0.0.3-rc.1.fix.1

This commit is contained in:
2026-09-29 18:08:50 +02:00
parent 038b91864a
commit 0351aa045e
7 changed files with 321 additions and 9 deletions

View File

@@ -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