0.0.3-beta.1

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Architecture de fondation Knowledge
 
@@ -498,3 +498,33 @@ candidat retenu sous refs/knowledge/candidates/<revision>
 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.
+
+## Réconciliation `0.0.3-beta.1` et trajectoire produit
+
+Le chemin Git générique est maintenant complet pour la responsabilité de `0.0.3` : lecture/snapshot par `GitRepository`, création locale de candidat puis push gardé par `GitRepositoryWriter`, sans API de forge. Les deux contrats restent séparés et les conflits distants sont des résultats récupérables plutôt que des rebase/merge implicites.
+
+La prochaine dépendance structurante commune aux trois produits n'est plus l'écriture Git mais l'état applicatif persistant partagé. `0.0.4` est donc retenue comme prochaine mission pour matérialiser PostgreSQL, son premier schéma et ses migrations, la configuration logique des sources et l'état minimal de synchronisation/indexation. Le choix concret du driver/ORM, du pooling et de la stratégie de test PostgreSQL reste à décider dans l'étude de démarrage `0.0.4` ; il n'est pas anticipé par `0.0.3`.
+
+La trajectoire des façades Web est désormais explicitement séparée en étapes afin de ne pas confondre design, rendu et logique serveur :
+
+```text
+PostgreSQL partagé
+-> modèles/projections PGR + HOWTO + snippet
+-> templates publics des trois sites dans le template lab
+-> templates d'administration des trois sites dans le template lab
+-> routes publiques Actix + adaptation Maud des templates publics
+-> auth/autorisation + routes admin Actix + adaptation Maud des templates admin
+-> gestion/proposition/revue/publication appuyée sur Git + PostgreSQL
+```
+
+Les pages de garde, listes, détails, navigation et états de recherche/filtrage visibles sont donc conçus d'abord comme templates Web de référence. Les dashboards, formulaires et états de proposition/revue suivent le même principe côté administration. Une phase ultérieure adapte le markup validé en composants Maud servis par les trois launchers Actix, plutôt que de développer simultanément deux interfaces indépendantes.
+
+Cette trajectoire concerne les trois sites :
+
+```text
+pgr.sasedev.com       consultation et gestion du référentiel PGR
+howtos.sasedev.com    consultation et gestion des HOWTOs
+snippets.sasedev.com  consultation et gestion des snippets
+```
+
+Git reste la vérité éditoriale publiée ; PostgreSQL porte l'état transversal et les projections reconstructibles. Un contenu accepté n'est publié qu'après production d'une révision Git autoritaire, puis la projection locale est réconciliée depuis cette révision.