0.0.2-rc.1

docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Plan 0.0.2 — Git générique et synchronisation de lecture
 
@@ -28,7 +28,7 @@ PGR publish report         pgr-0.1.3-publish.001-report.md = PASS
 
 Le passage de PGR `v0.1.1` à `v0.1.3` est traité comme adoption d'un projet existant via `230-ADOPTION`. Les artefacts historiques de `0.0.1` ne sont pas réécrits. `v0.1.3` constitue une provenance d'adoption, pas une dépendance normative vivante : les futurs démarrages Knowledge doivent partir des règles locales et ne consultent PGR que lorsqu'une nouvelle adoption est explicitement engagée.
 
-`0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` a été fermée par `alpha.3.fix.1` `PASS`. `alpha.4` a été fermée par `alpha.4.fix.1` `PASS`, terminant l'adoption PGR comme migration ponctuelle. `alpha.5` est `PASS` et ferme le scope fonctionnel alpha avec `knowledge-app-lib` et le cas d'usage partagé `Changed` / `Unchanged`. `beta.1` est `PARTIAL` : la réconciliation, les audits Rust/Git et la baseline Web passent, mais la gate générée a omis les smokes HTTP requis pendant la stabilisation. `beta.1.fix.1` est `FAIL` : les smokes HTTP sont désormais acquis, mais un `SyntaxError` dans l'audit de stabilisation et une ligne vide supplémentaire à EOF font échouer la gate. `beta.1.fix.2` est la tranche courante et corrige uniquement ces défauts de validation.
+`0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` a été fermée par `alpha.3.fix.1` `PASS`. `alpha.4` a été fermée par `alpha.4.fix.1` `PASS`, terminant l'adoption PGR comme migration ponctuelle. `alpha.5` est `PASS` et ferme le scope fonctionnel alpha avec `knowledge-app-lib` et le cas d'usage partagé `Changed` / `Unchanged`. `beta.1` est `PARTIAL` : la réconciliation, les audits Rust/Git et la baseline Web passent, mais la gate générée a omis les smokes HTTP requis pendant la stabilisation. `beta.1.fix.1` est `FAIL` : les smokes HTTP sont désormais acquis, mais un `SyntaxError` dans l'audit de stabilisation et une ligne vide supplémentaire à EOF font échouer la gate. `beta.1.fix.2` est `PASS` et ferme la stabilisation beta. `rc.1` est la tranche courante : le scope est gelé et seule la validation complète de candidate est autorisée.
 
 ## Mission
 
@@ -255,7 +255,9 @@ Résultat de revue proposé et soumis à la gate beta : aucune prochaine mission
 
 ### rc.1 — candidate stable
 
-Geler le scope fonctionnel de `0.0.2` et exécuter la gate complète de release candidate.
+Statut : **à valider**.
+
+`beta.1.fix.2` est `PASS`. Le scope fonctionnel de `0.0.2` est gelé et la candidate doit exécuter la gate complète de release sans introduire de changement produit.
 
 La RC doit notamment :
 
@@ -313,7 +315,7 @@ Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être
 
 ## Revue d'horizon
 
-État courant : **réalisée dans `0.0.2-beta.1`; contenu et smokes runtime acquis, clôture beta en attente de la gate propre `beta.1.fix.2`**.
+État courant : **réalisée et stabilisation beta fermée par `0.0.2-beta.1.fix.2` `PASS`; `rc.1` en validation candidate**.
 
 Résultat : aucune version postérieure à `0.0.2` n'est réservée. Les domaines futurs restent non numérotés parce qu'aucune mission suivante ne possède encore un scope et un ordre suffisamment décidés.
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 30 -->
+<!-- version: 31 -->
 
 # Matrice de validation Knowledge
 
@@ -797,3 +797,25 @@ Le fix de clôture beta doit prouver :
 - gate interactive ne modifiant pas le shell opérateur avec `set -euo pipefail`.
 
 Le `PASS` de `beta.1.fix.2`, combiné aux preuves runtime `PASS` conservées dans `history/0.0.2/beta.1.fix.1.md`, ferme la stabilisation beta et autorise uniquement `0.0.2-rc.1`.
+
+## Gate de 0.0.2-rc.1
+
+La release candidate gèle le scope et doit rejouer la preuve complète de release :
+
+```text
+CHECK  VERSION/Cargo = 0.0.2-rc.1 et history beta.1.fix.2 PASS
+AUDIT  ensemble exact des deltas/histories 0.0.2 antérieurs
+AUDIT  aucun diff produit sous crates/ ou Web/
+AUDIT  Markdown, hygiène texte à un LF et audits Rust locaux
+FORMAT cargo fmt --all puis cargo fmt --all -- --check avant audits Rust
+CHECK  cargo metadata + cargo check workspace
+LINT   clippy workspace strict -D warnings
+TEST   intégration Git réelle + tests workspace
+BUILD  npm ci + typecheck + build du template lab
+CHECK  manifest Vite de production
+SMOKE  trois launchers : /healthz, / et assets manifest servis en HTTP
+AUDIT  Cargo.lock local/ignoré/non suivi, hors-scope absents, aucune 0.0.3 réservée
+CHECK  git diff --check puis git diff --cached --check
+```
+
+Pendant la gate RC, `deltas/0.0.2/rc.1.md` doit être le seul delta `0.0.2` sans history correspondant. Un `PASS` autorise uniquement `rel.1` ; toute régression fonctionnelle importante impose un retour de phase ou un REPLAN.