0.0.2-alpha.5

docs/architecture/001-PROJECT_PROFILE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Profil du projet Knowledge
 
@@ -119,6 +119,7 @@ Les packages matérialisés sont :
 
 ```text
 knowledge-domain-lib       types métier stables de famille/source
+knowledge-app-lib          cas d'usage applicatifs partagés, dont synchronisation de lecture
 knowledge-git-api          contrat passif GitRepository provider-neutral
 knowledge-git-lib          implémentation Git générique + mirror/refresh/resolve/snapshot + état local contrôlé
 knowledge-sync-api         contrat passif RepositoryEventSource
@@ -128,7 +129,7 @@ knowledge-howtos-server    launcher HOWTOs mince
 knowledge-snippets-server  launcher snippets mince
 ```
 
-`knowledge-git-lib` devient réelle en `0.0.2-alpha.2` puis implémente le chemin de lecture Git dans `alpha.3`. `knowledge-app-lib` reste seulement l'owner candidat du cas d'usage de synchronisation partagé et ne sera matérialisée que si l'orchestration réelle démontre cette responsabilité.
+`knowledge-git-lib` devient réelle en `0.0.2-alpha.2` puis implémente le chemin de lecture Git dans `alpha.3`. `knowledge-app-lib` devient réelle en `0.0.2-alpha.5` : l'orchestration refresh / résolution / comparaison / snapshot confirme une responsabilité application partagée distincte du backend Git et des launchers.
 
 Les responsabilités suivantes restent candidates et non matérialisées :
 

docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
-<!-- version: 12 -->
+<!-- version: 13 -->
 
 # Architecture de fondation Knowledge
 
@@ -226,7 +226,7 @@ Un webhook peut être perdu ou dupliqué. Le commit Git résolu reste l'identit
 
 ### Ownership de `0.0.2`
 
-La synchronisation partagée est une responsabilité de couche application, distincte du backend Git et des producteurs de signaux. La candidate existante `knowledge-app-lib` devient l'owner naturel si l'orchestration réelle confirme qu'une crate partagée est nécessaire ; elle n'est pas créée en `alpha.1` comme placeholder.
+La synchronisation partagée est une responsabilité de couche application, distincte du backend Git et des producteurs de signaux. `0.0.2-alpha.5` confirme cette responsabilité et matérialise `knowledge-app-lib` comme owner du cas d'usage provider-neutral ; les launchers n'ont pas à dupliquer cette orchestration.
 
 Sans PostgreSQL dans cette release, la dernière révision connue n'est pas stockée dans un fichier ad hoc caché. Le cas d'usage reçoit `previous_revision` de l'appelant et retourne explicitement la révision observée ainsi qu'un résultat `Changed` ou `Unchanged`. La future persistance pourra remplacer cet état appelant sans modifier la frontière Git.
 

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: 9 -->
+<!-- version: 10 -->
 
 # Plan 0.0.2 — Git générique et synchronisation de lecture
 
@@ -186,7 +186,7 @@ La revue de tranche a déclenché un REPLAN explicite : l'autonomie normative ap
 
 ### alpha.4 — autonomie normative et structure interne des crates
 
-Statut opérateur initial : **FAIL**.
+Statut opérateur initial : **FAIL**. `alpha.4.fix.1` : **PASS**. Tranche fermée.
 
 La matérialisation normative, les audits locaux, les façades crate-root, rustfmt et les métadonnées sont propres. La compilation échoue uniquement parce que `GitReference` et `GitRevision`, déplacés dans leurs modules propriétaires, tentent encore de construire leurs tuple structs privés via les réexports crate-root.
 
@@ -218,15 +218,19 @@ Gate attendue : audits Markdown locaux, audit d'autonomie, audits Rust incluant
 
 ### alpha.5 — cas d'usage de synchronisation
 
-Composer les primitives Git en un cas d'usage réellement consommable :
+La matérialisation de l'orchestration confirme un ownership application partagé : `knowledge-app-lib` devient justifiée et doit éviter que les trois launchers recomposent chacun le même flux.
 
+Scope :
+
+- créer `knowledge-app-lib` comme façade bibliothèque mince de cas d'usage partagés ;
 - enchaîner refresh, résolution, comparaison avec `previous_revision` et snapshot ;
-- retourner explicitement un résultat `Unchanged` ou `Changed` avec la révision observée ;
-- rendre la synchronisation explicite utilisable par un appelant ;
-- vérifier que `RepositorySyncTrigger::Periodic` peut emprunter la même voie sans matérialiser un scheduler artificiel ;
-- garder la persistance de dernière révision hors scope.
+- retourner explicitement `RepositorySyncOutcome::Unchanged` ou `RepositorySyncOutcome::Changed` avec la révision observée ;
+- préparer le snapshot uniquement lorsque la révision diffère de celle fournie par l'appelant ;
+- consommer `RepositorySyncSignal` sans donner de sémantique autoritaire à sa cause ;
+- prouver qu'une cause `Periodic` emprunte exactement le même cas d'usage qu'une cause explicite sans matérialiser de scheduler ;
+- garder la persistance de dernière révision, PostgreSQL, worker réseau, forge et publication Git hors scope.
 
