0.1.0-beta.1

docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Plan 0.1.0 — première baseline PGR réutilisable
 
@@ -213,24 +213,34 @@ Games et KSP restent des futurs consommateurs : aucune migration externe ni acti
 
 ### alpha.5 — baseline réutilisable et dry-run de composition
 
-Statut opérateur : **à valider**.
+Statut opérateur : **PASS**.
 
-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 :
+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 :
 
 ```text
-NEW       instanciation temporaire réelle des templates avec Cargo
-ADOPTION  mapping non destructif d’un workspace existant
+NEW       PASS — metadata/fmt/check/clippy sur instanciation temporaire
+ADOPTION  PASS — workspace synthétique valide et choix KEEP-LOCAL / DEFER préservés
 ```
 
-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.
+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
 
-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.
+Statut opérateur : **à valider**.
 
-Le prompt de la prochaine version n'est créé que lorsque cette revue a effectivement fixé la cible suivante.
+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 :
+
+```text
+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
 
@@ -278,15 +288,17 @@ REPLAN est requis si :
 
 ## Revue d'horizon
 
-État : **requise**.
+État : **matérialisée en `beta.1`, à valider par la gate opérateur**.
 
-Moment : `beta.1`, après preuve de réutilisabilité et avant RC.
+Décision proposée par la revue :
 
-Sorties autorisées :
+- 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`.
 
-- 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.
+La revue complète et ses critères de réouverture sont possédés par `../studies/003-V0_1_0_HORIZON_REVIEW.md`.