0.0.3

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: 11 -->
+<!-- version: 12 -->
 
 # Plan 0.0.3 — écriture Git contrôlée et push gardé
 
@@ -235,6 +235,15 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 - produire le history observé avant commit produit/tag ;
 - ne fabriquer aucun rapport post-tag avant publication réelle.
 
+### rel.1.fix.1 — complétion de la preuve de clôture stable
+
+- conserver `rel.1 = PARTIAL` avec toutes les preuves produit/runtime réellement acquises ;
+- ne modifier aucun code produit, frontend, changelog, roadmap, architecture, étude, règle ou prompt ;
+- compléter explicitement l'audit de composition du workspace à partir du JSON `cargo metadata` déjà prévu par la gate ;
+- compléter explicitement l'audit d'hygiène texte sur les documents gouvernés ;
+- réutiliser les preuves Cargo/Clippy/tests, Web et smokes HTTP `PASS` de `rel.1` puisqu'aucun fichier concerné n'est modifié ;
+- autoriser le premier commit stable `0.0.3` uniquement après `PASS` complet de ce fix.
+
 ## Déclencheurs de REPLAN
 
 REPLAN avant de poursuivre si :
@@ -264,7 +273,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. `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` a corrigé uniquement cette preuve en `PASS`. `rel.1` assure maintenant la promotion stable pré-tag sans rouvrir le scope.
+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` a corrigé uniquement cette preuve en `PASS`. `rel.1` a acquis toutes les preuves produit/runtime de la promotion stable mais reste `PARTIAL` parce que deux contrôles annoncés — composition exacte du workspace et hygiène texte — ne figurent pas dans le transcript. `rel.1.fix.1` ferme uniquement ces deux preuves avant le premier commit stable réellement `PASS`.
 
 ## Revue d'horizon
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 40 -->
+<!-- version: 41 -->
 
 # Matrice de validation Knowledge
 
@@ -251,6 +251,22 @@ La fermeture stable pré-tag doit prouver :
 
 Un `PASS` de `rel.1` autorise le commit produit exact `0.0.3`, le push, puis seulement la création/push du tag annoté `v0.0.3`, le téléchargement de l'archive réellement servie et la production séparée du rapport `sasedev-knowledge-0.0.3-publish.001-report.md`.
 
+## Gate de `0.0.3-rel.1.fix.1`
+
+Le fix de complétion de preuve stable doit prouver :
+
+- `VERSION = 0.0.3` et version workspace identique ; la clôture stable reste la même version produit ;
+- history `history/0.0.3/rel.1.md` présent avec statut `PARTIAL` et committé avant application ;
+- aucune modification sous `crates/`, `Web/`, `CHANGELOG.md`, `ROADMAP.md`, `docs/architecture/`, `docs/studies/`, `docs/rules/` ou `prompts/` ;
+- fichier `cargo metadata --format-version 1 --no-deps` produit puis ensemble exact des neuf packages/workspace members vérifié explicitement ;
+- hygiène texte explicite `PASS` sur README/RULES/ROADMAP/CHANGELOG/docs/prompts/deltas/history ;
+- audits Markdown locaux propres après ajout du fix ;
+- preuves `rel.1` conservées : formatage/audits Rust, Cargo/Clippy/tests, Web/Vite et trois smokes HTTP tous `PASS` ;
+- tag `v0.0.3` et rapport post-tag toujours absents avant le history `rel.1.fix.1` `PASS` ;
+- `Cargo.lock` local ignoré/non suivi, package-lock Web versionné et staging final propre.
+
+Le premier `PASS` d'une clôture `rel.N[/fix.M]` autorise alors le commit produit exact `0.0.3`, le push, puis le tag annoté `v0.0.3` et la vérification post-tag.
+
 ## PostgreSQL
 
 Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.