107 lines
7.9 KiB
Markdown
107 lines
7.9 KiB
Markdown
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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 :
|
|
|
|
```text
|
|
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`](../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.
|
|
|
|
## 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.
|
|
|
|
### alpha.4 — 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.5 — 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.6 — 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.
|
|
|
|
### rc.1 — scope gelé et gate candidate
|
|
|
|
Geler le scope de `0.0.5`, préparer l'entrée candidate du changelog et le prompt `006` de la release suivante si sa mission est suffisamment connue. Rejouer les tests/audits PGR et les validations ciblées des nouveaux scripts/templates/profils réellement livrés.
|
|
|
|
### stable — 0.0.5
|
|
|
|
Promouvoir mécaniquement la RC validée : synchroniser `VERSION`, README/index, ROADMAP, CHANGELOG et statut du 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.
|
|
|
|
## 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 ;
|
|
- 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.
|