Sasedev/sasedev-knowledge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-29 19:00:14 +02:00
parent 9a1f73d57b
commit b382397244
4 changed files with 279 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md
View File

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