pgr/docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md

Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games

Statut et sources

Plan actif créé pendant 0.0.5-alpha.1 conformément à prompts/005-V0_0_5_START_PROMPT.md. La release confronte PGR à deux baselines autoritaires fournies sans présumer qu'elles ont déjà adopté PGR.

Sources contrôlées :

pgr-v0.0.4.zip                         7137bb084f017362323a2043d13ba71490be15b8786adc8d645981bf455b80ae
khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
games-v0.3.5.zip                      5f5fdee1a271386766d059657d6eaa831acdc263b3e722fed738808335c0a105

Le rapport externe pgr-0.0.4-publish.001-report.md est PASS et annonce le même hash pour la stable PGR. L'étude détaillée et les limites de l'environnement sont consignées dans ../studies/001-KSP_GAMES_RECONCILIATION.md.

Mission et garde-fous

0.0.5 doit améliorer PGR à partir des besoins réellement répétés dans KSP et Games sans transformer leurs conventions historiques en règles universelles.

Les deux projets ne sont pas encore gouvernés par PGR. Par conséquent :

• aucune divergence de leurs archives n'est qualifiée de défaut PGR par défaut ;
• aucune migration de KSP ou Games n'appartient au scope de cette release ;
• aucune ancienne tranche, nomenclature ou chaîne history n'est reconstruite rétroactivement ;
• tout nouvel owner PGR doit correspondre à un besoin réutilisable et non à un simple copier-coller de projet ;
• les règles métier, architecture, protocoles, distribution et infrastructure spécifiques restent locales.

Résultat du cadrage alpha.1

L'audit classe la majorité des mécanismes de gouvernance, documentation, validation et Rust/Cargo comme déjà OWNED par PGR. Les améliorations candidates réellement communes sont bornées à quatre axes :

1. prompt de démarrage de projet : le contrat actuel de 210-WORKFLOW.md est plus minimal que les prompts opératoires éprouvés dans les deux corpus ;
2. contrats documentaires locaux : les deux projets utilisent un registre de responsabilités de fichiers/familles qui peut devenir un pattern facultatif de la fondation ;
3. façade Rust et export completeness : les deux projets partagent pratiquement le même audit spécialisé, alors que PGR n'en fournit pas encore de version réutilisable ;
4. Tauri : le framework est utilisé indépendamment et de manière répétée dans les deux corpus, ce qui fournit enfin une base réelle pour activer la famille framework 700 sans généraliser Vite/Web/JNI au-delà des preuves disponibles.

Les audits composites, le Web autonome, WASM, JNI, règles serveur, distribution Games et frontières métier KSP restent différés ou locaux.

REPLAN alpha.4 — lifecycle inter-release et horizon

La gate alpha.3.fix.1 a validé son correctif local. Une revue séparée du plan, de ROADMAP.md et des historiques de conception PGR 0.0.1 à 0.0.4 a ensuite confirmé un besoin général non couvert explicitement par le forecast initial : PGR sait piloter une release active, mais n'assigne pas encore assez strictement où/quand sa fermeture et sa transition sont préparées, ni quand l'horizon des versions futures doit être rediscuté.

Les historiques montrent que plusieurs briques avaient déjà été décidées séparément — moment du CHANGELOG, ROADMAP, prompt suivant, REPLAN, abandon/supersession, continuation inter-session, handoff et distinction rel.001/publish.001. Le problème n'est donc pas d'inventer un second workflow, mais de les relier dans le contrat du plan et d'éviter qu'elles restent implicites.

Ce constat déclenche le point de décision REPLAN prévu par alpha.1. Aucun travail antérieur n'est invalidé. Les anciennes tranches alpha.4 à alpha.6 sont décalées d'un numéro et restent dans le scope.

Trajectoire prévisionnelle

alpha.1 — audit indépendant, étude et plan

Vérifier la stable PGR, son rapport post-tag et les deux archives externes ; exécuter les audits statiques disponibles ; classifier les écarts ; créer l'étude et le présent plan. Aucun changement normatif, script réutilisable, profil framework ou skeleton nouveau dans cette tranche.

