# 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` Statut opérateur : **PASS**. Le fix a conservé `200-GOVERNANCE.md`, `210-WORKFLOW.md` et le delta historique `alpha.2.md` inchangés. La preuve Python corrigée a reconfirmé la convention `rel.N`, le `FAIL` historique de `alpha.2`, les anciens artefacts `rel.001*` et l'indépendance de `publish.001`. La validation a exécuté `48/48` tests et les trois audits Markdown sans diagnostic. Aucun nouveau fix ni REPLAN n'est requis. ### alpha.3 — handoff automatique des commandes opérateur Statut opérateur : **FAIL**. Le contenu prévu a été matérialisé : `210-WORKFLOW.md` possède le contrat normatif de remise automatique et `006-OPERATOR_COMMAND_HANDOFF.md` fournit la forme de rendu pour tranche ordinaire, échec + fix, clôture stable, tag et preuves `publish.*`. Les `48` tests et les trois audits Markdown sont restés propres. La gate spécifique n'a toutefois pas pu s'exécuter jusqu'au bout : le littéral Python `'## Fermeture d'une tranche non stable'` utilisait des quotes simples autour d'un texte contenant l'apostrophe de `d'une`, provoquant `SyntaxError: unterminated string literal`. Le défaut appartient à la gate ; aucun défaut normatif du workflow ou du template n'est établi. ### alpha.3.fix.1 — correction de la gate du handoff opérateur Statut opérateur : **PASS**. Le fix a conservé `210-WORKFLOW.md`, `006-OPERATOR_COMMAND_HANDOFF.md`, l'index documentaire et le delta historique `alpha.3.md` inchangés. La gate corrigée a reconfirmé le `FAIL` historique de `alpha.3`, le contenu normatif du handoff et le pattern opérateur. La validation a exécuté `48/48` tests et les trois audits Markdown sans diagnostic. Aucun nouveau fix ni REPLAN n'est requis. ### alpha.4 — adoption d'un projet existant Statut opérateur : **PASS**. Le nouvel owner `230-ADOPTION.md` et le pattern `007-EXISTING_PROJECT_ADOPTION.md` ont été validés avec le mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, la migration progressive et la préservation de l’historique. Les `48` tests et les trois audits Markdown sont propres. Games et KSP restent des futurs consommateurs : aucune migration externe ni activation de profils non applicables n’a été introduite. ### alpha.5 — baseline réutilisable et dry-run de composition Statut opérateur : **PASS**. La fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale ont été réconciliés. Les deux chemins du contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` ont été exécutés avec Cargo : ```text NEW PASS — metadata/fmt/check/clippy sur instanciation temporaire ADOPTION PASS — workspace synthétique valide et choix KEEP-LOCAL / DEFER préservés ``` Les `48/48` tests PGR et les trois audits Markdown sont restés propres. Games et KSP n'ont pas été utilisés comme fixtures et aucun profil technologique supplémentaire n'a été absorbé par la tranche. ### beta.1 — réconciliation finale et revue d'horizon Statut opérateur : **PASS**. La gate opérateur a confirmé la revue d'horizon, la roadmap `0.1.1` à `0.1.7`, le maintien des domaines différés sans numéro, le prompt `007` et les `48/48` tests PGR avec les trois audits Markdown propres. La revue d'horizon est matérialisée dans `003-V0_1_0_HORIZON_REVIEW.md`. Elle engage une séquence par domaines cohérents : ```text 0.1.1 Web frontend 0.1.2 Java / Gradle 0.1.3 Android 0.1.4 Tauri contrôlé, sous condition de readiness Web 0.1.5 adoption Games 0.1.6 adoption KSP 0.1.7 audits Rust/Clippy statiques Python-only ``` WASM, serveur Rust et deployment restent non numérotés. Le prompt `007-V0_1_1_START_PROMPT.md` est préparé pour la cible suivante mais ne devient exécutable qu'après publication de `v0.1.0` et vérification post-tag `PASS`. ### rc.1 — release candidate Statut opérateur : **à valider**. Le scope est gelé. La RC produit l'entrée candidate de `CHANGELOG.md`, rejoue la gate d'intégration complète, reconfirme les deux dry-runs Rust/Cargo, vérifie le contrat d'adoption, la convention `rel.N`, le handoff opérateur, la roadmap et le prompt `007`. Aucun owner ni domaine technique nouveau n'entre dans la RC. ### 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 : **validée `PASS` par la gate opérateur de `beta.1`**. Décision proposée par la revue : - engager `0.1.1` Web frontend ; - engager séparément `0.1.2` Java/Gradle et `0.1.3` Android ; - engager `0.1.4` comme release de domaine Tauri, avec obligation de reconfirmer la readiness Web avant toute matérialisation de skeleton ; - engager `0.1.5` pour l'adoption Games puis `0.1.6` pour l'adoption KSP ; - engager `0.1.7` pour les audits Rust/Clippy statiques Python-only après retour réel des deux adoptions ; - conserver WASM et serveur Rust comme candidats sans numéro ; - conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure ; - conserver deployment/operations comme horizon majeur ultérieur sans réserver aujourd'hui `0.4.x` ou `0.5.x`. La revue complète et ses critères de réouverture sont possédés par `../studies/003-V0_1_0_HORIZON_REVIEW.md`.