0.0.2-beta.1

docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-V0_0_2_GIT_SYNC_PLAN.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Plan 0.0.2 — Git générique et synchronisation de lecture
 
@@ -28,7 +28,7 @@ PGR publish report         pgr-0.1.3-publish.001-report.md = PASS
 
 Le passage de PGR `v0.1.1` à `v0.1.3` est traité comme adoption d'un projet existant via `230-ADOPTION`. Les artefacts historiques de `0.0.1` ne sont pas réécrits. `v0.1.3` constitue une provenance d'adoption, pas une dépendance normative vivante : les futurs démarrages Knowledge doivent partir des règles locales et ne consultent PGR que lorsqu'une nouvelle adoption est explicitement engagée.
 
-`0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` démontre le chemin Git réel mais sa gate est `FAIL` sur hygiène/formatage/documentation de test ; `alpha.3.fix.1` corrige ces défauts et enregistre le REPLAN décrit ci-dessous.
+`0.0.2-alpha.1` est `FAIL` pour défaut de structure du présent plan malgré des contrôles techniques propres. `alpha.1.fix.1` a corrigé uniquement ce cadrage documentaire et sa gate opérateur est `PASS`. `alpha.2` a été fermée par `alpha.2.fix.2` `PASS`. `alpha.3` a été fermée par `alpha.3.fix.1` `PASS`. `alpha.4` a été fermée par `alpha.4.fix.1` `PASS`, terminant l'adoption PGR comme migration ponctuelle. `alpha.5` est `PASS` et ferme le scope fonctionnel alpha avec `knowledge-app-lib` et le cas d'usage partagé `Changed` / `Unchanged`. `beta.1` est la tranche courante de réconciliation et revue d'horizon.
 
 ## Mission
 
@@ -62,12 +62,12 @@ Décisions déjà matérialisées par le cadrage `alpha.1` et non remises en cau
 - la racine d'état reste exclusive à une instance/processus pour `0.0.2` ;
 - la révision précédemment observée reste fournie par l'appelant tant que la persistance PostgreSQL est hors scope ;
 - `gix` et `git2` restent des alternatives différées, pas des backends ajoutés par symétrie.
+- `knowledge-app-lib` est matérialisée en `alpha.5` comme owner du cas d'usage partagé refresh / résolution / comparaison / snapshot.
 
 Questions laissées ouvertes jusqu'à la tranche qui les consomme :
 
 - politique de nettoyage/rétention des snapshots ;
 - besoin réel de supporter submodules ou Git LFS dans cette release ;
-- besoin réel d'une crate `knowledge-app-lib` pour l'orchestration partagée ;
 - mécanisme concret de scheduler périodique, volontairement non requis pour prouver le cas d'usage de synchronisation ;
 - prochaine mission/version après `0.0.2`, à décider uniquement lors de la revue d'horizon.
 
@@ -234,17 +234,20 @@ La gate Rust applique désormais explicitement `cargo fmt --all`, puis `cargo fm
 
 ### beta.1 — réconciliation et revue d'horizon
 
-Réconcilier le plan avec l'implémentation réellement obtenue :
+Tranche courante de stabilisation. Elle n'ajoute aucune grande fonctionnalité.
 
-- inventorier les contrats et crates effectivement matérialisés ;
-- vérifier les `DEFER` et hors-scope ;
-- retirer ou corriger les hypothèses de forecast devenues fausses ;
-- vérifier l'absence de dépendance forge/PostgreSQL/auth/admin ;
-- rejouer les gates Rust/Git et la non-régression Web utile ;
-- décider si une prochaine mission est suffisamment claire pour engager une version suivante ;
-- ne réserver aucun numéro futur par défaut.
+La réconciliation doit :
 
-Aucune grande fonctionnalité nouvelle n'entre en beta.
+- inventorier les neuf packages et contrats effectivement matérialisés ;
+- confirmer `knowledge-git-lib` comme backend Git et `knowledge-app-lib` comme owner du cas d'usage partagé ;
+- vérifier les `DEFER` et hors-scope encore valides ;
+- corriger les formulations durables héritées de `0.0.1` qui utilisent encore des numéros d'alpha non qualifiés ;
+- confirmer l'absence de dépendance forge/PostgreSQL/auth/admin et d'écriture Git ;
+- rejouer la gate Rust/Git et la non-régression Web utile ;
+- produire une étude de réconciliation durable ;
+- réaliser la revue d'horizon sans réserver de numéro futur par défaut.
+
+Résultat de revue proposé et soumis à la gate beta : aucune prochaine mission n'est suffisamment décidée pour engager une version postérieure à `0.0.2`. Les domaines futurs restent non numérotés.
 
 ### rc.1 — candidate stable
 
@@ -306,14 +309,10 @@ Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être
 
 ## Revue d'horizon
 
-État courant : **non réalisée**.
+État courant : **réalisée dans `0.0.2-beta.1` et soumise à validation opérateur**.
 
-Aucune version postérieure à `0.0.2` n'est réservée par le présent plan.
+Résultat : aucune version postérieure à `0.0.2` n'est réservée. Les domaines futurs restent non numérotés parce qu'aucune mission suivante ne possède encore un scope et un ordre suffisamment décidés.
 
-La revue appartient à `beta.1` et doit s'appuyer sur le backend Git réellement éprouvé, les DEFER encore ouverts et les besoins produit observés. Elle peut :
+Les besoins différés confirmés incluent notamment : PostgreSQL/migrations, parsing/index, propositions/admin/auth, adapter de forge, écriture/publication Git, scheduler concret, submodules/LFS, politique de rétention des snapshots et partage multi-processus de la racine Git.
 
-- engager une prochaine release avec mission explicite ;
-- maintenir les domaines futurs non numérotés ;
-- reclasser un besoin différé si les preuves obtenues le justifient.
-
-Elle ne doit pas transformer automatiquement PostgreSQL, parsing/index, propositions/admin/auth, forge ou publication en prochaine version uniquement parce que ces domaines sont connus.
+Une future mission pourra être engagée depuis la stable `0.0.2` lorsqu'un besoin produit ou d'exploitation choisira explicitement l'un de ces axes. Elle devra repartir de la baseline locale Knowledge et ne consultera PGR que si une réévaluation PGR est elle-même explicitement dans le scope.