0.0.3-alpha.4

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 
 # Architecture de fondation Knowledge
 
@@ -480,3 +480,21 @@ snippets            source Git courte/contextualisée séparée
 Les dépôts de contenu ne sont pas fusionnés dans PGR et ne sont pas requis comme submodules Git du dépôt applicatif. Leur localisation et leurs credentials sont de la configuration de déploiement.
 
 Pendant `0.0.2`, cette configuration de déploiement est adaptée en configuration physique possédée par `knowledge-git-lib`. La racine de mirrors/worktrees reste un état généré reconstructible et ne remplace pas le futur stockage logique PostgreSQL.
+
+## Écriture Git gardée acquise en 0.0.3-alpha.4
+
+Le backend Git complète désormais le cycle provider-neutral d'écriture sans adapter de forge : un candidat retenu localement peut être publié vers une branche `refs/heads/...` uniquement sous garde explicite de l'état distant attendu.
+
+Le chemin est :
+
+```text
+candidat retenu sous refs/knowledge/candidates/<revision>
+-> observation `git ls-remote --refs origin <branche>`
+-> comparaison avec GitRemoteState attendu
+-> git push --force-with-lease=<branche>:<attendu>
+-> Updated(candidate) ou Conflict { actual }
+```
+
+Pour `GitRemoteState::Absent`, la lease utilise une attente vide et autorise donc uniquement la création d'une branche encore absente. Pour `GitRemoteState::Revision(r)`, la mise à jour distante n'est acceptée que si la branche pointe encore exactement sur `r`. L'observation préalable fournit un conflit rapide ; `--force-with-lease` reste la garde autoritaire contre une course entre observation et push. Après un rejet de push, le backend observe à nouveau la branche afin de traduire une divergence concurrente en conflit récupérable.
+
+Cette capacité ne fait aucun rebase/merge automatique et ne publie aucune pull/merge request. Elle utilise uniquement le remote `origin` possédé par le mirror contrôlé et conserve la forge hors du contrat.

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
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 35 -->
+<!-- version: 36 -->
 
 # Matrice de validation Knowledge
 
@@ -156,6 +156,27 @@ La tranche de création locale du commit candidat doit prouver :
 - `cargo fmt --all`, check, Clippy strict, tests ciblés `knowledge-git-lib` et tests workspace propres ;
 - `knowledge-app-lib` et `Web/` sans diff, `Cargo.lock` ignoré/non suivi et staging final propre.
 
+
+## Gate de `0.0.3-alpha.4`
+
+La tranche de push gardé et concurrence doit prouver :
+
+- `VERSION = 0.0.3-alpha.4` et version workspace identique ;
+- history `history/0.0.3/alpha.3.fix.1.md` présent avec statut `PASS` et committé avant application ;
+- `GitBackend` implémente désormais `GitRepositoryWriter` sans modifier le contrat public `knowledge-git-api` ;
+- le candidat à pousser doit exister sous la référence interne contrôlée créée par `alpha.3` ;
+- l'état distant est observé par le remote générique `origin`, sans API de forge ;
+- une attente `GitRemoteState::Revision(r)` utilise une lease exacte sur `r` ;
+- une attente `GitRemoteState::Absent` n'autorise que la création d'une branche absente ;
+- un écart observé avant le push produit immédiatement `GitPushOutcome::Conflict` ;
+- `--force-with-lease` protège également la course entre observation et push ;
+- après rejet d'un push, une nouvelle observation traduit une divergence en conflit récupérable sans écrasement ;
+- aucun rebase/merge automatique, force-push non gardé, forge, PostgreSQL ou orchestration applicative n'est ajouté ;
+- tests d'intégration Git réels avec remote bare local couvrant mise à jour d'une branche existante, création sous attente d'absence et conflit concurrent sans écrasement ;
+- `cargo fmt --all`, check, Clippy strict, tests ciblés `knowledge-git-lib` et tests workspace propres ;
+- `knowledge-git-api`, `knowledge-app-lib`, `Web/`, `CHANGELOG.md` et `ROADMAP.md` sans diff ;
+- `Cargo.lock` ignoré/non suivi et staging final propre.
+
 ## PostgreSQL
 
 Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.