0.0.2-beta.1

docs/architecture/001-PROJECT_PROFILE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Profil du projet Knowledge
 
@@ -166,10 +166,10 @@ Elles justifient de conserver séparées l'identité/authentification partagée,
 - une nouvelle stable PGR n'a aucun effet tant qu'une réévaluation n'est pas explicitement planifiée ;
 - les artefacts historiques `0.0.1` et les tranches antérieures de `0.0.2` restent inchangés.
 
-## Décisions à rouvrir
+## Réconciliation beta et décisions différées
 
-La release `0.0.2` rouvre uniquement l'implémentation Git générique et la synchronisation réelle de lecture.
+`0.0.2-beta.1` confirme que le scope alpha est matérialisé par neuf packages Cargo : contrats domaine/Git/synchronisation, backend Git générique, orchestration application partagée, composition Web et trois launchers. Aucune responsabilité supplémentaire n'est nécessaire pour fermer la mission de lecture/synchronisation de `0.0.2`.
 
-Restent différés : adapter Gitea, PostgreSQL/migrations, moteur de recherche, auth/admin complète, quatrième application d'administration, modèle détaillé rôles/capabilities, formats finaux HOWTO/snippet, écriture/publication Git et partage concurrent de la même racine Git entre plusieurs processus.
+Restent différés : adapter Gitea, PostgreSQL/migrations, moteur de recherche, auth/admin complète, quatrième application d'administration, modèle détaillé rôles/capabilities, formats finaux HOWTO/snippet, écriture/publication Git, scheduler concret, support explicite submodules/LFS, politique de nettoyage/rétention des snapshots et partage concurrent de la même racine Git entre plusieurs processus.
 
-Un changement de scope produit, un besoin mesuré ou une contrainte d'exploitation peut déclencher un REPLAN ; il ne justifie pas un choix anticipé.
+La revue d'horizon beta ne réserve aucune release suivante. Un changement de scope produit, un besoin mesuré ou une contrainte d'exploitation pourra engager ultérieurement une nouvelle mission ; il ne justifie pas un choix anticipé.

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Architecture de fondation Knowledge
 
@@ -15,23 +15,25 @@ Le principe directeur reste :
 
 ## Workspace Rust matérialisé
 
-`alpha.2` instancie le skeleton PGR `002-RUST_CARGO_WORKSPACE`. `alpha.3` matérialise les trois premières frontières passives :
-
-```text
-knowledge-domain-lib  famille/source de contenu
-knowledge-git-api     GitRepository provider-neutral
-knowledge-sync-api    RepositoryEventSource et signal de réconciliation
-```
-
-`alpha.5` complète la fondation avec :
+La stable `0.0.1` a matérialisé les premières frontières et le runtime Web :
 
 ```text
+knowledge-domain-lib       famille/source de contenu
+knowledge-git-api          GitRepository provider-neutral
+knowledge-sync-api         RepositoryEventSource et signal de réconciliation
 knowledge-web-lib          composition Actix/Maud et assets Vite
 knowledge-pgr-server       launcher PGR
 knowledge-howtos-server    launcher HOWTOs
 knowledge-snippets-server  launcher snippets
 ```
 
+`0.0.2` ajoute deux owners réels sans changer la topologie multi-app :
+
+```text
+knowledge-git-lib  backend Git générique : mirror/refresh/resolve/snapshot
+knowledge-app-lib  cas d'usage partagé de synchronisation Changed/Unchanged
+```
+
 Les deux crates `-api` sont justifiées par des implémentations réellement remplaçables ou multiples. Elles restent sans runtime, sans logging propre et sans dépendance à Actix, Gitea ou PostgreSQL.
 
 Les tests unitaires Rust sont désormais placés hors de `src/` sous `unit_tests/`, conformément à la convention locale Knowledge sélectionnée sur l'option permise par PGR.
@@ -330,9 +332,9 @@ En particulier, Knowledge ne doit pas hériter mécaniquement :
 - d’une arborescence d’assets spécifique au corpus ;
 - de dépendances TypeScript `@types/*` non justifiées par les packages réellement consommés.
 
-`alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées.
+`0.0.1-alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées.
 
-`alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener.
+`0.0.1-alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener.
 
 Les trois packages `knowledge-pgr-server`, `knowledge-howtos-server` et `knowledge-snippets-server` sont des launchers minces : chacun sélectionne `ServerSite` et le nom de sa variable de bind, puis délègue au runtime commun. Ils ne possèdent aucune logique de rendu ou de manifest dupliquée.
 
@@ -348,6 +350,21 @@ La fondation matérialisée est cohérente avec les objectifs `0.0.1` :
 
 `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.
 
+## Réconciliation `0.0.2-beta.1`
+
+La mission Git/synchronisation est réconciliée avec l'implémentation réellement obtenue :
+
+- neuf packages Cargo, sans crate placeholder ;
+- `knowledge-git-api` provider-neutral et `knowledge-git-lib` comme implémentation process Git contrôlée ;
+- sources locales/remotes convergeant vers un mirror contrôlé puis vers une révision commit et un snapshot validé ;
+- `knowledge-app-lib` comme unique owner du cas d'usage refresh / resolve / compare / snapshot ;
+- dernière révision fournie par l'appelant, sans stockage caché ;
+- causes de synchronisation non autoritaires, `Periodic` sans scheduler imposé ;
+- règles Knowledge autonomes après l'adoption ponctuelle PGR `v0.1.3` ;
+- aucun adapter forge, PostgreSQL, auth/admin complète, écriture Git ou format final HOWTO/snippet introduit par anticipation.
+
+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.
+
 ## 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é.