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.

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 :

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.