0.0.3-alpha.3

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Architecture de fondation Knowledge
 
@@ -135,12 +135,16 @@ Les données générées résident hors du dépôt applicatif et hors des dépô
 
 ```text
 <git-state-root>/
+  empty-global.gitconfig
   hooks-disabled/
   repositories/
     <source-key>.git/
   snapshots/
     <source-key>/
       <resolved-revision>/
+  write-worktrees/
+    <source-key>/
+      candidate/
 ```
 
 Le backend reçoit explicitement `<git-state-root>` ; il n'utilise aucun défaut implicite sous le workspace. Une variable de déploiement telle que `KNOWLEDGE_GIT_STATE_ROOT` pourra alimenter la composition, mais la librairie reçoit un chemin et ne lit pas elle-même l'environnement.
@@ -387,7 +391,11 @@ Après publication vérifiée de `v0.0.2`, la prochaine mission explicitement en
 
 `alpha.2` matérialise cette frontière dans `knowledge-git-api` sans implémentation de backend : `GitMutationPath` confine lexicalement les mutations à des chemins relatifs normalisés hors `.git`, `GitFileMutation` représente écriture ou suppression, `GitCommitIdentity` impose une identité explicite, `GitBranch` borne la cible à une référence de branche complète valide, et `GitRemoteState` représente soit l'absence attendue soit une révision distante attendue. `GitWriteRequest`, `GitPushRequest` et `GitPushOutcome` portent respectivement la création de candidate, la comparaison-et-échange distante et son résultat. Le trait `GitRepositoryWriter` reste séparé de `GitRepository` afin qu'un consommateur ou fake lecture seule n'acquière aucune obligation d'écriture.
 
-Le confinement filesystem contre les symlinks, la neutralisation des hooks, la création du commit et l'exécution du push gardé restent des responsabilités de `knowledge-git-lib` à partir de `alpha.3`; l'API passive ne prétend pas les prouver seule.
+`alpha.3` implémente la moitié locale de ce contrat dans `knowledge-git-lib`. Le backend crée un worktree détaché temporaire sous `write-worktrees/<source-key>/candidate`, applique uniquement les chemins demandés et refuse tout composant filesystem qui est un symlink. Le staging est contrôlé contre l'ensemble exact des mutations avant commit. L'identité auteur/committer est injectée explicitement ; la configuration Git système et globale est neutralisée, les hooks sont redirigés vers `hooks-disabled`, et le commit désactive également hook/signature à l'appel.
+
+Après commit, le backend vérifie `HEAD` et `HEAD^1`, exige que le parent soit exactement la `GitRevision` de base puis conserve l'objet candidat sous `refs/knowledge/candidates/<revision>`. Le worktree possédé est retiré après succès ; après une erreur survenue dans un worktree créé par l'opération, le backend tente une suppression forcée de cet état temporaire. Un worktree préexistant n'est jamais supprimé silencieusement et produit une erreur récupérable.
+
+Le push distant gardé reste réservé à `alpha.4`. `alpha.3` ne met à jour aucune branche remote et n'implémente ni rebase ni merge.
 
 PostgreSQL, workflow complet de proposition, auth/admin, parsing final et adapter Gitea restent des missions distinctes.
 

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: 4 -->
+<!-- version: 5 -->
 
 # Plan 0.0.3 — écriture Git contrôlée et push gardé
 
@@ -165,12 +165,14 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 
 ### alpha.3 — worktree d'écriture et commit candidat
 
+- partir de `alpha.2 = PASS` historisé et committé ;
 - matérialiser dans `knowledge-git-lib` un worktree d'écriture isolé dérivé d'une base résolue ;
-- appliquer create/update/delete sous confinement ;
-- neutraliser hooks/configuration ambiante pertinente ;
-- créer un commit avec identité explicite ;
-- retourner une révision candidate vérifiée ;
-- nettoyer l'état temporaire de manière déterministe sans masquer un état inattendu.
+- appliquer create/update/delete sous confinement et refuser les traversées par symlink ;
+- neutraliser la configuration Git système/globale pertinente et les hooks ;
+- créer un commit avec identité auteur/committer explicite ;
+- vérifier que le candidat a exactement la base demandée comme parent ;
+- retenir le candidat sous une référence backend interne sans mettre à jour de branche distante ;
+- nettoyer l'état temporaire de manière déterministe sans supprimer silencieusement un worktree préexistant.
 
 ### alpha.4 — push gardé et concurrence
 
@@ -235,7 +237,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 retour opérateur de ce premier fix reste `PARTIAL` parce que son transcript s'arrête avant les assertions finales imposées par le delta ; il autorise donc uniquement `0.0.3-alpha.1.fix.2`. Un `PASS` complet de `alpha.1.fix.2` autorise `0.0.3-alpha.2`. Tout autre statut produit d'abord son history puis un nouveau fix ou 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 et sa gate opérateur est `PASS`; son history autorise `0.0.3-alpha.3`. Tout autre statut de `alpha.3` produit d'abord son history puis un fix borné ou un REPLAN selon le diagnostic.
 
 ## Revue d'horizon
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 34 -->
+<!-- version: 35 -->
 
 # Matrice de validation Knowledge
 
@@ -135,6 +135,27 @@ La tranche de contrat d'écriture Git doit prouver :
 - les tests workspace passent car la façade publique de la crate change ;
 - `knowledge-git-lib`, `knowledge-app-lib`, `Web/`, PostgreSQL et adapters forge ne sont pas modifiés par cette tranche.
 
+## Gate de `0.0.3-alpha.3`
+
+La tranche de création locale du commit candidat doit prouver :
+
+- `VERSION = 0.0.3-alpha.3` et version workspace identique ;
+- history `history/0.0.3/alpha.2.md` présent avec statut `PASS` et committé avant application ;
+- `knowledge-git-api` inchangé par rapport à `alpha.2` ;
+- `knowledge-git-lib` crée un worktree d'écriture isolé sous sa racine d'état sans modifier les snapshots de lecture ;
+- create/update/delete limités exactement aux chemins de mutation demandés ;
+- toute traversée par symlink refusée avant écriture hors worktree ;
+- configuration Git système/globale pertinente neutralisée et hooks désactivés ;
+- identité auteur/committer explicitement fournie par `GitWriteRequest` ;
+- commit candidat vérifié comme enfant direct de la révision de base ;
+- candidat retenu sous une référence backend interne avant suppression du worktree temporaire ;
+- worktree temporaire supprimé après succès et après erreur possédée, mais worktree préexistant jamais effacé silencieusement ;
+- aucun push distant, rebase, merge, forge, PostgreSQL ou orchestration application ajouté ;
+- test d'intégration Git réel prouvant modification/création/suppression, identité explicite, base inchangée et nettoyage ;
+- test Unix prouvant qu'un symlink versionné ne permet pas d'écrire hors du worktree ;
+- `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.
+
 ## PostgreSQL
 
 Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.