Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.0-alpha.5

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-26 20:33:53 +02:00
parent e4b5992266
commit a65a183ee4
12 changed files with 656 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Plan 0.1.0 — première baseline PGR réutilisable
@@ -205,19 +205,26 @@ La validation a exécuté `48/48` tests et les trois audits Markdown sans diagno
### alpha.4 — adoption d'un projet existant
Statut opérateur : **à valider**.
Statut opérateur : **PASS**.
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.
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.
Le nouvel owner `230-ADOPTION.md` doit distinguer explicitement adoption et instanciation par skeleton. Le pattern `007-EXISTING_PROJECT_ADOPTION.md` doit fournir une forme réutilisable sans devenir un manifest obligatoire.
Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet ni migrer effectivement ces dépôts dans `0.1.0`.
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
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.
Statut opérateur : **à valider**.
Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche.
Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Le contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` distingue explicitement :
```text
NEW instanciation temporaire réelle des templates avec Cargo
ADOPTION mapping non destructif d’un workspace existant
```
La gate doit exercer le mode `NEW` avec `cargo metadata`, `cargo fmt`, `cargo check` et `cargo clippy`, puis exercer le mode `ADOPTION` sur une baseline synthétique différente des templates et prouver que les décisions `KEEP-LOCAL` / `DEFER` ne sont pas écrasées.
Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche. Games et KSP ne sont pas utilisés comme fixtures du dry-run.
### beta.1 — réconciliation finale et revue d'horizon