-`knowledge-app-lib` n'est créée que si cette orchestration possède effectivement un ownership partagé et évite une duplication réelle. Sinon la tranche reste dans les crates déjà justifiées.
+La gate Rust applique désormais explicitement `cargo fmt --all`, puis `cargo fmt --all -- --check`, avant les audits du code Rust. Cette normalisation précède les contrôles structurels afin que les audits observent l'état réellement formaté.
 
 ### beta.1 — réconciliation et revue d'horizon
 

docs/rules/400-VALIDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/400-VALIDATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Validation locale Knowledge
 
@@ -79,12 +79,15 @@ Lorsqu'un audit lexical rencontre un cas que son modèle ne sait pas interpréte
 
 ## Ordre normal
 
-Pour une tranche Rust transverse, la séquence habituelle est :
+Pour une tranche Rust transverse, le formatter officiel normalise d'abord les sources. `cargo fmt --all` est une étape mutante volontaire et doit être exécutée avant tout audit du code Rust ; `cargo fmt --all -- --check` confirme immédiatement l'état obtenu.
+
+La séquence habituelle est :
 
 ```text
-format
--> audits structurels applicables
--> cargo check / metadata utile
+cargo fmt --all
+-> cargo fmt --all -- --check
+-> audits Rust structurels applicables
+-> cargo metadata / cargo check utiles
 -> clippy strict
 -> tests ciblés
 -> tests workspace si justifiés
@@ -92,6 +95,8 @@ format
 -> git diff --cached --check / status
 ```
 
+Les audits Markdown ou autres contrôles documentaires peuvent être exécutés avant ou après le formatage Rust puisqu'ils ne portent pas sur les sources Rust.
+
 Pour une tranche Web, les preuves npm/typecheck/build sont ajoutées lorsque `Web/` ou son contrat d'intégration est touché. Une tranche documentaire ou Rust sans diff Web ne rejoue pas automatiquement le frontend.
 
 ## Régression et dette externe

docs/rules/510-RUST_CARGO.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/510-RUST_CARGO.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Rust / Cargo local Knowledge
 
@@ -57,6 +57,8 @@ Les tests ne rendent pas l'API produit plus visible uniquement pour accéder à
 
 ## Formatage et audits
 
+Le formatter est appliqué, pas seulement interrogé : `cargo fmt --all` précède obligatoirement les audits du code Rust, puis `cargo fmt --all -- --check` vérifie immédiatement le résultat.
+
 La séquence normale d'un changement Rust pertinent inclut :
 
 ```bash

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 26 -->
+<!-- version: 27 -->
 
 # Matrice de validation Knowledge
 
@@ -700,3 +700,37 @@ Le correctif doit prouver :
 - `Cargo.lock` ignoré/non suivi et `git diff --cached --check` propre.
 
 Le `PASS` de `alpha.4.fix.1` ferme `alpha.4`, termine l'adoption PGR `v0.1.3` comme migration ponctuelle et autorise uniquement la préparation de `0.0.2-alpha.5`.
+
+## Ordre canonique des validations Rust à partir de `0.0.2-alpha.5`
+
+Toute gate qui audite du code Rust applique d'abord le formatter :
+
+```bash
+cargo fmt --all
+cargo fmt --all -- --check
+```
+
+Les audits Rust sont exécutés seulement après ces deux commandes. Viennent ensuite `cargo metadata`/`cargo check`, Clippy et les tests requis par le scope. Les audits Markdown peuvent être placés avant ou après cette séquence puisqu'ils ne lisent pas la forme du code Rust.
+
+## Gate de `0.0.2-alpha.5`
+
+La tranche de cas d'usage de synchronisation doit prouver :
+
+- `VERSION = 0.0.2-alpha.5` et version workspace identique ;
+- history `history/0.0.2/alpha.4.fix.1.md` présent avec statut `PASS` et committé avant application ;
+- neuf packages Cargo exactement, avec `knowledge-app-lib` comme nouvel owner application réel ;
+- `knowledge-app-lib` dépendant seulement de `knowledge-git-api` et `knowledge-sync-api` en production ;
+- `src/lib.rs` de `knowledge-app-lib` conforme au contrat de façade crate-root ;
+- cas d'usage public enchaînant refresh, résolution, comparaison de `previous_revision` puis snapshot seulement si changement ;
+- résultat explicite `Changed` / `Unchanged` exposant toujours la révision observée et le snapshot uniquement en cas de changement ;
+- absence de persistance implicite de la dernière révision ;
+- cause `Periodic` prouvée sur le même chemin que la synchronisation explicite, sans scheduler concret ;
+- aucune dépendance forge, PostgreSQL, Actix, worker réseau ou écriture Git dans `knowledge-app-lib` ;
+- `cargo fmt --all` exécuté avant tout audit Rust ;
+- `cargo fmt --all -- --check` exécuté immédiatement après le formatage et avant tout audit Rust ;
+- audits Rust locaux propres, y compris façade crate-root et complétude d'exports ;
+- `cargo metadata`, `cargo check --workspace`, Clippy strict, tests ciblés `knowledge-app-lib`/Git et tests workspace propres ;
+- `Web/` sans diff et `Cargo.lock` ignoré/non suivi ;
+- `git diff --cached --check` propre avant commit.
+
+Le `PASS` d'`alpha.5` ferme le scope fonctionnel alpha de `0.0.2` et autorise uniquement la préparation de `beta.1` de réconciliation et revue d'horizon.