pgr/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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.

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 :

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 :

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 : PASS.

La gate opérateur a confirmé le scope gelé, les huit histories antérieurs avec leurs statuts réels, les deux dry-runs Rust/Cargo via la toolchain réelle, le contrat d’adoption, la convention rel.N, le handoff opérateur, la roadmap et le prompt 007. Les 48/48 tests et les trois audits Markdown sont propres. Aucun owner ni domaine technique nouveau n’est entré dans la RC.

rel.1 — promotion stable

Première utilisation de la convention corrigée rel.1. La promotion est strictement mécanique : VERSION = 0.1.0, ROADMAP.md marque 0.1.0 terminée, le CHANGELOG perd son marqueur candidate, README/index décrivent la baseline comme stable et le présent plan devient historique. Aucun owner, profil, template, skeleton ou script technique n’est modifié.

Le résultat opérateur de cette tranche appartient à history/0.1.0/rel.1.md, créé seulement après exécution de la gate. Si rel.1 échoue, son history est conservé et un rel.1.fix.N corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit 0.1.0 avant le tag v0.1.0. La vérification post-tag reste séparée et doit produire pgr-0.1.0-publish.001-report.md uniquement à partir de l’archive et des preuves réellement publiées.

Stratégie de validation

Chaque tranche documentaire rejoue au minimum :

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.