alpha.2 — contrat générique des prompts de démarrage

Renforcer l'owner 210-WORKFLOW.md pour les prompts versionnés sans recopier les règles locales KSP/Games. Fournir une spécification réutilisable couvrant au minimum : baseline autoritaire, ordre de lecture, état déjà validé, mission/résultat, scope/hors-scope, décisions gelées/ouvertes, première gate, trajectoire prévisionnelle et validations.

Le template manuel 003-NEW_SESSION_PROMPT.md reste distinct : il sert au court message remis après publication, alors que cette tranche porte le prompt versionné du projet.

alpha.3 — pattern de contrats de fichiers/familles

Étendre 300-DOCUMENTATION.md et la fondation 001 uniquement si nécessaire pour décrire un registre local facultatif des fichiers ou familles dont le rôle et les règles de modification méritent d'être explicites. Fournir une spécification/template documentaire courte plutôt qu'un catalogue universel.

Le pattern ne doit pas imposer FILE_CONTRACTS.md à un petit projet, ni recopier les rôles déjà possédés par PGR. Le correctif alpha.3.fix.1 a en outre renforcé l'audit des tables Markdown fenced sans modifier ce scope fonctionnel.

alpha.4 — REPLAN : clôture, transition et revue d'horizon

Formaliser le lifecycle inter-release qui manquait au plan initial :

• imposer à un plan de release suffisamment complexe d'attribuer noir sur blanc les responsabilités de clôture/transition ;
• définir la revue d'horizon sans imposer un nombre artificiel de versions futures ;
• expliciter le passage idea/study → décision durable → roadmap/plan ;
• confirmer qu'une discussion stratégique peut vivre dans une session séparée sans changer VERSION ;
• rendre spontané le message manuel de reprise lorsque la prochaine cible est connue ;
• permettre la livraison history courant + delta suivant dans une même réponse lorsque la suite est déterministe, tout en maintenant deux archives et l'ordre commit/apply ;
• fournir un pattern réutilisable de plan de release pour l'adoption future dans KSP, Games et d'autres projets.

Cette tranche ne commence pas l'audit Rust ni le profil Tauri.

alpha.5 — audit Rust de façade/export completeness

Extraire le noyau réellement commun de audit_rust_export_completeness.py, l'aligner avec 510-RUST_CARGO.md, documenter son caractère facultatif et ses limites, et ajouter des tests positifs/négatifs.

Cette tranche ne réimporte pas audit_rust_general_rules.py en bloc. Toute règle déjà possédée par Rustfmt, Clippy, le compilateur ou les audits PGR existants reste chez son owner actuel.

alpha.6 — premier profil framework : Tauri

Si la revue de alpha.1 reste confirmée, activer la famille 700 — frameworks et créer un profil Tauri fondé uniquement sur les invariants communs aux deux corpus : composition avec Rust/Cargo, ownership du build Tauri, hooks frontend, version produit, artefacts générés, configuration sensible et gates de développement/build.

Les versions exactes de dépendances, ports, fenêtres, plugins, bundles et chemins applicatifs restent des décisions destinataire. Vite/Web/WASM n'entrent pas automatiquement dans ce profil.

alpha.7 — décision de skeleton Tauri

Vérifier si le profil Tauri obtenu permet une skeleton specification utile sans créer de tauri.conf.json universel. Si oui, ajouter une specialization composable au-dessus de 001 + 002 + 700/710. Sinon, consigner explicitement le report et ne pas matérialiser un skeleton décoratif.

beta.1 — réconciliation intégrée

Rejouer la matrice de l'étude sur l'état PGR obtenu. Vérifier : owner unique, navigation, absence de règles KSP/Games aspirées par accident, caractère facultatif des patterns/audits concernés, cohérence des skeletons et domaines encore différés.

Cette tranche réconcilie aussi la documentation durable et vérifie que le présent plan possède un contrat de fermeture exécutable. Le prompt 006 vers 0.1.0 peut être préparé ici si la mission 0.1.0 reste suffisamment connue.

rc.1 — scope gelé et gate candidate

