0.0.3-alpha.2

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -385,6 +385,10 @@ Après publication vérifiée de `v0.0.2`, la prochaine mission explicitement en
 
 `0.0.3` borne la mise à jour distante à des branches `refs/heads/...` et exige un état distant attendu. Un push n'est accepté que lorsque cette attente reste vraie ; sinon le résultat est un conflit récupérable. Le backend ne résout pas ce conflit par rebase/merge automatique.
 
+`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.
+
 PostgreSQL, workflow complet de proposition, auth/admin, parsing final et adapter Gitea restent des missions distinctes.
 
 ## 10. Administration

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: 3 -->
+<!-- version: 4 -->
 
 # 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` a produit une gate technique propre jusqu'aux tests workspace mais reste `PARTIAL` : la fin de gate n'a pas été fournie et la revue opérateur a détecté un mauvais cycle de rédaction du changelog, du prompt suivant et de la roadmap. `0.0.3-alpha.1.fix.1` corrige uniquement ce workflow documentaire avant l'implémentation fonctionnelle.
+`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`, ce qui ferme le cadrage et autorise `alpha.2`. `alpha.2` matérialise maintenant uniquement le contrat d'écriture provider-neutral dans `knowledge-git-api`; le backend de worktree reste réservé à `alpha.3`.
 
 ## Mission
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 33 -->
+<!-- version: 34 -->
 
 # Matrice de validation Knowledge
 
@@ -117,6 +117,24 @@ Les tests doivent permettre plusieurs `source_id` et ne pas confondre famille de
 
 Un test live de remote ou de forge doit être explicitement classé comme externe, séparé des tests unitaires et ne doit pas devenir une condition cachée pour les opérations locales.
 
+## Gate de `0.0.3-alpha.2`
+
+La tranche de contrat d'écriture Git doit prouver :
+
+- `VERSION = 0.0.3-alpha.2` et version workspace identique ;
+- `knowledge-git-api` reste une crate passive sans dépendance de forge, runtime, filesystem backend ou PostgreSQL ;
+- `GitRepository` de lecture reste inchangé et implémentable sans capacité d'écriture ;
+- `GitRepositoryWriter` est une capacité distincte ;
+- les chemins de mutation refusent valeur vide, chemin absolu/séparateur plateforme, `.` / `..`, composant vide et `.git` ;
+- les mutations représentent écriture create/update et suppression, avec rejet des chemins dupliqués dans une même requête ;
+- l'identité de commit et le message sont explicites et validés ;
+- la branche cible est une référence complète valide sous `refs/heads/...` ;
+- l'état distant attendu représente explicitement branche absente ou révision connue ;
+- le résultat de push peut représenter succès ou conflit sans rebase/merge automatique ;
+- `cargo fmt --all`, check, Clippy strict et tests ciblés `knowledge-git-api` passent ;
+- 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.
+
 ## PostgreSQL
 
 Aucune gate PostgreSQL n'est créée avant matérialisation d'une dépendance ou d'un schéma réel.