0.0.2-alpha.3.fix.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: 6 -->
+<!-- version: 7 -->
 
 # Plan 0.0.2 — Git générique et synchronisation de lecture
 
@@ -17,7 +17,7 @@ Knowledge publish report   sasedev-knowledge-0.0.1-publish.001-report.md = PASS
 Knowledge start prompt     prompts/002-V0_0_2_START_PROMPT.md
 ```
 
-La baseline PGR réévaluée au démarrage de cette release est :
+La source PGR explicitement réévaluée au démarrage de cette release est :
 
 ```text
 PGR stable tag             v0.1.3
@@ -26,9 +26,9 @@ PGR archive SHA-256        f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a0
 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.
+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` peut donc matérialiser le premier backend Git réel.
+`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.
 
 ## Mission
 
@@ -43,13 +43,13 @@ source locale/remote
   -> résultat de synchronisation changed/unchanged
 ```
 
-La release doit transformer les contrats passifs de `0.0.1` en un backend Git de lecture testable, reproductible et remplaçable, tout en gardant Git autoritaire pour le contenu et la persistance métier hors de ce scope.
+La release doit transformer les contrats passifs de `0.0.1` en un backend Git de lecture testable, reproductible et remplaçable, tout en gardant Git autoritaire pour le contenu et la persistance métier hors de ce scope. Elle doit également terminer l'adoption PGR engagée au démarrage en rendant Knowledge autonome : règles applicables adaptées/possédées localement, PGR conservé comme provenance et non chargé automatiquement à chaque reprise.
 
 ## État acquis et questions ouvertes
 
 Décisions déjà matérialisées par le cadrage `alpha.1` et non remises en cause par son `FAIL` documentaire :
 
-- PGR `v0.1.3` est la baseline applicable au projet existant ;
+- PGR `v0.1.3` est la source d'adoption explicitement retenue pour `0.0.2`, tandis que la baseline normative courante doit être possédée localement par Knowledge ;
 - les changements PGR Java/Maven/Gradle/Android ne deviennent pas applicables à Knowledge ;
 - le `DEFER` Tauri reste inchangé ;
 - le backend initial utilise un processus `git` contrôlé via `std::process::Command`, sans shell ;
@@ -164,24 +164,51 @@ Si la surface « configuration + runner + mirror » ne peut plus être validée
 
 ### alpha.3 — refresh, résolution et snapshot réel
 
-Statut opérateur : **à valider**.
+Statut opérateur initial : **FAIL**.
 
-La tranche complète le chemin de lecture Git sur de vrais repositories temporaires :
+La tranche a matérialisé et prouvé sur de vrais repositories temporaires :
 
-- enregistrer explicitement les configurations physiques des sources dans `GitBackend` afin d'implémenter réellement le contrat provider-neutral ;
-- faire implémenter `knowledge-git-api::GitRepository` par `knowledge-git-lib` ;
-- étendre le contrat uniquement avec `GitSnapshot` / `prepare_snapshot`, maintenant nécessaires à la matérialisation de lecture ;
+- enregistrement explicite des configurations physiques dans `GitBackend` ;
+- implémentation réelle de `knowledge-git-api::GitRepository` par `knowledge-git-lib` ;
+- extension minimale du contrat avec `GitSnapshot` / `prepare_snapshot` ;
 - refresh idempotent du mirror via `remote update --prune` ;
-- résolution typée d'une référence vers un commit avec `rev-parse --verify --end-of-options ...^{commit}` ;
-- refus des références invalides ou non résolubles ;
-- préparation d'un worktree/snapshot détaché adressé par révision ;
-- validation du `HEAD` et de l'état propre d'un snapshot existant avant réutilisation ;
-- preuve d'un changement de révision après ajout d'un commit source ;
-- preuve qu'aucune API de forge n'est nécessaire.
+- résolution typée avec `rev-parse --verify --end-of-options ...^{commit}` ;
+- worktree/snapshot détaché adressé par révision ;
+- validation du `HEAD` et de l'état propre avant réutilisation ;
+- changement de révision après ajout d'un commit source ;
+- rejet d'une référence invalide et d'un snapshot sale.
 
-Les tests doivent exercer la frontière `GitRepository` et les effets Git réels. Une imitation complète de `git` par mocks ne constitue pas la preuve principale de cette tranche. Aucun `knowledge-app-lib`, scheduler ou état persistant n'entre dans `alpha.3`.
+Les tests fonctionnels passent, mais la gate complète échoue sur trois défauts de conformité : ligne vide terminale dans la matrice, formatage rustfmt d'un test `knowledge-git-api` et documentation de crate manquante dans le test d'intégration `git_read_path`.
 
-### alpha.4 — cas d'usage de synchronisation
+`alpha.3.fix.1` corrige exclusivement ces défauts techniques et enregistre le présent REPLAN. Il ne modifie pas le comportement Git déjà prouvé.
+
+La revue de tranche a déclenché un REPLAN explicite : l'autonomie normative après adoption PGR et l'organisation interne des crates doivent être traitées avant l'orchestration de synchronisation.
+
+### alpha.4 — autonomie normative et structure interne des crates
+
+Finaliser l'adoption PGR `v0.1.3` comme migration ponctuelle, sans transformer PGR en dépendance documentaire permanente :
+
+- inventorier les owners/contrats PGR réellement retenus par Knowledge ;
+- produire un mapping durable `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` fondé sur la baseline locale actuelle ;
+- pour chaque `ADOPT`, identifier l'owner local qui possède effectivement le contrat ;
+- adapter et matérialiser localement uniquement les règles, templates/configurations et audits nécessaires au développement de Knowledge ;
+- ne pas recopier mécaniquement l'arborescence ou les textes PGR lorsque `RULES.md` ou un owner local plus adapté suffit ;
+- faire de PGR `v0.1.3` une provenance d'adoption figée, et non une « baseline courante » à recharger ;
+- établir que les futurs prompts de démarrage partent de la baseline Knowledge locale et ne demandent une consultation PGR que si une réévaluation PGR est explicitement dans leur scope ;
+- vérifier que les règles de gouvernance, workflow, documentation, validation, Rust/Cargo et Web réellement nécessaires sont compréhensibles et applicables depuis le dépôt Knowledge seul.
+
+La même tranche audite l'organisation interne des crates :
+
+- `lib.rs` reste la façade publique/documentation de crate ;
+- les types, traits et implémentations sont déplacés vers des modules nommés selon leur responsabilité lorsqu'ils forment une responsabilité distincte ;
+- les crates `knowledge-git-api` et `knowledge-sync-api` sont examinées en priorité ;
+- `api.rs` n'est pas imposé comme nom générique : préférer des modules tels que `reference`, `revision`, `snapshot`, `repository`, `signal` ou autre ownership réel ;
+- les petites crates/fichiers ne sont pas découpés artificiellement uniquement pour satisfaire une forme ;
+- les réexports publics restent centralisés à la crate root et les consommateurs externes continuent d'utiliser la façade stable.
+
+Cette tranche ne change pas la sémantique Git prouvée par `alpha.3` et ne matérialise pas encore le cas d'usage `Changed` / `Unchanged`.
+
+### alpha.5 — cas d'usage de synchronisation
 
 Composer les primitives Git en un cas d'usage réellement consommable :
 
@@ -250,7 +277,7 @@ REPLAN obligatoire si :
 - l'orchestration de synchronisation crée une duplication réelle qui impose un nouvel owner commun non prévu ;
 - des mesures concrètes rendent le backend process inadéquat et justifient de réévaluer `gix` ou `git2` ;
 - trois fixes ou plus apparaissent sur une même tranche ;
-- une nouvelle stable PGR modifie un owner réellement applicable au scope courant ;
+- une réévaluation PGR explicitement engagée révèle un changement substantiel d'un contrat déjà adopté par Knowledge ;
 - un prérequis externe invalide la mission de `0.0.2`.
 
 Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être masqué par un simple élargissement opportuniste d'un delta.
@@ -260,7 +287,7 @@ Un REPLAN modifie le présent plan de manière explicite ; il ne doit pas être
 - documentation durable : réconciliée à chaque tranche qui change un contrat, puis revue globalement en `beta.1` ;
 - `CHANGELOG.md` : consolidé en candidate/stable sans catalogue de fixes internes inutile ;
 - `ROADMAP.md` : revue d'horizon en `beta.1`, sans création automatique d'une prochaine version ;
-- prompt/handoff suivant : créé uniquement si une prochaine mission est réellement décidée ;
+- prompt/handoff suivant : créé uniquement si une prochaine mission est réellement décidée et fondé sur la baseline normative locale Knowledge ; aucune consultation PGR automatique n'y est ajoutée ;
 - fermeture du plan : `rel.1` ou son fix établissant la stable ;
 - publication : commit produit `0.0.2`, tag stable `v0.0.2`, archive du tag puis rapport post-tag séparé ;
 - toute tranche suit `delta -> gate opérateur -> history réel -> commit/push -> tranche suivante ou fix`.