diff --git a/VERSION b/VERSION index 8acdd82..4e71452 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.0.1 +0.0.2-alpha.1 diff --git a/deltas/0.0.2/alpha.1.md b/deltas/0.0.2/alpha.1.md new file mode 100644 index 0000000..14953c7 --- /dev/null +++ b/deltas/0.0.2/alpha.1.md @@ -0,0 +1,171 @@ + + + +# Delta 0.0.2-alpha.1 — audit de baseline et cadrage des profils + +## Baseline + +Archive source fournie par l'opérateur comme téléchargement du tag stable Gitea : + +```text +v0.0.1 +``` + +Cette archive constitue la baseline autoritaire de la tranche. L'absence de `.git` y est normale ; aucun état provenant d'un workspace local ou d'une conversation antérieure n'est utilisé comme état courant s'il n'est pas confirmé par l'archive ou par `prompts/002-V0_0_2_START_PROMPT.md`. + +Version attendue avant application : + +```text +0.0.1 +``` + +Version après application : + +```text +0.0.2-alpha.1 +``` + +## Objet + +Exécuter le gate de framing imposé par le prompt `0.0.2` avant toute consolidation technologique : + +- vérifier la baseline stable `v0.0.1` ; +- auditer les règles, la gouvernance, la structure documentaire, les deltas/histories et la cohérence générale ; +- confronter le prompt `0.0.2` à l'état réel du dépôt ; +- inventorier les profils technologiques candidats ; +- limiter le scope aux profils utiles à cette première release ; +- dimensionner les tranches suivantes ; +- créer le plan actif `0.0.2`. + +Aucune règle technologique détaillée n'est introduite dans `alpha.1`. + +## Résultat de l'audit de baseline + +La prévalidation de l'archive a constaté : + +- archive ZIP lisible, racine unique `pgr/`, sans doublon, traversal ou symlink ; +- `44` fichiers et `13` répertoires ; +- `VERSION` égal à `0.0.1` ; +- absence normale de `.git` ; +- aucun cache/build connu ou secret local distribué ; +- headers `file/version` cohérents sur tous les Markdown ; +- aucun lien Markdown local cassé parmi les liens vérifiés ; +- `12` deltas et `12` histories `0.0.1` appariés exactement ; +- chaîne PASS/FAIL/fix cohérente jusqu'à `rel.001` PASS ; +- plan `0.0.1` clôturé, roadmap/changelog cohérents et prompt `0.0.2` présent ; +- compteurs internes des documents vivants cohérents avec les opérations de deltas observées. + +Aucun défaut bloquant n'impose de `0.0.1` correctif avant le démarrage de `0.0.2`. + +Une observation non bloquante est conservée dans le plan : le history stable mentionne un contrôle post-tag `publish.001`, mais aucune preuve versionnée correspondante ne peut être déduite de cette archive. `alpha.1` n'invente ni ne reconstruit cette preuve. + +## Cadrage retenu + +`0.0.2` matérialisera d'abord : + +```text +profile model / composition +Rust / Cargo +Java / Maven / Gradle +Android +Rust + Android / JNI +Web / TypeScript / Vite / WASM / Rust server composition +Tauri desktop/mobile +``` + +Les profils suivants sont examinés mais différés de cette release afin d'éviter une taxonomie exhaustive sans nécessité immédiate : + +```text +C / C++ / CMake +PHP / Composer +Python 3 application/package +``` + +Ils restent des candidats futurs et ne sont pas rejetés. + +Les règles cross-cutting ne recevront un propriétaire `800 — architecture` que lorsqu'une règle réellement commune à plusieurs profils n'est pas déjà possédée par un owner général existant. + +## Scope + +REPLACE : + +```text +VERSION +``` + +ADD : + +```text +docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +deltas/0.0.2/alpha.1.md +``` + +DELETE : aucun. + +Aucun manifest de suppression n'est nécessaire. + +## Documents volontairement inchangés + +Les documents suivants ne sont pas modifiés uniquement pour refléter le passage à `0.0.2-alpha.1` : + +```text +README.md +RULES.md +ROADMAP.md +CHANGELOG.md +docs/000-README.md +docs/rules/000-README.md +``` + +Leur contenu courant reste cohérent : la roadmap annonce déjà `0.0.2`, les règles possèdent déjà le framing `alpha.1` et la hiérarchie général → spécifique, et le changelog ne journalise pas les prereleases internes. + +## Validation opérateur + +```bash +test "$(cat VERSION)" = "0.0.2-alpha.1" + +test -f docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +test -f deltas/0.0.2/alpha.1.md + +grep -F 'Plan actif créé pendant `0.0.2-alpha.1`' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F 'Aucun défaut bloquant de gouvernance' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F '### alpha.2 — Rule profile model' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F '### alpha.8 — Tauri desktop/mobile' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md + +grep -F -- '- `( ) 0.0.2`' ROADMAP.md +grep -F 'v0.0.1' prompts/002-V0_0_2_START_PROMPT.md + +git diff --check + +git add VERSION docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md deltas/0.0.2/alpha.1.md + +git diff --cached --check + +git status --short +``` + +La sortie attendue avant ajout du history est : + +```text +M VERSION +A deltas/0.0.2/alpha.1.md +A docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +``` + +Revue opérateur complémentaire : + +- confirmer que l'archive `v0.0.1` utilisée est bien celle téléchargée depuis le tag Gitea déclaré ; +- confirmer que l'absence de `.git` n'est pas traitée comme une anomalie ; +- vérifier que le plan n'introduit aucune règle technologique comme déjà normative ; +- vérifier que les profils différés ne sont ni oubliés ni artificiellement matérialisés ; +- vérifier que `README.md`, `RULES.md`, `ROADMAP.md`, `CHANGELOG.md` et les historiques `0.0.1` ne sont pas modifiés par cette tranche. + +## Transition + +### PASS + +Créer et appliquer séparément `history/0.0.2/alpha.1.md`, committer `alpha.1`, puis seulement préparer `0.0.2-alpha.2` consacré au modèle documentaire et à la composition des profils. + +### FAIL + +Rester dans le scope de cadrage avec `0.0.2-alpha.1.fix.1`. Le fix corrige uniquement les défauts du framing/audit/plan ; aucune règle technologique de `alpha.2+` ne doit y être absorbée. diff --git a/docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md b/docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md new file mode 100644 index 0000000..b20a959 --- /dev/null +++ b/docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md @@ -0,0 +1,193 @@ + + + +# Plan 0.0.2 — premiers profils de règles technologiques + +## Statut + +Plan actif créé pendant `0.0.2-alpha.1` après audit de la baseline stable `v0.0.1` fournie sous forme d'archive ZIP issue du tag Gitea. + +La baseline `v0.0.1` est cohérente pour démarrer `0.0.2`. L'absence de `.git` dans cette archive est normale et n'est pas une anomalie de baseline. + +Le présent plan reste prévisionnel. Il peut être révisé lorsqu'un résultat réel invalide son dimensionnement ou son découpage, conformément aux règles de REPLAN. + +## Mission + +`0.0.2` introduit les premiers profils de règles technologiques réutilisables de PGR sans dupliquer les responsabilités déjà possédées par `RULES.md` et les familles `200`, `300` et `400`. + +La release doit démontrer concrètement la composition : + +```text +GENERAL + ↓ +ecosystem / language + ↓ +platform + ↓ +framework + ↓ +project type / subsystem + ↓ +project-specific / explicit exception +``` + +Un profil matérialisé doit posséder un contenu normatif réel, un scope explicite et un propriétaire documentaire identifiable. Il ne doit pas devenir un catalogue de dépendances ni répéter les règles générales sous une autre forme. + +## Autorité des sources pendant la consolidation + +Pour cette release : + +- l'archive source issue du tag `v0.0.1` est la baseline autoritaire de l'état PGR ; +- `prompts/002-V0_0_2_START_PROMPT.md` est le contrat opératoire de démarrage de `0.0.2` ; +- les corpus de conception externes ou historiques peuvent servir de matière d'analyse, mais ne constituent pas l'état courant du dépôt ; +- aucune règle, décision, version de fichier ou structure absente de la baseline et du prompt ne doit être supposée déjà acquise ; +- chaque proposition réutilisée doit être requalifiée selon les règles PGR actuelles avant de devenir normative. + +## Audit de la baseline `v0.0.1` + +L'inspection de l'archive taggée a constaté : + +- une racine unique `pgr/` ; +- `44` fichiers et `13` répertoires dans l'archive, sans entrée dupliquée ; +- aucune entrée absolue, traversée `..` ou symlink ; +- aucune arborescence `.git`, conformément au contrat des archives de tag ; +- `VERSION` égal exactement à `0.0.1` ; +- aucun cache/build connu, `__pycache__`, `.pyc`, `node_modules`, `target`, `dist` ou secret local distribué ; +- tous les fichiers Markdown avec headers `file/version` cohérents avec leur emplacement ; +- aucun lien Markdown local cassé parmi les liens vérifiés ; +- `12` deltas `0.0.1` et `12` histories correspondants, sans delta ou history orphelin ; +- une chaîne de résultats cohérente : les `FAIL` de `alpha.1`, `alpha.1.fix.1`, `alpha.4` et `rc.1` restent historiques et sont suivis par leurs corrections validées avant progression ; +- la promotion `rel.001` enregistrée `PASS`, le plan `0.0.1` clôturé et le prompt `0.0.2` présent ; +- les compteurs internes `version:` des documents vivants cohérents avec les opérations `ADD`/`REPLACE` observées dans les deltas `0.0.1`. + +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 + +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. + +`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. + +## 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. + +| 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 | + +Les domaines différés restent des candidats légitimes. Leur absence de `0.0.2` ne vaut ni rejet ni interdiction future. + +## Règles de consolidation + +Chaque tranche technologique doit : + +1. repartir des règles générales actuellement applicables ; +2. identifier ce qui est réellement spécifique au profil ; +3. éviter les duplications de gouvernance, documentation et validation générales ; +4. distinguer règle normative, exemple, choix de projet et point encore ouvert ; +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 ; +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. + +## Découpage prévisionnel + +### alpha.1 — Baseline audit and profile sizing + +Auditer intégralement `v0.0.1`, confronter le prompt à l'état réel, inventorier les profils candidats, fixer les domaines inclus/différés et créer le présent plan. + +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. + +Cette tranche doit créer uniquement les propriétaires documentaires réellement nécessaires aux profils suivants ; aucun placeholder vide n'est autorisé. + +### 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. + +### 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. + +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. + +### beta.1 — Profile reconciliation + +Réconcilier les profils créés, vérifier les scopes/overrides, éliminer les répétitions, vérifier la navigation et extraire vers un owner cross-cutting uniquement les règles réellement communes qui ne possèdent pas déjà de propriétaire normatif. + +Aucun nouveau profil technologique majeur ne doit être introduit en beta sans REPLAN. + +### rc.1 — Rule profiles release candidate + +Geler le scope, préparer l'entrée candidate `0.0.2` du changelog, finaliser le prompt `0.0.3` et exécuter la gate documentaire complète applicable. + +### stable — 0.0.2 + +Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer `rel.001`, commit/tag `v0.0.2`, puis vérifier séparément l'archive publiée issue du tag. + +## Dimensionnement et points de replan + +Le découpage privilégie des responsabilités indépendamment validables plutôt qu'un nombre minimal de tranches. + +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. + +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. + +## Hors périmètre + +`0.0.2` ne doit pas : + +- produire les templates techniques réservés à `0.0.3` ; +- 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 ; +- 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. + +## Critères de fermeture + +`0.0.2` peut atteindre RC lorsque : + +- 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 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 ; +- les profils différés ne sont pas artificiellement matérialisés ; +- les validations de la release restent documentaires et proportionnées au dépôt PGR lui-même. diff --git a/history/0.0.2/alpha.1.md b/history/0.0.2/alpha.1.md new file mode 100644 index 0000000..5804795 --- /dev/null +++ b/history/0.0.2/alpha.1.md @@ -0,0 +1,105 @@ + + + +# History 0.0.2-alpha.1 — baseline audit and profile sizing + +## Statut + +FAIL + +Les commandes mécaniques prévues par le delta `alpha.1` ont toutes réussi, mais la revue opérateur a identifié des défauts dans le cadrage lui-même. Comme `alpha.1` est précisément la gate d'audit, de sizing et de planification de `0.0.2`, la tranche ne doit pas être déclarée PASS tant que ces défauts ne sont pas corrigés. + +## Baseline + +Archive source issue du tag stable Gitea : + +```text +v0.0.1 +``` + +Version observée après application du delta : + +```text +0.0.2-alpha.1 +``` + +L'absence de `.git` dans l'archive de baseline reste normale et n'a pas été traitée comme une anomalie. + +## Validation opérateur observée + +Les commandes communiquées par l'opérateur ont réussi : + +```bash +test "$(cat VERSION)" = "0.0.2-alpha.1" + +test -f docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +test -f deltas/0.0.2/alpha.1.md + +grep -F 'Plan actif créé pendant `0.0.2-alpha.1`' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F 'Aucun défaut bloquant de gouvernance' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F '### alpha.2 — Rule profile model' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +grep -F '### alpha.8 — Tauri desktop/mobile' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md + +grep -F -- '- `( ) 0.0.2`' ROADMAP.md +grep -F 'v0.0.1' prompts/002-V0_0_2_START_PROMPT.md + +git diff --check + +git add VERSION docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md deltas/0.0.2/alpha.1.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 est exactement : + +```text +M VERSION +A deltas/0.0.2/alpha.1.md +A docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md +``` + +## Défauts identifiés par revue + +### Tableau Markdown non aligné + +Le tableau `Inventaire des profils candidats` est syntaxiquement lisible par Markdown, mais ses colonnes ne sont pas alignées dans le source. Le défaut est visible immédiatement lors d'une revue et n'a pas été détecté par la gate `alpha.1`. + +Un audit réutilisé en diagnostic depuis les projets sources confirme le défaut sur les quatre colonnes du tableau. + +Ce cas fournit une propriété stable et objectivement automatisable : l'alignement source des tableaux Markdown. Il justifie l'introduction d'un premier audit PGR monotâche et read-only au lieu d'ajouter un contrôle manuel supplémentaire. + +### Sizing trop large + +Le plan initial conservait, après `alpha.1`, sept tranches technologiques `alpha.2` à `alpha.8` avant réconciliation et RC. + +Ce découpage est trop ambitieux pour l'objectif de dimensionnement « une version complète par session », surtout avant d'avoir mesuré le coût réel du premier profil. L'opérateur demande explicitement de privilégier l'exécution correcte du scope retenu plutôt que de matérialiser trop de profils dans `0.0.2`. + +Le fix doit donc réduire le scope initial de la release à un ensemble minimal mais représentatif : modèle de profil, Rust/Cargo, Java/Maven/Gradle et Android. Les compositions Rust+Android/JNI, Web/WASM et Tauri restent candidates mais sont différées. + +### Preuve post-tag `publish.001` déjà disponible + +La revue initiale avait correctement conclu que `publish.001` ne pouvait pas faire partie du tag `v0.0.1`, mais elle n'avait pas retrouvé le rapport post-tag déjà conservé hors du tag. + +Le rapport `pgr-0.0.1-publish.001-report.md` existe dans la bibliothèque de travail et indique `Status: PASS` pour l'archive `pgr-v0.0.1.zip`, avec le SHA-256 attendu. + +Cette preuve ne doit pas être injectée rétroactivement dans le tag stable. Elle doit simplement être reconnue comme preuve post-publication externe à la baseline source. + +La maturité future de PGR devra également permettre aux handoffs/prompts de reprise d'indiquer explicitement si un tel rapport post-publication doit être fourni à la session suivante. Cette amélioration de workflow ne doit toutefois pas élargir `0.0.2`. + +## Conséquence + +`0.0.2-alpha.1` est enregistré en `FAIL`. + +La tranche suivante est `0.0.2-alpha.1.fix.1`, strictement limitée au cadrage de `alpha.1` : + +- corriger le tableau Markdown du plan ; +- reconnaître correctement le rapport post-tag `publish.001` déjà disponible sans modifier `v0.0.1` ; +- réduire le nombre de profils matérialisés dans `0.0.2` ; +- introduire un premier audit Markdown monotâche, read-only et sans dépendance externe, parce qu'un défaut réel vient d'en démontrer la nécessité ; +- enregistrer ce nouvel audit dans la matrice de validation. + +Aucune règle technologique prévue pour `alpha.2+` ne doit être absorbée dans le fix.