0.0.3-rc.1.fix.1

docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Plan 0.0.3 — écriture Git contrôlée et push gardé
 
@@ -217,6 +217,15 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 - vérifier reproductibilité des tests Git d'écriture locaux, intégrité des deltas/histories, Cargo/Clippy/tests et non-régression Web/runtime prévue par la phase ;
 - n'introduire aucune nouvelle fonctionnalité.
 
+### rc.1.fix.1 — correction de la vérification des statuts historiques
+
+- conserver `rc.1 = FAIL` avec la preuve exacte de l'assertion lexicale trop stricte ;
+- ne réécrire aucun history antérieur, en particulier `alpha.1` dont le statut historique est écrit `` `PARTIAL` `` ;
+- normaliser uniquement la lecture du statut lors des gates afin d'accepter la présentation Markdown existante ;
+- ne modifier aucun fichier sous `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/` ou `prompts/` ;
+- rejouer les contrôles documentaires, Cargo/Clippy/tests et la cohérence RC nécessaires à ce fix ;
+- autoriser `rel.1` uniquement après `PASS` complet du fix.
+
 ### rel.1 — promotion stable pré-tag
 
 - promouvoir mécaniquement `VERSION` et le workspace vers `0.0.3` ;
@@ -255,7 +264,7 @@ La release est fermable lorsque :
 - les règles/architecture décrivent l'état effectivement obtenu ;
 - beta et RC ont fermé les non-régressions prévues.
 
-Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. `beta.1` a stabilisé et réconcilié cet état en `PASS`, sans nouveau code produit. La RC doit désormais uniquement confirmer la candidate stable par la gate complète.
+Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. `beta.1` a stabilisé et réconcilié cet état en `PASS`, sans nouveau code produit. `rc.1` a confirmé toutes les preuves produit/runtime mais reste `FAIL` à cause d'une assertion lexicale trop stricte sur le statut historique `alpha.1`. `rc.1.fix.1` doit corriger uniquement cette preuve avant promotion stable.
 
 ## Revue d'horizon
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 38 -->
+<!-- version: 39 -->
 
 # Matrice de validation Knowledge
 
@@ -205,7 +205,7 @@ La release candidate doit prouver :
 - `VERSION = 0.0.3-rc.1` et version workspace identique ;
 - history `history/0.0.3/beta.1.md` présent avec statut `PASS` et committé avant application ;
 - scope produit gelé : aucun diff sous `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/` ou `prompts/` ;
-- tous les histories antérieurs de `0.0.3` présents avec leurs statuts réels et `rc.1.md` seul delta sans history correspondant ;
+- tous les histories antérieurs de `0.0.3` présents avec leurs statuts réels et `rc.1.md` seul delta sans history correspondant ; les contrôles de statut doivent comparer la valeur sémantique après retrait d'un éventuel balisage inline Markdown historique, sans réécrire les histories ;
 - `CHANGELOG.md` toujours en `## 0.0.3 (candidate)` et `ROADMAP.md` conservant `0.0.3` engagée avec l'horizon validé en beta ;
 - handoff `prompts/004-V0_0_4_START_PROMPT.md` présent et toujours sans commit/SHA futur inventé ;
 - `cargo fmt --all`, audits Rust, metadata/check, Clippy strict, tests Git ciblés et tests workspace passent ;
@@ -216,6 +216,21 @@ La release candidate doit prouver :
 
 Un `PASS` autorise uniquement `0.0.3-rel.1`. Toute régression fonctionnelle exige un fix RC borné ou un retour de phase approprié ; aucune fonctionnalité ne peut être ajoutée en RC.
 
+## Gate de `0.0.3-rc.1.fix.1`
+
+Le fix de validation RC doit prouver :
+
+- `VERSION = 0.0.3-rc.1.fix.1` et version workspace identique ;
+- history `history/0.0.3/rc.1.md` présent avec statut `FAIL` et committé avant application ;
+- `alpha.1` toujours historiquement `PARTIAL` sans modification de son fichier ;
+- lecture robuste des statuts historiques, qu'ils soient bruts ou entourés de backticks Markdown ;
+- aucun diff produit sous `crates/` ou `Web/` et aucun changement du changelog, de la roadmap, de l'architecture, des études, des règles ou des prompts ;
+- audits Markdown/Rust locaux, `cargo fmt`, metadata/check, Clippy strict, tests Git ciblés et tests workspace propres ;
+- présentation candidate `0.0.3` et handoff `0.0.4` inchangés ;
+- `Cargo.lock` local ignoré/non suivi, package-lock Web versionné et staging final propre.
+
+Un `PASS` autorise `0.0.3-rel.1`. Le fix ne rejoue pas les smokes HTTP ni le build Web déjà `PASS` sur `rc.1`, puisqu'aucun fichier produit ou Web n'est modifié ; la gate stable `rel.1` les rejouera avant publication.
+
 ## PostgreSQL
 
 Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.