0.0.3-alpha.4

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: 6 -->
+<!-- version: 7 -->
 
 # Plan 0.0.3 — écriture Git contrôlée et push gardé
 
@@ -19,7 +19,7 @@ Knowledge start prompt     prompts/003-V0_0_3_START_PROMPT.md
 
 PGR `v0.1.3` reste une provenance historique de l'adoption fermée pendant `0.0.2`. Aucune version PGR plus récente n'est une source de cette release et aucune réévaluation PGR n'est engagée.
 
-`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` a ensuite introduit le worktree et le commit candidat, mais sa gate est `FAIL` sur une assertion du nouveau test d'intégration qui compare un `Result<String, std::io::Error>` avec `assert_eq!`. `alpha.3.fix.1` corrige uniquement cette preuve de test avant toute progression vers `alpha.4`.
+`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion et sa gate opérateur est `PASS`. `alpha.4` ferme maintenant le scope fonctionnel alpha avec le push gardé et les conflits explicites.
 
 ## Mission
 
@@ -62,12 +62,14 @@ Décisions prises par l'étude `006` :
 - traiter une divergence comme conflit récupérable, sans rebase/merge automatique ;
 - ne créer aucune nouvelle crate tant qu'un owner distinct n'est pas démontré.
 
-Questions laissées à l'implémentation sans modifier la mission :
+Décisions d'implémentation désormais résolues dans les alphas :
 
-- forme exacte des types de mutation publique dans `knowledge-git-api` ;
-- stratégie interne de nommage/cleanup des worktrees d'écriture ;
-- découpage exact des erreurs de conflit versus erreurs process ;
-- détail de la commande Git utilisée pour la garde distante, sous réserve de la sémantique décidée.
+- mutations publiques provider-neutral matérialisées dans `knowledge-git-api` ;
+- worktree d'écriture backend déterministe sous `write-worktrees/<source-key>/candidate` ;
+- candidats retenus sous `refs/knowledge/candidates/<revision>` ;
+- conflits distants représentés par `GitPushOutcome::Conflict`, séparés des erreurs process ;
+- garde distante matérialisée par observation `ls-remote` puis `push --force-with-lease` exact ;
+- `remote.origin.mirror=true` neutralisé uniquement sur le push ciblé afin de ne jamais publier toutes les refs internes du mirror.
 
 ## Scope
 
@@ -184,10 +186,14 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 
 ### alpha.4 — push gardé et concurrence
 
-- observer l'état de la branche distante ;
+- partir de `alpha.3.fix.1 = PASS` historisé et committé ;
+- observer l'état de la branche distante via le remote générique `origin` ;
+- exiger que la révision candidate soit encore retenue par le backend ;
 - pousser la révision candidate uniquement si la cible correspond à l'attente explicite ;
+- utiliser `--force-with-lease` comme garde compare-and-exchange autoritaire ;
 - gérer création de branche lorsque l'absence est attendue ;
-- produire un conflit récupérable en cas de divergence ;
+- réobserver après rejet afin de produire un conflit récupérable en cas de divergence concurrente ;
+- implémenter `GitRepositoryWriter` sur `GitBackend` maintenant que create + push sont disponibles ;
 - prouver l'absence d'écrasement par tests d'intégration avec remote bare local ;
 - fermer le scope fonctionnel alpha sans ajouter workflow de proposition ou forge.
 
@@ -245,7 +251,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 ensuite matérialisé le contrat d'écriture provider-neutral avec une gate `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; son history autorise uniquement `alpha.3.fix.1`. Un `PASS` complet de ce fix autorise `alpha.4`; tout autre statut produit d'abord son history puis un fix borné ou un REPLAN selon le diagnostic.
+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 ensuite matérialisé le contrat d'écriture provider-neutral avec une gate `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` corrige uniquement le test et sa gate opérateur est `PASS`. `alpha.4` peut donc fermer le scope fonctionnel alpha par le push gardé et les conflits explicites.
 
 ## Revue d'horizon