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

0.0.2-alpha.1.fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-23 10:44:34 +02:00
parent d3f1e13c84
commit 1a5dd0908c
6 changed files with 557 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

96
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 -->
<!-- version: 1 -->
<!-- version: 2 -->
# Plan 0.0.2 — premiers profils de règles technologiques
@@ -62,32 +62,42 @@ L'inspection de l'archive taggée a constaté :
Aucun défaut bloquant de gouvernance, de structure documentaire, de pairing delta/history ou de cohérence interne n'a été trouvé.
### Observation post-tag non bloquante
### Preuve post-tag `publish.001`
Le history `rel.001` prévoit une vérification post-tag nommée `publish.001`, mais la baseline taggée ne contient pas de snapshot `publish.001`. Ce constat ne rend pas `v0.0.1` invalide : le contrôle est, par définition, postérieur au tag et les règles actuelles n'imposent pas un emplacement versionné pour sa preuve dans ce même tag.
Le rapport post-tag `pgr-0.0.1-publish.001-report.md` a été retrouvé dans la bibliothèque de travail après la première revue de `alpha.1`.
`0.0.2` ne doit pas inventer rétroactivement cette preuve. Une éventuelle décision durable sur la conservation des preuves post-publication relève d'un futur changement de gouvernance, hors du scope des profils technologiques sauf si elle devient bloquante.
Il enregistre `Status: PASS` pour `pgr-v0.0.1.zip` et confirme le SHA-256 déjà observé pour l'archive de baseline :
```text
48bfed6acc50d2c5bdd69db764ae29fe8c5a06b64375943f5d4120c7bb8429ef
```
Cette preuve est volontairement extérieure au tag `v0.0.1` parce qu'elle vérifie un artefact produit après le tag. Elle ne doit ni être injectée rétroactivement dans la stable ni remplacer l'audit d'intake de la session courante.
La revue a également identifié un besoin de maturité futur : un handoff/prompt de reprise doit finir par indiquer explicitement si une preuve post-publication telle que `publish.001` doit être fournie à la session suivante. Ce besoin de workflow reste hors scope fonctionnel de `0.0.2`.
## Inventaire des profils candidats
Le prompt demande d'examiner le corpus suivant. `alpha.1` le classe selon son utilité immédiate pour une première release de profils, sans prétendre fermer définitivement la taxonomie.
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 |
|------------------|------------------|---------------------------|-------|
| 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` | corpus éprouvé et directement réutilisable |
| Java / Maven / Gradle | inclure | famille `500 — languages` avec spécialisations build | nécessaire pour distinguer langage et build tool avant Android |
| Android | inclure | famille `600 — platforms` | premier vrai exemple de spécialisation plateforme |
| Rust + Android / JNI | inclure | famille `600 — platforms` comme composition spécialisée | vérifie l'interaction langage + plateforme + FFI sans généraliser JNI |
| Web / TypeScript / Vite / WASM / serveurs Rust | inclure | famille `600 — platforms` et composition de composants | couvre frontend autonome, WASM et frontières client/serveur |
| Tauri desktop/mobile | inclure | famille `700 — frameworks` | vérifie qu'un framework raffine Rust/Web/Android sans contaminer leurs règles générales |
| C / C++ / CMake | différer | future famille `500 — languages` | corpus utile mais non nécessaire pour prouver le premier modèle de composition |
| PHP / Composer | différer | future famille `500 — languages` | ne pas matérialiser un profil uniquement pour remplir la taxonomie |
| Python 3 application/package | différer | future famille `500 — languages` | le dépôt PGR n'est pas lui-même une application Python ; le profil peut être ajouté lorsqu'un besoin concret le justifie |
| architecture/règles cross-cutting | inclure seulement si nécessaire | famille `800 — architecture` ou propriétaire général existant | ne créer un owner transversal que si plusieurs profils ont réellement besoin d'une règle commune non déjà possédée |
| 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 |
| Rust / Cargo | inclure | famille `500 — languages` | 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 |
| 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 |
| 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 |
| C / C++ / CMake | différer | future famille `500 — languages` | 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 |
| Python 3 application/package | différer | future famille `500 — languages` | à 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 |
Les domaines différés restent des candidats légitimes. Leur absence de `0.0.2` ne vaut ni rejet ni interdiction future.
Le choix retenu cherche le plus petit ensemble qui exerce réellement plusieurs niveaux de composition : un modèle commun, un profil langage/écosystème, une distinction langage/build et une plateforme. Les compositions FFI, Web et framework restent séparées afin de ne pas transformer la première release de profils en catalogue.
## Règles de consolidation
Chaque tranche technologique doit :
@@ -99,7 +109,7 @@ Chaque tranche technologique doit :
5. documenter explicitement les overrides/contraintes spécialisées et leur scope ;
6. préférer les structures canoniques de l'écosystème lorsqu'elles apportent une vraie valeur ;
7. ne pas fixer une version d'outil ou de dépendance sans raison de compatibilité, reproductibilité, support ou sécurité ;
8. garder les audits spécialisés hors scope tant qu'une propriété stable et objectivement automatisable n'est pas identifiée ;
8. ne créer un audit que lorsqu'une propriété stable, objectivement automatisable et réellement utile a été démontrée ;
9. conserver PGR lui-même indépendant des toolchains qu'il documente ;
10. réviser le plan si une tranche devient sensiblement plus large que prévu au lieu d'absorber silencieusement le scope.
@@ -113,37 +123,25 @@ Aucune règle technologique détaillée n'est consolidée dans cette tranche.
### alpha.2 — Rule profile model
Formaliser le contrat d'un profil PGR : ownership, composition général → spécifique, navigation des familles `500`/`600`/`700`/`800`, règles de non-duplication et traitement des choix encore ouverts.
Formaliser le contrat d'un profil PGR : ownership, composition général → spécifique, navigation des familles nécessaires, règles de non-duplication et traitement des choix encore ouverts.
Cette tranche doit créer uniquement les propriétaires documentaires réellement nécessaires aux profils suivants ; aucun placeholder vide n'est autorisé.
Cette tranche doit créer uniquement les propriétaires documentaires réellement nécessaires à `0.0.2`. Les familles `700` et `800` restent réservées tant qu'aucun contenu réel ne justifie leur matérialisation.
### alpha.3 — Rust / Cargo
Consolider le premier profil langage/écosystème Rust/Cargo, notamment structure de workspace/crates, manifests et toolchain, dépendances/features, API/imports, erreurs/safety, tests et validation spécialisée lorsque ces sujets ne sont pas déjà possédés par une règle générale.
Cette tranche sert aussi de mesure réelle du coût d'un profil. Si elle montre que le modèle documentaire est sensiblement plus lourd que prévu, un REPLAN doit intervenir avant d'enchaîner les autres profils.
### alpha.4 — Java / Maven / Gradle
Consolider le profil Java et ses spécialisations de build Maven/Gradle en maintenant une frontière nette entre règles Java, contraintes de build tool et choix propres à une plateforme ou un framework.
### alpha.5 — Android
Consolider le profil plateforme Android : structure canonique, toolchain compatible, SDK/targets, configuration locale/signing, modules, packaging, tests/smokes et règles de compatibilité de target.
Consolider le premier profil plateforme Android : structure canonique, toolchain compatible, SDK/targets, configuration locale/signing, modules, packaging, tests/smokes et règles de compatibilité de target.
Les règles Rust/JNI ne doivent pas être absorbées dans le profil Android général.
### alpha.6 — Rust + Android / JNI
Consolider la composition spécialisée Rust + Android/JNI : ownership des responsabilités, frontière FFI, localisation de l'unsafe lorsqu'il est techniquement requis, lifecycle/threading et validation en couches.
### alpha.7 — Web / TypeScript / Vite / WASM / Rust server
Consolider le profil Web et ses compositions utiles : frontend autonome, TypeScript/Vite, assets, outputs générés, WASM Rust comme composant, séparation client/serveur et validation/smokes associés.
Les choix de framework serveur particuliers restent des spécialisations lorsque le profil général n'a pas besoin de les imposer.
### alpha.8 — Tauri desktop/mobile
Consolider Tauri comme framework composant des profils Rust, Web et éventuellement Android. Les contraintes Tauri desktop/mobile restent locales au framework et ne doivent pas devenir des règles Rust, Web, Java ou Android générales.
Les règles Rust/JNI, Web et Tauri ne doivent pas être absorbées dans ce profil général. Elles restent différées jusqu'à une release où leurs compositions pourront être traitées sans surcharger `0.0.2`.
### beta.1 — Profile reconciliation
@@ -161,11 +159,25 @@ Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release
## Dimensionnement et points de replan
Le découpage privilégie des responsabilités indépendamment validables plutôt qu'un nombre minimal de tranches.
Le premier forecast `alpha.2` à `alpha.8` a été jugé trop large pendant la revue opérateur de `alpha.1`. Le présent plan réduit donc la release avant tout développement technologique lourd.
Les tranches `alpha.4`, `alpha.5`, `alpha.7` et `alpha.8` présentent le plus grand risque de croissance. Si leur consolidation exige plusieurs propriétaires documentaires importants ou dépasse sensiblement une tranche cohérente, le plan MUST être révisé et le travail scindé en `alpha.N` supplémentaires avant de poursuivre.
Après `alpha.1.fix.1`, le chemin prévu est :
Si l'ensemble de `0.0.2` devient déraisonnablement large malgré la différenciation des profils C/C++, PHP et Python, un REPLAN peut encore réduire le scope de la release. Il ne faut pas forcer une taxonomie exhaustive pour fermer la version.
```text
alpha.2 modèle de profil
alpha.3 Rust / Cargo
alpha.4 Java / Maven / Gradle
alpha.5 Android
beta.1 réconciliation
rc.1 release candidate
stable 0.0.2
```
Ce découpage reste un forecast, pas une obligation de remplir tous les numéros coûte que coûte.
`alpha.3` est un point de mesure explicite. Si la construction du premier profil montre qu'un profil complet dépasse sensiblement le sizing envisagé, la release doit être REPLANifiée avant `alpha.4` au lieu de conserver mécaniquement le forecast.
Un nouveau besoin critique, plusieurs fixes consécutifs ou une évolution qui rend `0.0.2` non terminable dans la session doivent également déclencher un REPLAN. La qualité de la release prend le dessus sur la volonté de conserver artificiellement le nombre initial de profils.
## Hors périmètre
@@ -175,7 +187,7 @@ Si l'ensemble de `0.0.2` devient déraisonnablement large malgré la différenci
- créer les skeleton specifications complètes réservées à `0.0.4` ;
- créer un générateur ;
- réécrire KSP ou `sasedev-games` ;
- créer des audits spécialisés uniquement parce qu'un profil existe ;
- multiplier les audits spécialisés ; `alpha.1.fix.1` introduit uniquement l'audit Markdown monotâche justifié par un défaut réellement observé ;
- transformer les exemples de technologies en dépendances du dépôt PGR ;
- modifier rétroactivement les deltas/histories `0.0.1` pour refléter des règles apparues après leur émission.
@@ -185,7 +197,7 @@ Si l'ensemble de `0.0.2` devient déraisonnablement large malgré la différenci
- le modèle documentaire des profils est explicite et cohérent avec la hiérarchie PGR ;
- les profils retenus dans le scope possèdent chacun un propriétaire normatif réel ;
- les spécialisations plateforme/framework ne contaminent pas les règles générales ;
- les spécialisations de build et de plateforme retenues ne contaminent pas les règles générales ;
- les choix encore ouverts restent identifiés comme tels ;
- la navigation entre règles générales et profils spécifiques est claire ;
- aucune duplication importante avec les familles `200`, `300` et `400` ne subsiste ;

23
docs/validation/001-VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Matrice de validation PGR
@@ -13,18 +13,21 @@ Les catégories et règles de sélection sont définies dans [`../rules/400-VALI
## Contrôles actifs
| ID | Catégorie | Commande / contrôle | Prérequis | Trigger | Phase | Coût | Acteur |
|-------------------|-----------|------------------------------------------------------------------------------------------|------------------------|-------------------------------|----------------------|--------|-----------------|
| `PGR-GIT-001` | `CHECK` | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | Git | toute modification suivie | alpha/beta/RC/stable | faible | opérateur |
| `PGR-VERSION-001` | `CHECK` | comparer `VERSION` à la version attendue par le delta courant | fichier `VERSION` | changement de tranche/version | alpha/beta/RC/stable | faible | opérateur |
| `PGR-LAYOUT-001` | `AUDIT` | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta | scope du delta | changement de structure | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-DOC-001` | `AUDIT` | vérifier headers `file/version`, chemins, liens et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-NAV-001` | `AUDIT` | vérifier que les points d'entrée et liens canoniques ciblent des fichiers existants | index et docs racine | navigation ou réconciliation | beta/RC/stable | faible | opérateur/revue |
| `PGR-SCOPE-001` | `AUDIT` | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants | réconciliation de phase | beta/RC/stable | faible | revue |
| `PGR-STATUS-001` | `CHECK` | `git status --short` | Git | avant fermeture d'une tranche | alpha/beta/RC/stable | faible | opérateur |
| ID | Catégorie | Commande / contrôle | Prérequis | Trigger | Phase | Coût | Acteur |
|--------------------|-----------|------------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
| `PGR-GIT-001` | `CHECK` | `git diff --check` ou `git diff --cached --check` selon l'état de l'index | Git | toute modification suivie | alpha/beta/RC/stable | faible | opérateur |
| `PGR-VERSION-001` | `CHECK` | comparer `VERSION` à la version attendue par le delta courant | fichier `VERSION` | changement de tranche/version | alpha/beta/RC/stable | faible | opérateur |
| `PGR-LAYOUT-001` | `AUDIT` | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta | scope du delta | changement de structure | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-DOC-001` | `AUDIT` | vérifier headers `file/version`, chemins, liens et responsabilités des documents touchés | fichiers documentaires | modification documentaire | alpha/beta/RC/stable | faible | opérateur/revue |
| `PGR-MD-TABLE-001` | `AUDIT` | `python3 -B scripts/audit_markdown_tables.py <paths...>` | Python 3 | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI |
| `PGR-NAV-001` | `AUDIT` | vérifier que les points d'entrée et liens canoniques ciblent des fichiers existants | index et docs racine | navigation ou réconciliation | beta/RC/stable | faible | opérateur/revue |
| `PGR-SCOPE-001` | `AUDIT` | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants | réconciliation de phase | beta/RC/stable | faible | revue |
| `PGR-STATUS-001` | `CHECK` | `git status --short` | Git | avant fermeture d'une tranche | alpha/beta/RC/stable | faible | opérateur |
Un contrôle manuel peut rester dans la matrice lorsqu'aucun audit automatisé fiable n'existe encore. PGR SHOULD automatiser uniquement les propriétés stables et objectivement contrôlables.
`PGR-MD-TABLE-001` est le premier audit matérialisé dans PGR lui-même. Il reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown, sans vérifier les blank lines, les headers, les liens ou d'autres règles documentaires.
## Politique Eclipse actuelle
Les métadonnées Eclipse spécifiques à une machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.