# Réconciliation 0.0.2 — Git générique et synchronisation ## Objet Cette étude de `0.0.2-beta.1` réconcilie la mission annoncée avec l'implémentation réellement validée par les alphas. Elle n'ajoute aucune fonctionnalité et sert de baseline durable pour la candidate. ## Inventaire matérialisé Le workspace contient neuf packages : ```text knowledge-domain-lib famille/source de contenu knowledge-git-api contrat GitRepository provider-neutral knowledge-git-lib backend process Git contrôlé knowledge-sync-api signaux de réconciliation knowledge-app-lib cas d'usage partagé Changed / Unchanged knowledge-web-lib runtime Actix/Maud/Vite partagé knowledge-pgr-server launcher PGR knowledge-howtos-server launcher HOWTOs knowledge-snippets-server launcher snippets ``` Aucune crate n'est un placeholder créé uniquement pour refléter un diagramme. ## Chemin Git obtenu Le chemin de lecture réellement matérialisé est : ```text GitSourceConfig -> mirror contrôlé repositories/.git -> remote update --prune -> rev-parse ^{commit} -> GitRevision -> worktree détaché snapshots// -> validation HEAD + worktree propre -> GitSnapshot ``` L'implémentation reste derrière `knowledge-git-api::GitRepository`. Les sources locales utilisent `--no-local`; les opérations sont lancées sans shell, sans prompt interactif et avec hooks neutralisés sur les opérations concernées. Les erreurs publiques n'exposent pas les localisations ou credentials de source. ## Synchronisation obtenue `knowledge-app-lib` possède le cas d'usage partagé : ```text RepositorySyncSignal -> refresh -> resolve_revision -> comparer previous_revision -> Unchanged ou -> prepare_snapshot -> Changed { revision, snapshot } ``` La révision précédente est fournie par l'appelant ; aucune pseudo-base locale n'est ajoutée. `Periodic` utilise le même chemin de réconciliation qu'une cause explicite, sans scheduler concret. ## Autonomie normative L'adoption PGR `v0.1.3` est fermée comme migration ponctuelle. Les règles, templates et audits nécessaires au travail courant sont possédés par Knowledge. Une session ou version normale repart de la baseline locale et ne recharge pas PGR. ## DEFER confirmés Restent hors de `0.0.2` : - adapter Gitea ou autre forge ; - écriture Git, branches/propositions/rebase/merge/push et publication ; - PostgreSQL, migrations et persistance durable de dernière révision ; - moteur de recherche/index applicatif ; - auth/admin complète et modèle rôles/capabilities ; - formats finaux HOWTO/snippet et parsing métier ; - scheduler périodique concret ; - support explicite submodules/Git LFS ; - politique de nettoyage/rétention des snapshots ; - partage concurrent d'une même racine Git entre plusieurs processus ; - backend secondaire `gix`/`git2` sans nouvelle preuve de besoin. Ces points ne sont pas des défauts de `0.0.2`; ils nécessitent une mission distincte ou un besoin d'exploitation démontré. ## Réconciliation documentaire Les anciennes références `alpha.2` à `alpha.5` de la fondation Web sont qualifiées `0.0.1-*` lorsque leur contexte serait ambigu avec les alphas `0.0.2`. La documentation durable distingue désormais clairement : - fondation/runtime Web stable `0.0.1` ; - backend Git et synchronisation `0.0.2` ; - adoption PGR `v0.1.3` comme provenance historique, non comme dépendance courante. ## Revue d'horizon La revue ne réserve aucune release après `0.0.2`. Plusieurs domaines futurs sont connus, mais aucun n'a encore un scope et un ordre suffisamment décidés pour devenir la prochaine mission autoritaire. La prochaine version sera engagée uniquement lorsqu'un besoin produit ou d'exploitation choisira explicitement un axe. Aucun prompt `0.0.3` n'est créé en `beta.1`. ## Conclusion Le scope fonctionnel de `0.0.2` est complet et cohérent avec sa mission. `beta.1` peut préparer la release candidate sans ajouter de fonctionnalité ; la RC devra se concentrer sur l'intégrité des artefacts, la reproductibilité Git, la gate Rust complète et la non-régression Web/runtime.