Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.2-alpha.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-23 11:19:21 +02:00
parent 1a5dd0908c
commit 5f9b84c980
9 changed files with 634 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
RULES.md
View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md --> <!-- file: RULES.md -->
<!-- version: 5 --> <!-- version: 6 -->
# Index normatif Project Governance Rules # Index normatif Project Governance Rules
@@ -72,12 +72,16 @@ Les traductions complètes éventuelles vivent dans des dépôts distincts (`pgr
Les règles détaillées sont structurées progressivement sous [`docs/rules/`](docs/rules/). Les règles détaillées sont structurées progressivement sous [`docs/rules/`](docs/rules/).
Famille actuellement active : Familles actuellement actives :
- [`docs/rules/200-GOVERNANCE.md`](docs/rules/200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession. - [`docs/rules/200-GOVERNANCE.md`](docs/rules/200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.
- [`docs/rules/210-WORKFLOW.md`](docs/rules/210-WORKFLOW.md) — plans, deltas, histories, prompts, handoffs, manifests, commits, baselines et reprise de session. - [`docs/rules/210-WORKFLOW.md`](docs/rules/210-WORKFLOW.md) — plans, deltas, histories, prompts, handoffs, manifests, commits, baselines et reprise de session.
- [`docs/rules/300-DOCUMENTATION.md`](docs/rules/300-DOCUMENTATION.md) — rôles documentaires, taxonomie, révisions internes, documents vivants et conservation historique. - [`docs/rules/300-DOCUMENTATION.md`](docs/rules/300-DOCUMENTATION.md) — rôles documentaires, taxonomie, révisions internes, documents vivants et conservation historique.
- [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — sélection proportionnelle des preuves, catégories de validation, tests utiles, doubles de test et autorité opérateur. - [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — sélection proportionnelle des preuves, catégories de validation, tests utiles, doubles de test et autorité opérateur.
- [`docs/rules/500-LANGUAGES.md`](docs/rules/500-LANGUAGES.md) — contrat commun des profils langage, écosystème et spécialisations de build associées.
- [`docs/rules/600-PLATFORMS.md`](docs/rules/600-PLATFORMS.md) — contrat commun des profils plateforme et de leur compatibilité de target/runtime.
Le modèle de composition et d'ownership des profils est défini dans [`docs/architecture/003-RULE_PROFILE_MODEL.md`](docs/architecture/003-RULE_PROFILE_MODEL.md).
Une famille de règles n'est créée que lorsqu'elle possède un contenu réel ; aucun répertoire vide n'est requis pour anticiper une future technologie. Une famille de règles n'est créée que lorsqu'elle possède un contenu réel ; aucun répertoire vide n'est requis pour anticiper une future technologie.

2
VERSION
View File

@@ -1 +1 @@
0.0.2-alpha.1.fix.1 0.0.2-alpha.2

180
deltas/0.0.2/alpha.2.md Normal file
View File

@@ -0,0 +1,180 @@
<!-- file: deltas/0.0.2/alpha.2.md -->
<!-- version: 1 -->
# Delta 0.0.2-alpha.2 — rule profile model
## Baseline
Version attendue avant application :
```text
0.0.2-alpha.1.fix.1
```
Le history `history/0.0.2/alpha.1.fix.1.md` MUST avoir été appliqué et committé avant ce delta.
Version après application :
```text
0.0.2-alpha.2
```
## Objet
Formaliser le modèle de profils PGR avant toute consolidation technologique détaillée.
Cette tranche définit :
- la notion de profil et son propriétaire normatif ;
- l'applicabilité d'un profil à partir de faits réels du projet ;
- la composition du général vers le spécifique ;
- la résolution des overrides et des conflits ;
- la non-duplication des règles héritées ;
- le traitement des spécialisations internes et profils composites ;
- la distinction entre règle décidée et choix encore ouvert ;
- les contrats communs des familles `500 — languages / ecosystems` et `600 — platforms` nécessaires au scope réduit de `0.0.2`.
Aucune règle Rust, Cargo, Java, Maven, Gradle ou Android détaillée n'est encore introduite.
## Modèle retenu
La composition de référence reste :
```text
GENERAL
↓
ecosystem / language
↓
platform
↓
framework
↓
project type / subsystem
↓
project-specific
↓
explicit exception
```
Chaque règle durable possède un seul owner normatif. Les profils spécifiques héritent des règles générales et ne les recopient pas.
Une contradiction volontaire doit être un override explicite, borné et justifié. Deux règles applicables de même niveau qui se contredisent sans relation explicite constituent un défaut à résoudre ; l'ordre des fichiers ne crée aucune priorité.
Les profils composites ne sont créés que si l'intersection de plusieurs profils possède un contrat propre réel. La simple coexistence de deux technologies ne suffit pas.
## Familles activées
`alpha.2` active uniquement les familles nécessaires aux prochaines tranches :
```text
500 — languages / ecosystems
600 — platforms
```
Les familles suivantes restent réservées et non matérialisées :
```text
700 — frameworks
800 — architecture
```
Les règles project-specific continuent d'appartenir au dépôt qui les possède ; PGR ne crée pas de placeholder `900` sans contenu réel.
## Scope
REPLACE :
```text
VERSION
RULES.md
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
docs/rules/000-README.md
```
ADD :
```text
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/rules/500-LANGUAGES.md
docs/rules/600-PLATFORMS.md
deltas/0.0.2/alpha.2.md
```
DELETE : aucun.
Aucun manifest de suppression n'est nécessaire.
## Validation opérateur
```bash
test "$(cat VERSION)" = "0.0.2-alpha.2"
test -f docs/architecture/003-RULE_PROFILE_MODEL.md
test -f docs/rules/500-LANGUAGES.md
test -f docs/rules/600-PLATFORMS.md
test -f deltas/0.0.2/alpha.2.md
grep -F 'Toute règle durable doit posséder un seul propriétaire normatif canonique.' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -F "L'ordre des fichiers dans un répertoire ne crée jamais une priorité normative." docs/architecture/003-RULE_PROFILE_MODEL.md
grep -F 'PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -F 'Les profils spécifiques utilisent la plage `510` à `599`.' docs/rules/500-LANGUAGES.md
grep -F 'Une spécialisation de build tool ne devient pas une règle du langage entier.' docs/rules/500-LANGUAGES.md
grep -F 'La modernité de la toolchain de build et la version minimale du runtime ou de la target sont deux décisions distinctes.' docs/rules/600-PLATFORMS.md
grep -F 'Les profils spécifiques utilisent la plage `610` à `699`.' docs/rules/600-PLATFORMS.md
grep -F '500-LANGUAGES.md' RULES.md
grep -F '600-PLATFORMS.md' RULES.md
grep -F '003-RULE_PROFILE_MODEL.md' docs/rules/000-README.md
grep -F 'famille `500 — languages / ecosystems`' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
git diff --check
git add VERSION RULES.md \
docs/architecture/003-RULE_PROFILE_MODEL.md \
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md \
docs/rules/000-README.md \
docs/rules/500-LANGUAGES.md \
docs/rules/600-PLATFORMS.md \
deltas/0.0.2/alpha.2.md
git diff --cached --check
git status --short
```
La sortie attendue avant ajout du history est :
```text
M RULES.md
M VERSION
A deltas/0.0.2/alpha.2.md
A docs/architecture/003-RULE_PROFILE_MODEL.md
M docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
M docs/rules/000-README.md
A docs/rules/500-LANGUAGES.md
A docs/rules/600-PLATFORMS.md
```
Revue opérateur complémentaire :
- confirmer que le modèle permet de déterminer où une règle doit être possédée sans utiliser l'ordre des fichiers comme priorité ;
- confirmer que les spécialisations Maven/Gradle pourront rester locales à Java/build et qu'une contrainte Android ne contaminera pas Java en général ;
- confirmer que les familles `700` et `800` ne sont pas créées prématurément ;
- confirmer qu'aucune règle technologique détaillée prévue pour `alpha.3+` n'a été absorbée dans cette tranche.
## Transition
### PASS
Créer et appliquer séparément `history/0.0.2/alpha.2.md`, committer la tranche, puis préparer `0.0.2-alpha.3` consacré au premier profil réel `Rust / Cargo`.
`alpha.3` reste le point de mesure prévu par le plan : si le coût réel d'un profil complet invalide le sizing, effectuer un REPLAN avant `alpha.4`.
### FAIL
Rester dans `0.0.2-alpha.2.fix.M` tant que le modèle de profil lui-même n'est pas cohérent. Ne pas commencer le profil Rust/Cargo sur un modèle non validé.

163
docs/architecture/003-RULE_PROFILE_MODEL.md Normal file
View File

@@ -0,0 +1,163 @@
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
<!-- version: 1 -->
# Modèle de profils de règles PGR
## Rôle
Un profil PGR est un ensemble cohérent de règles réutilisables dont le scope est plus spécifique que les règles générales.
Un profil ne constitue ni un catalogue de dépendances, ni un template technique, ni un skeleton de projet. Il définit uniquement les règles durables réellement propres à un langage, un écosystème, une plateforme, un framework, un type de projet ou un sous-système.
Les règles générales restent héritées implicitement. Elles ne sont pas recopiées dans chaque profil.
## Axes de spécialisation
La composition normative suit l'ordre général :
```text
GENERAL
↓
ecosystem / language
↓
platform
↓
framework
↓
project type / subsystem
↓
project-specific
↓
explicit exception
```
Cet ordre exprime la spécificité des scopes. Il ne signifie pas qu'un projet doit posséder un profil à chaque niveau.
Un projet peut par exemple combiner uniquement :
```text
GENERAL
+ Rust / Cargo
```
ou :
```text
GENERAL
+ Java
+ Gradle
+ Android
```
Une technologie absente du projet ne rend aucun profil correspondant applicable.
## Propriétaire normatif
Toute règle durable doit posséder un seul propriétaire normatif canonique.
Lorsqu'une règle est déjà correctement possédée par un document général, un profil spécifique doit la référencer si nécessaire, mais ne doit pas la recopier sous une formulation équivalente.
Inversement, une contrainte réellement propre à un profil ne doit pas être remontée vers un owner général uniquement pour réduire le nombre de fichiers.
Le propriétaire est choisi selon le scope le plus général dans lequel la règle reste vraie sans exception implicite.
## Applicabilité
Un profil doit rendre son scope explicite : l'utilisateur ou le skeleton futur doit pouvoir déterminer à partir de faits du projet si le profil s'applique.
L'applicabilité doit reposer sur des propriétés concrètes, par exemple :
- langage ou écosystème réellement utilisé ;
- build tool réellement utilisé ;
- plateforme réellement ciblée ;
- framework réellement présent ;
- type de projet ou sous-système réellement concerné.
PGR ne doit pas appliquer un profil uniquement parce qu'il est fréquent, recommandé ailleurs ou présent dans un projet source historique.
## Composition et résolution
La résolution d'un ensemble de profils suit ces étapes :
1. appliquer les règles générales ;
2. ajouter les profils langage/écosystème applicables ;
3. ajouter les profils plateforme applicables ;
4. ajouter les profils framework applicables ;
5. ajouter les profils de type de projet ou sous-système applicables ;
6. appliquer les règles propres au projet ;
7. appliquer les exceptions explicites et bornées.
Une règle plus spécifique peut raffiner, renforcer ou remplacer une règle plus générale dans son scope.
Lorsqu'elle contredit volontairement une règle héritée, le profil spécifique doit identifier l'override, son scope et sa raison. L'ordre des fichiers dans un répertoire ne crée jamais une priorité normative.
Deux règles applicables de même niveau qui se contredisent sans relation explicite ne sont pas départagées arbitrairement : la situation constitue un défaut de conformité ou de modélisation à résoudre.
## Spécialisation interne à une famille
Une famille peut posséder plusieurs niveaux internes lorsque cela réduit la duplication.
Par exemple, un profil de langage peut être complété par un build tool particulier :
```text
Java
↓
Maven
```
ou :
```text
Java
↓
Gradle
```
Cette relation interne ne modifie pas la hiérarchie globale. Une contrainte de plateforme plus spécifique peut encore raffiner le résultat lorsqu'elle s'applique.
Lorsque langage et build tool sont pratiquement indissociables pour le scope visé, PGR peut les documenter dans un même profil si cette fusion évite une séparation artificielle. Le choix du découpage doit suivre les responsabilités réelles, pas une taxonomie rigide.
## Profils composites
PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.
Un profil composite n'est justifié que lorsque l'intersection de plusieurs profils possède des règles propres qui ne peuvent être correctement possédées par chacun séparément.
Ainsi, la simple coexistence de Rust et Android ne suffit pas à créer un profil `Rust + Android`. Un tel profil devient pertinent seulement lorsqu'un contrat propre à leur interaction, par exemple une frontière FFI/JNI, doit être normé.
## Choix ouverts
Un choix encore indécis n'est pas une règle.
Lorsqu'un profil révèle plusieurs options légitimes sans critère permettant d'en retenir une, PGR doit conserver la question comme décision ouverte, étude ou point de planification approprié plutôt que d'inventer une valeur par défaut arbitraire.
Une contrainte issue d'un framework, d'une plateforme ou d'un outil externe peut devenir une règle spécifique lorsque son caractère obligatoire est établi.
## Non-duplication
Un profil doit contenir uniquement ce qui ajoute une information normative dans son scope.
Il ne doit pas recopier les règles générales relatives notamment à la gouvernance, aux documents, aux secrets, au lifecycle des releases ou à la validation lorsque ces règles s'appliquent déjà sans modification.
Une règle transversale découverte pendant la création de plusieurs profils doit être remontée vers un propriétaire commun uniquement si elle est réellement indépendante de ces profils.
## Croissance documentaire
PGR matérialise uniquement les familles et profils possédant un contenu normatif réel.
Pour `0.0.2`, les familles nécessaires sont :
```text
500 — languages / ecosystems
600 — platforms
```
Les familles `700 — frameworks` et `800 — architecture` restent réservées tant qu'un premier profil réel ne justifie pas leur activation normative.
Le modèle architectural présent n'oblige pas à créer des fichiers placeholders pour les profils différés.
## Instanciation future
Les futures skeleton specifications sélectionneront les profils applicables et recopieront leurs règles pertinentes dans la baseline locale du projet créé.
Le projet instancié restera autonome : la composition de profils sert à construire sa baseline initiale, pas à créer une dépendance dynamique vers PGR.

28
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md --> <!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Plan 0.0.2 — premiers profils de règles technologiques # Plan 0.0.2 — premiers profils de règles technologiques
@@ -80,19 +80,19 @@ La revue a également identifié un besoin de maturité futur : un handoff/promp
Le prompt demande d'examiner le corpus suivant. Après revue du sizing initial, `0.0.2-alpha.1.fix.1` réduit volontairement le nombre de profils matérialisés afin de conserver une version terminable et correctement validable dans une session. Le prompt demande d'examiner le corpus suivant. Après revue du sizing initial, `0.0.2-alpha.1.fix.1` réduit volontairement le nombre de profils matérialisés afin de conserver une version terminable et correctement validable dans une session.
| Domaine candidat | Décision `0.0.2` | Propriétaire prévisionnel | Motif | | Domaine candidat | Décision `0.0.2` | Propriétaire prévisionnel | Motif |
|------------------------------------------------|------------------|------------------------------------------------------|------------------------------------------------------------------------------| |------------------------------------------------|------------------|------------------------------------------------|------------------------------------------------------------------------------|
| modèle de profil et composition des scopes | inclure | architecture PGR | nécessaire avant de créer plusieurs profils cohérents | | modèle de profil et composition des scopes | inclure | architecture PGR | nécessaire avant de créer plusieurs profils cohérents |
| Rust / Cargo | inclure | famille `500 — languages` | premier profil langage/écosystème, corpus éprouvé | | Rust / Cargo | inclure | famille `500 — languages / ecosystems` | premier profil langage/écosystème, corpus éprouvé |
| Java / Maven / Gradle | inclure | famille `500 — languages` avec spécialisations build | permet de distinguer langage et build tool avant Android | | Java / Maven / Gradle | inclure | famille `500 — languages / ecosystems` + build | permet de distinguer langage et build tool avant Android |
| Android | inclure | famille `600 — platforms` | premier exemple de spécialisation plateforme sur des règles de langage/build | | Android | inclure | famille `600 — platforms` | premier exemple de spécialisation plateforme sur des règles de langage/build |
| Rust + Android / JNI | différer | future composition spécialisée | utile mais non nécessaire pour prouver le premier modèle | | Rust + Android / JNI | différer | future composition spécialisée | utile mais non nécessaire pour prouver le premier modèle |
| Web / TypeScript / Vite / WASM / serveurs Rust | différer | future composition Web | scope autonome suffisamment large pour une release ultérieure | | Web / TypeScript / Vite / WASM / serveurs Rust | différer | future composition Web | scope autonome suffisamment large pour une release ultérieure |
| Tauri desktop/mobile | différer | future famille `700 — frameworks` | dépend de profils Rust/Web/plateforme suffisamment stabilisés | | Tauri desktop/mobile | différer | future famille `700 — frameworks` | dépend de profils Rust/Web/plateforme suffisamment stabilisés |
| C / C++ / CMake | différer | future famille `500 — languages` | corpus utile mais non nécessaire au premier lot | | C / C++ / CMake | différer | future famille `500 — languages / ecosystems` | corpus utile mais non nécessaire au premier lot |
| PHP / Composer | différer | future famille `500 — languages` | ne pas matérialiser un profil uniquement pour remplir la taxonomie | | PHP / Composer | différer | future famille `500 — languages / ecosystems` | ne pas matérialiser un profil uniquement pour remplir la taxonomie |
| Python 3 application/package | différer | future famille `500 — languages` | à introduire lorsqu'un besoin concret le justifie | | Python 3 application/package | différer | future famille `500 — languages / ecosystems` | à introduire lorsqu'un besoin concret le justifie |
| architecture/règles cross-cutting | conditionnel | famille `800 — architecture` ou owner existant | uniquement si plusieurs profils révèlent une règle commune sans propriétaire | | architecture/règles cross-cutting | conditionnel | famille `800 — architecture` ou owner existant | uniquement si plusieurs profils révèlent une règle commune sans propriétaire |
Les domaines différés restent des candidats légitimes. Leur absence de `0.0.2` ne vaut ni rejet ni interdiction future. Les domaines différés restent des candidats légitimes. Leur absence de `0.0.2` ne vaut ni rejet ni interdiction future.

8
docs/rules/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/000-README.md --> <!-- file: docs/rules/000-README.md -->
<!-- version: 6 --> <!-- version: 7 -->
# Index des règles PGR # Index des règles PGR
@@ -15,6 +15,10 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
- [`210-WORKFLOW.md`](210-WORKFLOW.md) — contrats des artefacts workflow, ordre delta/history/commit, reprise et baselines de release. - [`210-WORKFLOW.md`](210-WORKFLOW.md) — contrats des artefacts workflow, ordre delta/history/commit, reprise et baselines de release.
- [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques. - [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques.
- [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur. - [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur.
- [`500-LANGUAGES.md`](500-LANGUAGES.md) — contrat commun des profils langage/écosystème et de leurs spécialisations de build.
- [`600-PLATFORMS.md`](600-PLATFORMS.md) — contrat commun des profils plateforme.
Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).
## Organisation prévue ## Organisation prévue
@@ -25,7 +29,7 @@ Les autres familles seront créées uniquement lorsqu'elles disposent d'un conte
200 — governance 200 — governance
300 — documentation 300 — documentation
400 — validation 400 — validation
500 — languages 500 — languages / ecosystems
600 — platforms 600 — platforms
700 — frameworks 700 — frameworks
800 — architecture 800 — architecture

76
docs/rules/500-LANGUAGES.md Normal file
View File

@@ -0,0 +1,76 @@
<!-- file: docs/rules/500-LANGUAGES.md -->
<!-- version: 1 -->
# Règles de profils langage et écosystème
## Scope
Cette famille définit le contrat commun des profils liés à un langage, son écosystème et, lorsque pertinent, ses build tools ou package managers.
Les règles propres à Rust/Cargo, Java, Maven, Gradle ou à d'autres technologies sont ajoutées dans des documents plus spécifiques uniquement lorsqu'un contenu normatif réel existe.
## Responsabilités de la famille
Un profil langage/écosystème MAY posséder les règles spécifiques concernant notamment :
- l'organisation canonique des sources, packages, modules, crates ou workspaces ;
- les manifests et fichiers de configuration propres à l'écosystème ;
- la toolchain de compilation ou d'exécution lorsqu'elle appartient au langage ;
- les build tools et package managers liés à cet écosystème ;
- les dépendances, features, scopes ou configurations propres au gestionnaire utilisé ;
- le formatter, le linter et les commandes officielles de vérification ;
- les conventions d'API, d'import, d'erreur ou de safety réellement propres au langage ;
- l'organisation des tests lorsque l'écosystème lui donne une structure spécifique ;
- les artefacts générés ou lockfiles lorsque leur traitement dépend réellement de l'écosystème.
Un profil langage/écosystème MUST NOT absorber des règles dont le propriétaire naturel est une plateforme, un framework, un domaine métier ou le projet particulier.
## Héritage
Les profils de cette famille héritent des règles générales PGR et ne doivent pas recopier les contrats déjà possédés par les familles de gouvernance, documentation ou validation.
Une règle générale comme l'interdiction de versionner des secrets reste applicable sans être répétée dans chaque profil langage.
Lorsqu'un langage ou un build tool impose une exception réelle à une règle générale, le profil spécifique doit déclarer l'override et sa justification.
## Langage et build tool
PGR ne force pas un découpage identique pour tous les écosystèmes.
Un langage et son build tool MAY partager un profil lorsque leurs responsabilités sont suffisamment liées et que les séparer ne produirait que des renvois artificiels.
Ils SHOULD être séparés lorsque plusieurs build tools interchangeables possèdent chacun des règles propres significatives.
Dans ce second cas, la composition est explicite :
```text
language profile
↓
build-tool specialization
```
Une spécialisation de build tool ne devient pas une règle du langage entier.
## Versions d'outils et dépendances
Un profil MUST NOT figer une version exacte d'outil ou de dépendance uniquement parce qu'une version apparaît dans un projet source historique.
Une contrainte de version appartient au profil lorsqu'elle répond à une nécessité démontrée de compatibilité, reproductibilité, support, sécurité ou matrice imposée par un outil plus spécifique.
Une contrainte introduite par une plateforme ou un framework reste possédée par ce scope plus spécifique et ne se propage pas au langage entier.
## Validation spécialisée
Un profil langage/écosystème peut ajouter des commandes de formatage, lint, check ou test propres à sa toolchain.
Ces commandes complètent la gouvernance de validation générale ; elles ne redéfinissent ni l'autorité du gate opérateur, ni les statuts de preuve, ni le principe de proportionnalité.
Un audit Python PGR ne doit pas réimplémenter une propriété déjà contrôlée de façon fiable par le compilateur, le formatter, le linter ou le build tool officiel sans besoin distinct démontré.
## Nomenclature documentaire
Le document `500-LANGUAGES.md` possède le contrat commun de la famille.
Les profils spécifiques utilisent la plage `510` à `599`. Leur numéro identifie la navigation documentaire et ne représente ni une priorité normative implicite ni une version technologique.
L'applicabilité et les relations de spécialisation sont déterminées par le contenu du profil conformément à [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md), jamais par l'ordre lexical des fichiers.

65
docs/rules/600-PLATFORMS.md Normal file
View File

@@ -0,0 +1,65 @@
<!-- file: docs/rules/600-PLATFORMS.md -->
<!-- version: 1 -->
# Règles de profils plateforme
## Scope
Cette famille définit le contrat commun des profils liés à une plateforme de build, d'exécution ou de distribution telle qu'Android, iOS, Desktop, Web ou une cible embarquée lorsqu'un profil réel le justifie.
Les règles propres à une plateforme sont ajoutées dans des documents plus spécifiques uniquement lorsqu'elles possèdent un contenu normatif réel.
## Responsabilités de la famille
Un profil plateforme MAY posséder les règles spécifiques concernant notamment :
- la structure de projet imposée ou conventionnelle sur cette plateforme ;
- les SDKs, targets, runtimes et niveaux minimums supportés ;
- les contraintes de toolchain réellement imposées par la plateforme ;
- les permissions, manifests, capabilities ou métadonnées de plateforme ;
- le packaging, la signature et les artefacts de distribution ;
- les émulateurs, simulateurs, appareils ou environnements nécessaires aux smokes ;
- les adaptations de lifecycle, input ou services réellement propres à la plateforme ;
- les contraintes de compatibilité utilisateur liées à une version minimale de target/runtime.
Un profil plateforme MUST NOT recopier les règles du langage ou du build tool lorsque celles-ci restent valides sans spécialisation.
## Composition avec les langages et build tools
Une plateforme peut être utilisée avec plusieurs langages ou toolchains. Son profil ne doit donc pas supposer implicitement une combinaison unique lorsque la plateforme elle-même ne l'impose pas.
Lorsqu'une plateforme impose une contrainte plus précise à un langage ou build tool déjà applicable, la règle plateforme peut la raffiner ou la remplacer dans son scope à condition d'identifier clairement la contrainte et sa raison.
Cette contrainte MUST NOT se propager aux projets utilisant le même langage hors de cette plateforme.
## Toolchain de build et compatibilité de target
La modernité de la toolchain de build et la version minimale du runtime ou de la target sont deux décisions distinctes.
L'utilisation d'un SDK, compilateur ou build tool récent ne justifie pas à elle seule l'augmentation de la version minimale supportée par les utilisateurs.
Une hausse d'un minimum de target/runtime constitue un changement de compatibilité et doit être justifiée par une contrainte ou un bénéfice réel du projet.
Inversement, un minimum ancien ne doit pas être conservé artificiellement lorsqu'il empêche une capacité nécessaire, une maintenance raisonnable ou une chaîne de build supportée.
## Packaging, secrets et configuration locale
Les règles de packaging ou de signature spécifiques à une plateforme peuvent appartenir à son profil, mais les secrets eux-mêmes restent soumis aux règles générales PGR et ne sont jamais versionnés.
Une plateforme peut nécessiter des fichiers locaux ou générés particuliers ; leur politique Git doit être documentée dans le profil spécifique seulement lorsqu'elle diffère réellement du contrat général.
## Validation spécialisée
Un profil plateforme peut définir les builds, packages et smokes réellement nécessaires pour prouver le support annoncé.
La présence d'une plateforme dans un projet ne rend pas automatiquement tous ses smokes obligatoires à chaque tranche. La sélection reste proportionnée au scope modifié et aux preuves invalidées.
Les validations nécessitant un appareil, un simulateur, un service externe ou une chaîne de packaging réelle doivent être distinguées des contrôles documentaires ou unitaires qui ne prouvent pas ces comportements.
## Nomenclature documentaire
Le document `600-PLATFORMS.md` possède le contrat commun de la famille.
Les profils spécifiques utilisent la plage `610` à `699`. Leur numéro sert à la navigation et ne détermine pas une priorité normative implicite.
La résolution entre profils suit [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).

123
history/0.0.2/alpha.2.md Normal file
View File

@@ -0,0 +1,123 @@
<!-- file: history/0.0.2/alpha.2.md -->
<!-- version: 1 -->
# History 0.0.2-alpha.2 — modèle de profils PGR
## Statut
PASS
La tranche `0.0.2-alpha.2` a été validée par l'opérateur. Le modèle d'ownership, d'applicabilité et de composition des profils est en place avant l'introduction du premier profil technologique réel.
## Baseline
La tranche précédente `0.0.2-alpha.1.fix.1` a été enregistrée `PASS`, puis committée et poussée sous le commit observé :
```text
1a5dd09
```
Version validée après application de `alpha.2` :
```text
0.0.2-alpha.2
```
## Validation opérateur observée
L'opérateur a confirmé la version et la présence des nouveaux propriétaires documentaires :
```bash
test "$(cat VERSION)" = "0.0.2-alpha.2"
test -f docs/architecture/003-RULE_PROFILE_MODEL.md
test -f docs/rules/500-LANGUAGES.md
test -f docs/rules/600-PLATFORMS.md
test -f deltas/0.0.2/alpha.2.md
```
Les contrats principaux du modèle ont été vérifiés par recherche littérale :
```text
Toute règle durable doit posséder un seul propriétaire normatif canonique.
L'ordre des fichiers dans un répertoire ne crée jamais une priorité normative.
PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.
```
Les contrats des familles `500` et `600` ont également été retrouvés, notamment :
```text
Les profils spécifiques utilisent la plage `510` à `599`.
Une spécialisation de build tool ne devient pas une règle du langage entier.
La modernité de la toolchain de build et la version minimale du runtime ou de la target sont deux décisions distinctes.
Les profils spécifiques utilisent la plage `610` à `699`.
```
Les liens depuis `RULES.md`, l'index `docs/rules/000-README.md` et le plan `0.0.2` ont été vérifiés.
L'audit Markdown PGR a ensuite été exécuté :
```bash
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
```
Résultat observé :
```text
Markdown table audit: clean (2 table(s), 50 file(s))
```
Les contrôles Git ont réussi :
```bash
git diff --check
git add VERSION RULES.md \
docs/architecture/003-RULE_PROFILE_MODEL.md \
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md \
docs/rules/000-README.md \
docs/rules/500-LANGUAGES.md \
docs/rules/600-PLATFORMS.md \
deltas/0.0.2/alpha.2.md
git diff --cached --check
git status --short
```
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
La sortie finale observée avant ajout du présent history était exactement :
```text
M RULES.md
M VERSION
A deltas/0.0.2/alpha.2.md
A docs/architecture/003-RULE_PROFILE_MODEL.md
M docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
M docs/rules/000-README.md
A docs/rules/500-LANGUAGES.md
A docs/rules/600-PLATFORMS.md
```
## Revue qualitative
L'état livré respecte les frontières prévues par `alpha.2` :
- l'ownership d'une règle dépend de son scope et non du numéro ou de l'ordre lexical des fichiers ;
- une spécialisation de build tool peut rester plus spécifique que son langage sans contaminer ce dernier ;
- une contrainte plateforme peut surcharger localement un langage/build tool sans devenir une règle générale ;
- les familles `700 — frameworks` et `800 — architecture` restent réservées et ne sont pas matérialisées sans contenu réel ;
- aucune règle Rust, Cargo, Java, Maven, Gradle ou Android détaillée n'a été absorbée prématurément dans le modèle transversal.
## Résultat
`0.0.2-alpha.2` est validée `PASS`.
La tranche suivante autorisée est :
```text
0.0.2-alpha.3
```
Elle est consacrée au premier profil réel `Rust / Cargo` et sert de point de mesure du coût d'un profil complet avant de confirmer ou replanifier les tranches `alpha.4+`.