0.0.3-alpha.1

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Architecture de fondation Knowledge
 
@@ -177,9 +177,23 @@ Le snapshot de lecture est ensuite créé comme worktree détaché adressé par
 
 Les hooks Git sont désactivés pour les opérations de checkout/worktree appartenant au backend. Les commandes sont exécutées directement sans shell, avec prompts interactifs désactivés et sans journaliser de credential.
 
-### Scope futur du contrat Git
+### Écriture Git engagée en `0.0.3`
 
-`alpha.3` étend `GitRepository` uniquement avec `prepare_snapshot`, parce que la matérialisation locale devient effectivement nécessaire au cas d'usage de lecture. Les opérations génériques à plus long terme peuvent inclure `status/diff`, branch, commit, merge/rebase et push. Elles ne sont pas ajoutées en `0.0.2`.
+`0.0.3` ajoute une frontière d'écriture distincte du `GitRepository` de lecture. Le backend conserve le processus `git` contrôlé et matérialise un worktree d'écriture isolé sous la racine d'état, sans modifier les snapshots de lecture.
+
+Le chemin cible est :
+
+```text
+base GitRevision explicite
+-> worktree d'écriture contrôlé
+-> mutations de fichiers confinées
+-> commit avec identité explicite
+-> révision candidate
+-> push vers refs/heads/... gardé par l'état distant attendu
+-> succès ou conflit explicite
+```
+
+Une divergence ne déclenche ni rebase, ni merge, ni force-push non gardé. Ces décisions appartiennent à un futur workflow de proposition/publication. Les capacités forge-specific restent séparées.
 
 La baseline conserve au moins trois sources indépendantes (`pgr`, `howtos`, `snippets`) mais le mapping reste configurable et extensible ; aucun `match` codé en dur n'impose exactement trois repositories.
 
@@ -348,7 +362,7 @@ La fondation matérialisée est cohérente avec les objectifs `0.0.1` :
 - frontend de référence indépendant et rendu runtime Maud effectivement relié au manifest Vite ;
 - aucune persistance PostgreSQL, auth complète, UI admin complète, forge spécifique ou format final HOWTO/snippet introduit par anticipation.
 
-`0.0.2-alpha.1` conserve cette réconciliation comme baseline : la release courante ouvre uniquement le chemin Git générique de lecture et la synchronisation réelle ; les autres axes restent différés.
+`0.0.2-alpha.1` a conservé cette réconciliation comme baseline et la stable `0.0.2` a fermé le chemin Git générique de lecture et la synchronisation réelle.
 
 ## Réconciliation `0.0.2-beta.1`
 
@@ -365,6 +379,14 @@ La mission Git/synchronisation est réconciliée avec l'implémentation réellem
 
 Les besoins de rétention de snapshots, submodules/LFS, partage multi-processus de la racine Git et scheduler concret restent différés jusqu'à preuve d'un besoin réel. Aucune prochaine release n'est numérotée par cette réconciliation.
 
+## Ouverture `0.0.3` — écriture Git contrôlée
+
+Après publication vérifiée de `v0.0.2`, la prochaine mission explicitement engagée est l'écriture Git générique contrôlée. Elle réutilise le backend process existant, introduit un contrat d'écriture distinct de la lecture et garde la forge optionnelle.
+
+`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.
+
+PostgreSQL, workflow complet de proposition, auth/admin, parsing final et adapter Gitea restent des missions distinctes.
+
 ## 10. Administration
 
 L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.