# 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 "" git push origin ``` 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. Deux horizons supplémentaires sont acquis comme **candidats différés**, sans numéro réservé : - après application réelle de PGR à Games puis KSP, une release `0.1.x` non prioritaire pourra introduire des audits Python read-only reproduisant uniquement le sous-ensemble des conventions Rust/Clippy vérifiable statiquement sans Cargo ni `rustc`; ces audits devront utiliser les options PGR existantes, documenter explicitement les lints `FULL / LIMITED / UNSUPPORTED` et MUST NOT être présentés comme équivalents à `cargo clippy`, qui reste la validation autoritaire ; - à plus long terme, une série dédiée au déploiement et à l'exploitation devra être étudiée, potentiellement dans un horizon `0.4.x` ou `0.5.x` mais sans réservation actuelle : reverse proxies tels que Nginx/Apache, bases PostgreSQL/MySQL ou autres, conteneurs Docker/Compose, hébergement Linux/services, environnements et secrets, migrations/backup, health/observabilité et skeletons/audits de déploiement composables. Ces horizons ne modifient pas la mission de `0.1.0` et ne doivent pas être absorbés par les tranches courantes. ## Trajectoire prévisionnelle de `0.1.0` ### alpha.1 — audit de stable et plan Statut opérateur : **PASS**. La stable `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées ont été vérifiés. Le cadrage a été consigné sans changement normatif ni migration externe. ### alpha.2 — clôture stable et identité `rel.N` Statut opérateur : **FAIL**. Le contenu normatif prévu a été matérialisé et le contrôle structurel spécifique a confirmé `rel.N` sans padding, la conservation des historiques `rel.001*` et l'identité explicite du commit stable. La gate livrée contenait toutefois des commandes `grep -F` entourées de quotes simples alors que certains motifs contenaient eux-mêmes des apostrophes (`n'utilise`, `l'exploitation`). Le shell a donc mal interprété plusieurs contrôles textuels. Le défaut appartient à la gate opérateur, pas aux owners `200-GOVERNANCE` / `210-WORKFLOW`. Le delta `alpha.2.md` reste immuable. ### alpha.2.fix.1 — correction de la gate `rel.N` Corriger uniquement la validation de `alpha.2` : - conserver `200-GOVERNANCE.md` et `210-WORKFLOW.md` inchangés ; - remplacer les assertions shell fragiles par une vérification Python syntaxiquement sûre ; - rejouer la suite Python complète, les audits Markdown et la preuve structurelle ; - conserver le `FAIL` de `alpha.2` avant toute progression. Après PASS de ce fix, reprendre la trajectoire normale à `alpha.3`. ### 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.