0.1.0-alpha.1

docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md

@@ -0,0 +1,257 @@
+<!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
+<!-- version: 1 -->
+
+# Plan 0.1.0 — première baseline PGR réutilisable
+
+## Statut et sources
+
+Plan actif créé pendant `0.1.0-alpha.1` conformément à `prompts/006-V0_1_0_START_PROMPT.md` après audit indépendant de la stable taggée `v0.0.5` et de son rapport post-tag.
+
+Sources autoritaires de reprise :
+
+```text
+pgr-v0.0.5.zip                       1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49
+pgr-0.0.5-publish.001-report.md      a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96
+```
+
+Le rapport `publish.001` est `PASS` et porte sur cette même archive. L'absence de `.git` dans l'archive du tag est normale et n'est pas une validation manquante.
+
+Deux corpus récents ont également été fournis pour préparer l'adoption future sans devenir des dépendances de la baseline `0.1.0` :
+
+```text
+games-v0.3.6.zip                     ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
+```
+
+Games `0.3.6` conserve explicitement `0.3.7` comme future release d'alignement PGR. KSP `0.3.16` reste principalement un corpus Rust/Cargo avec six applications Tauri ; aucune migration de Games ou KSP n'appartient à `0.1.0`.
+
+## Audit de la stable `v0.0.5`
+
+### Intégrité et chaîne historique
+
+L'archive stable contient `225` entrées sous une racine unique `pgr/`, soit `194` fichiers et `31` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
+
+Les `62` couples delta/history des releases `0.0.1` à `0.0.5` sont complets :
+
+```text
+0.0.1  12 / 12
+0.0.2  12 / 12
+0.0.3  10 / 10
+0.0.4   9 / 9
+0.0.5  19 / 19
+```
+
+La vérité opérateur de `0.0.5` est conservée, notamment les `FAIL` intermédiaires et la fermeture finale `rel.001.fix.1` en `PASS`. Aucun ancien delta/history ne sera renommé rétroactivement lorsque la nouvelle convention `rel.N` sera introduite.
+
+### Tests et audits
+
+La stable passe :
+
+```text
+python3 -B -m unittest discover -s tests -v
+48 tests PASS
+
+Markdown header audit: clean (171 file(s))
+Markdown table audit:  clean (8 table(s), 171 file(s))
+Markdown link audit:   clean (161 local link(s), 171 file(s))
+```
+
+Les audits PGR restent monotâches et read-only : trois audits Markdown, six audits de style Rust, un audit Rust de façade/export completeness, plus leur helper commun. Aucun audit ne devient un wrapper de build.
+
+### Règles, profils, templates et skeletons
+
+La hiérarchie normative est cohérente et possède un owner explicite pour gouvernance, workflow, skeletons, documentation, validation, langages/écosystèmes, plateformes et frameworks.
+
+Profils techniques déjà matérialisés :
+
+```text
+510  Rust / Cargo
+520  Java / Maven / Gradle
+610  Android
+710  Tauri 2
+```
+
+La baseline possède cinq templates techniques Rust/Cargo sous `templates/rust-cargo/`, deux skeleton specifications concrètes — fondation de gouvernance et workspace Rust/Cargo — et les contrats de validation associés.
+
+Le profil Rust/Cargo est suffisamment avancé pour servir rapidement de référence à Games et KSP. Les profils Java/Gradle et Android existent déjà normativement ; leur future release `0.1.x` devra donc d'abord réévaluer leur complétude pratique, leurs templates, skeletons et audits nécessaires au cas Games au lieu de recréer les profils depuis zéro.
+
+Le profil Tauri `710` existe également, mais le skeleton Tauri contrôlé reste volontairement `DEFER` : il attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS, sorties frontend et validation frontend indépendante.
+
+## Défauts de gouvernance à corriger en 0.1.0
+
+L'audit ne révèle pas de défaut bloquant de la stable, mais deux conventions doivent être corrigées avant de diffuser PGR plus largement.
+
+### Clôture stable `rel.N`
+
+L'expérience réelle de `0.0.5` montre que la convention actuelle `rel.001` mélange inutilement padding historique et identité de tranche. La convention future doit utiliser :
+
+```text
+rel.1
+rel.1.fix.1
+rel.2
+...
+```
+
+Les anciens fichiers `rel.001*` restent immuables.
+
+Le nom de tranche et le message du commit qui matérialise finalement la stable doivent être distingués. Par défaut PGR :
+
+```text
+rel.1 FAIL              -> commit de tranche X.Y.Z-rel.1
+rel.1.fix.1 FAIL        -> commit de tranche X.Y.Z-rel.1.fix.1
+première tranche qui obtient le PASS stable
+                         -> commit final X.Y.Z
+```
+
+Le tag `vX.Y.Z` n'est créé qu'après ce commit final stable.
+
+### Commandes opérateur et publication
+
+Après production d'un history constaté, le générateur doit remettre spontanément les commandes exactes à exécuter entre l'application de ce history et le delta suivant. Le défaut PGR retenu est :
+
+```bash
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "<message attendu>"
+git push origin <branche>
+```
+
+Le bloc doit être adapté au projet et au statut réel de la tranche ; il ne doit pas inventer une branche ou un remote lorsqu'ils ne sont pas établis.
+
+Pour la dernière clôture pré-tag, le handoff opérateur doit en plus fournir le bloc de tag/vérification approprié et indiquer explicitement les preuves/artefacts à remettre pour générer la vérification post-tag, notamment l'archive issue du tag et les preuves Git réellement disponibles. Un tag annoté doit être vérifié sans confondre l'objet tag avec son commit déréférencé.
+
+Après `publish.* PASS`, la consigne manuelle de nouvelle session reste produite automatiquement selon `docs/templates/003-NEW_SESSION_PROMPT.md`.
+
+## Mission de `0.1.0`
+
+`0.1.0` doit transformer la fondation `0.0.x` en baseline réellement réutilisable **sans absorber les domaines technologiques futurs**.
+
+La release doit :
+
+1. corriger la sémantique de clôture `rel.N` et des commits stables ;
+2. rendre obligatoire le handoff automatique des commandes opérateur après chaque history et lors de la publication ;
+3. formaliser une adoption proportionnée de PGR par un projet existant, distincte de l'instanciation d'un nouveau projet ;
+4. vérifier que la fondation et le skeleton Rust/Cargo peuvent servir de baseline réutilisable sans dépendre de choix KSP/Games ;
+5. effectuer avant RC une revue d'horizon qui engage uniquement les prochaines releases `0.1.x` suffisamment décidées.
+
+`0.1.0` ne crée pas de profil Web, WASM, serveur Rust/Actix, Java, Android ou Tauri supplémentaire. Ces domaines seront traités séparément dans la série `0.1.x` lorsque leur release dédiée sera engagée.
+
+## Direction acquise pour la série `0.1.x`
+
+La série `0.1.x` doit rester composée de releases concrètes indépendantes, en pratique une release/session par domaine cohérent. Il est explicitement exclu de regrouper Web, serveur Rust, Java/Android, Tauri et WASM dans `0.1.0` ou dans une unique grosse release suivante.
+
+La revue d'horizon de `0.1.0` devra ordonner et, seulement lorsque le scope est suffisamment décidé, numéroter les axes suivants :
+
+- owners Web contrôlés : TypeScript, Vite, Sass/CSS, package manager/build outputs et validation frontend ;
+- serveur Web Rust — Actix Web ou autre framework seulement à partir d'un besoin et d'un corpus réels, notamment pour les trajectoires HTTP/3 ;
+- réévaluation pratique du profil Java/Gradle existant pour Games ;
+- réévaluation pratique du profil Android existant pour Games ;
+- WASM comme domaine séparé si l'adoption Games démontre qu'un owner PGR apporte une valeur immédiate ;
+- levée du `DEFER` Tauri seulement après matérialisation des owners Web nécessaires ;
+- adoption de PGR par Games dès que le sous-ensemble requis est réellement prêt ;
+- adoption de PGR par KSP ensuite, avec une pression principalement Rust/Cargo + Tauri et sans attendre les profils non pertinents pour KSP.
+
+Les numéros exacts `0.1.1`, `0.1.2`, etc. ne sont pas réservés dans `alpha.1`. Cette attribution appartient à la revue d'horizon lorsque l'ordre réel est suffisamment décidé.
+
+Après cette vague d'adoption `0.1.x`, les axes plus larges — projets documentaires/spécifications tels que `saselang-bible`, généricité hors logiciel et autres familles technologiques — restent candidats pour une trajectoire `0.2.x`/`0.3.x` à décider ultérieurement, sans réservation artificielle aujourd'hui.
+
+## Trajectoire prévisionnelle de `0.1.0`
+
+### alpha.1 — audit de stable et plan
+
+Vérifier intégralement `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées. Consigner le cadrage présent sans changement normatif ni migration externe.
+
+### alpha.2 — clôture stable et identité `rel.N`
+
+Modifier les owners de gouvernance/workflow nécessaires pour :
+
+- remplacer la convention future `rel.001` par `rel.1` ;
+- préserver l'immutabilité des anciennes releases ;
+- définir le message de commit des tranches de clôture échouées ;
+- définir que le commit qui obtient finalement le `PASS` stable se nomme `X.Y.Z` par défaut avant création de `vX.Y.Z`.
+
+Aucun changement technologique dans cette tranche.
+
+### alpha.3 — handoff automatique des commandes opérateur
+
+Formaliser le bloc de commandes remis après chaque history, l'ordre commit/push avant application du delta suivant, les commandes supplémentaires de tag pour une stable validée et la liste des preuves à fournir pour produire le rapport post-tag.
+
+Créer ou adapter un template documentaire uniquement si cela évite de dupliquer ces commandes dans chaque delta.
+
+### alpha.4 — adoption d'un projet existant
+
+Formaliser une méthode courte d'adoption PGR pour un dépôt existant : audit de la baseline réelle, mapping des owners applicables, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, migration progressive et interdiction de réécrire l'historique uniquement pour le rendre rétroactivement conforme.
+
+Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet.
+
+### alpha.5 — baseline réutilisable et dry-run de composition
+
+Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Effectuer un dry-run documentaire/structurel d'instanciation et d'adoption afin de vérifier qu'un nouveau projet Rust et un projet Rust existant peuvent sélectionner les owners utiles sans dépendre de KSP/Games.
+
+Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche.
+
+### beta.1 — réconciliation finale et revue d'horizon
+
+Stabiliser la baseline `0.1.0`, vérifier les documents durables et effectuer la revue d'horizon obligatoire. Cette revue décidera les prochaines releases `0.1.x` à réellement inscrire dans `ROADMAP.md`, une par domaine cohérent, en privilégiant la préparation rapide de Games puis KSP.
+
+Le prompt de la prochaine version n'est créé que lorsque cette revue a effectivement fixé la cible suivante.
+
+### rc.1 — release candidate
+
+Geler le scope, produire l'entrée candidate de `CHANGELOG.md`, exécuter le release gate complet applicable, vérifier le prompt/handoff suivant et confirmer que les changements `rel.N`/commandes opérateur sont exercés par les artefacts de la release elle-même.
+
+### rel.1 — promotion stable
+
+Première utilisation de la convention corrigée `rel.1`. La promotion reste mécanique et proportionnée. Si `rel.1` échoue, le history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est committée sous `0.1.0` avant le tag `v0.1.0`.
+
+## Stratégie de validation
+
+Chaque tranche documentaire rejoue au minimum :
+
+```text
+python3 -B -m unittest discover -s tests -v
+python3 -B scripts/audit_markdown_headers.py ...
+python3 -B scripts/audit_markdown_tables.py ...
+python3 -B scripts/audit_markdown_links.py ...
+```
+
+Les scripts d'audit restent read-only et ne déclenchent aucun build. Les changements de workflow doivent recevoir des contrôles structurels ciblés qui vérifient la nomenclature future sans imposer de renommer les snapshots historiques.
+
+Le dry-run de composition `alpha.5` doit privilégier les parsers/outils officiels lorsque disponibles. Une prévalidation générateur ne remplace pas le gate opérateur.
+
+## Déclencheurs de REPLAN
+
+REPLAN est requis si :
+
+- `0.1.0` commence à absorber Web, Android, WASM, Actix ou le skeleton Tauri au lieu de les laisser à des releases `0.1.x` distinctes ;
+- la convention de commit stable ne peut pas être définie sans ambiguïté avec les histories `FAIL`/fix ;
+- le handoff automatique dépend de valeurs Git qui ne peuvent pas être établies de manière sûre ;
+- l'adoption d'un projet existant exige de modifier rétroactivement son historique ;
+- le dry-run révèle que la fondation ou le skeleton Rust/Cargo n'est pas réellement autonome ;
+- la revue d'horizon transforme des candidats en numéros réservés sans scope suffisamment décidé.
+
+## Clôture et transition
+
+- documentation durable du workflow : `alpha.2` à `alpha.4` ;
+- preuve de réutilisabilité : `alpha.5` ;
+- réconciliation documentaire et revue d'horizon : `beta.1` ;
+- `CHANGELOG` candidate et release gate : `rc.1` ;
+- promotion stable et nouveau contrat `rel.1` : `rel.1` ;
+- tag/post-tag : après le commit stable `0.1.0`, avec handoff opérateur automatique ;
+- prompt suivant : créé uniquement si `beta.1` a réellement engagé la prochaine cible `0.1.x`.
+
+## Revue d'horizon
+
+État : **requise**.
+
+Moment : `beta.1`, après preuve de réutilisabilité et avant RC.
+
+Sorties autorisées :
+
+- engager une ou plusieurs prochaines releases `0.1.x`, chacune avec un seul domaine cohérent ;
+- conserver certains axes comme `DEFER` ou candidats sans numéro ;
+- ordonner Games avant KSP lorsque les owners requis le permettent ;
+- lever le `DEFER` Tauri uniquement si les owners Web requis existent réellement ;
+- repousser WASM ou serveur Rust si leur normalisation n'apporte pas encore assez de valeur ;
+- conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure sans l'inventer prématurément.