# Plan 0.0.2 — premiers profils de règles technologiques ## Statut Plan clôturé par la promotion stable `0.0.2` après validation de `0.0.2-rc.1.fix.1`. 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é. ### Preuve post-tag `publish.001` 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`. 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. 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 / ecosystems` | premier profil langage/écosystème, corpus éprouvé | | 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 | | 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 / ecosystems` | corpus utile mais non nécessaire au premier lot | | 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 / 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 | 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 : 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. 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. ## 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 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 à `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 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, 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 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. État observé à l'entrée de beta : ```text alpha.1 FAIL cadrage initial corrigé par fix.1 alpha.1.fix.1 PASS sizing réduit + premier audit Markdown alpha.2 PASS modèle de profils et familles 500/600 alpha.3 PASS Rust / Cargo alpha.4 FAIL incohérence locale entre texte et grep de gate alpha.4.fix.1 PASS cohérence de gate rétablie alpha.5 PASS Android beta.1 FAIL quoting Bash invalide dans une commande de gate beta.1.fix.1 PASS quoting de gate corrigé sans changement de scope ``` Cette synthèse décrit uniquement la trajectoire du plan ; les preuves détaillées restent dans les histories immuables correspondants. La réconciliation beta confirme comme owners technologiques de `0.0.2` : ```text 510-RUST_CARGO.md 520-JAVA_MAVEN_GRADLE.md 610-ANDROID.md ``` Aucune famille `700` ou `800` n'est activée. Aucun profil différé n'est ramené dans le scope. ### 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. Le scope RC est gelé sur les trois profils matérialisés (`510`, `520`, `610`) et les deux audits génériques monotâches (`tables`, `liens locaux`). Aucun nouveau profil, owner de famille ou audit technologique n'est admis sans correction strictement nécessaire ou REPLAN. Le prompt `0.0.3` doit aussi fournir explicitement le texte manuel de nouvelle session et indiquer le rôle du futur rapport post-tag `publish.001`, afin que cette information ne dépende plus d'une demande ad hoc de l'opérateur. ### 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. ## Clôture La release candidate `rc.1` a été enregistrée `FAIL` à cause d'un audit Python inline invalide dans sa gate. `rc.1.fix.1` a corrigé exclusivement cette commande et a ensuite été validée `PASS`, sans changement du scope fonctionnel ou normatif. La promotion stable `rel.001` clôt le plan en mettant à jour uniquement les métadonnées vivantes de release et en préparant le tag `v0.0.2`. Le contrôle post-tag `publish.001` reste une preuve séparée : il doit vérifier l'archive réellement produite depuis le tag et fournir `pgr-0.0.2-publish.001-report.md` à la future session `0.0.3` lorsqu'il est `PASS`. ## Dimensionnement et points de replan 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. Après `alpha.1.fix.1`, le chemin prévu est : ```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 `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` ; - multiplier les audits spécialisés ; `0.0.2` ne matérialise que des audits génériques monotâches justifiés par un besoin réel (`tables` puis `liens locaux`), sans audit technologique artificiel ; - 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 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 ; - 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.