Geler le scope de 0.0.5, préparer l'entrée candidate du changelog, vérifier ROADMAP.md, finaliser/vérifier le prompt 006-V0_1_0_START_PROMPT.md si 0.1.0 reste la cible retenue et rejouer les tests/audits PGR ainsi que les validations ciblées des nouveaux scripts/templates/profils réellement livrés.

Aucune version postérieure à 0.1.0 n'est inventée à cette étape.

stable — 0.0.5

Promouvoir mécaniquement la RC validée : synchroniser VERSION, README/index, ROADMAP.md, CHANGELOG.md et statut du présent plan sans ajouter de nouveau besoin commun. Après history PASS, commit et tag v0.0.5, vérifier séparément l'archive publiée.

La vérification post-tag doit produire, si le mécanisme reste retenu, pgr-0.0.5-publish.001-report.md extérieur au tag. Le message manuel final doit alors indiquer spontanément à l'opérateur de fournir l'archive taggée et ce rapport avec le prompt 006 lors de la session 0.1.0.

Clôture et transition

Le présent plan attribue dès maintenant les responsabilités de fermeture :

• la documentation directement liée à chaque capacité évolue dans sa tranche ;
• beta.1 réalise la réconciliation durable globale et prépare le prompt suivant si sa mission est connue ;
• rc.1 porte le scope freeze, l'entrée CHANGELOG candidate, la vérification ROADMAP et le prompt suivant candidat ;
• rel.001/stable finalise CHANGELOG, marque 0.0.5 terminée dans ROADMAP, ferme le présent plan et effectue le promotion gate pré-tag ;
• publish.001 vérifie l'archive réellement produite après le tag et fournit la preuve externe requise par la reprise suivante ;
• aucune de ces opérations ne doit être repoussée implicitement à la session 0.1.0.

Revue d'horizon

Pour PGR, la prochaine release engagée est 0.1.0 — première baseline réutilisable. La trajectoire au-delà n'est pas suffisamment décidée et reste volontairement ouverte ; ce n'est pas un défaut de roadmap.

0.0.5 ne doit donc pas inventer 0.1.1, 0.2.0 ou un catalogue de versions futures. Le plan de 0.1.0-alpha.1 devra en revanche identifier un moment de revue d'horizon avant sa fermeture, une fois la baseline réutilisable suffisamment concrète pour juger la suite. Cette revue pourra se tenir dans une session stratégique séparée sans modifier VERSION.

Ses sorties autorisées seront : étendre la roadmap avec des objectifs réellement décidés, maintenir l'horizon ouvert avec un prochain déclencheur, différer/mettre en pause la trajectoire ou constater qu'un objectif macro est accompli.

Points de décision

Un REPLAN est requis si :

• le contrat de prompt devient une copie exhaustive des règles plutôt qu'un artefact de reprise ;
• le pattern de contrats de fichiers ajoute plus de cérémonie qu'il n'en retire ;
• le lifecycle de clôture impose des documents ou versions futures sans valeur opérationnelle ;
• la revue d'horizon devient un quota de versions à prévoir plutôt qu'un mécanisme de décision ;
• l'audit de façade Rust ne peut pas être séparé proprement des conventions strictes KSP/Games ;
• le profil Tauri exige de choisir arbitrairement Vite, WASM, des plugins ou un layout d'application ;
• le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework ;
• une autre divergence des corpus apparaît comme un besoin commun critique non couvert par ce plan.

Stratégie de validation

Les tranches documentaires rejouent les trois audits Markdown et la suite Python PGR. Toute modification d'un script ajoute ou adapte des tests ciblés avant la suite globale. Les templates/configurations structurées sont parsés ou exercés avec l'outil le plus fiable disponible.

PGR ne compile pas KSP ou Games comme gate de sa propre release : ces projets servent de corpus de pression. Une validation croisée MAY exécuter leurs audits statiques sur leurs archives fournies lorsque cela vérifie une propriété précise, mais ne remplace jamais leurs propres gates opérateur.

La toolchain Cargo n'étant pas disponible dans l'environnement de préparation de alpha.1, aucune preuve Cargo externe n'est revendiquée pour cette tranche. La gate PGR reste documentaire et structurelle.