0.0.2-alpha.1

docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md

@@ -0,0 +1,193 @@
+<!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md -->
+<!-- version: 1 -->
+
+# 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.