5.0 KiB
History 0.0.2-alpha.5 — cas d'usage partagé de synchronisation
Statut
PASS
La gate opérateur de 0.0.2-alpha.5 exécutée le 2026-09-28 est propre. La tranche matérialise knowledge-app-lib comme owner du cas d'usage partagé de synchronisation de lecture et rend durable l'ordre de validation Rust cargo fmt --all puis cargo fmt --all -- --check avant les audits du code Rust.
Baseline opérateur
alpha.4.fix.1 PASS a été historisé, committé et poussé avant application de alpha.5 :
history/0.0.2/alpha.4.fix.1.md PASS
commit 1fe39df
message 0.0.2-alpha.4.fix.1
branch master
push origin/master PASS
workspace après push propre
Le push observé a avancé origin/master de 3f8c795 à 1fe39df.
Version, documentation et formatage
Les contrôles passent :
VERSION 0.0.2-alpha.5
Cargo workspace version 0.0.2-alpha.5
git diff --check PASS
Markdown header audit clean (84 file(s))
Markdown link audit clean (71 local link(s), 84 file(s))
Markdown table audit clean (4 table(s), 84 file(s))
cargo fmt --all PASS
cargo fmt --all -- --check PASS
Le formatter est exécuté avant les audits Rust, conformément au contrat local désormais possédé par Knowledge.
Audits Rust
Après formatage, les audits Rust passent :
Rust test-layout audit: clean (9 crate(s))
Rust blank-line audit: clean (32 file(s))
Rust item-spacing audit: clean (32 file(s))
Rust module-order audit: clean (32 file(s))
Rust trait-import-block audit: clean (32 file(s))
Rust re-export-block audit: clean (32 file(s))
Rust crate-root facade audit: clean (6 crate root(s))
Rust export completeness audit: 0 candidate(s) across 9 package(s)
Compilation et Clippy
Les commandes suivantes passent :
cargo metadata --format-version 1 --no-deps PASS
cargo check --workspace PASS
cargo clippy --workspace --all-targets --all-features
-- -D warnings PASS
Les neuf packages attendus sont détectés, dont le nouveau knowledge-app-lib.
Cas d'usage de synchronisation
knowledge-app-lib compose les contrats existants sans introduire de persistance, de scheduler ou de forge :
RepositorySyncSignal
-> GitRepository::refresh
-> GitRepository::resolve_revision
-> comparaison previous_revision
-> RepositorySyncOutcome::Unchanged
ou
-> GitRepository::prepare_snapshot
-> RepositorySyncOutcome::Changed
Les trois tests ciblés passent :
changed_revision_prepares_snapshot_and_returns_observed_revision PASS
unchanged_revision_does_not_prepare_snapshot PASS
periodic_signal_uses_the_same_reconciliation_path PASS
La cause Periodic emprunte donc le même cas d'usage que la synchronisation explicite sans matérialiser de scheduler concret.
Tests ciblés et workspace
Les suites ciblées passent :
knowledge-app-lib 3 PASS
knowledge-git-api 1 PASS
knowledge-git-lib 8 unit PASS + 2 integration PASS
knowledge-sync-api 1 PASS
La suite workspace passe intégralement :
knowledge-app-lib 3 PASS
knowledge-domain-lib 3 PASS
knowledge-git-api 1 PASS
knowledge-git-lib 8 unit PASS + 2 integration PASS
knowledge-sync-api 1 PASS
knowledge-web-lib 4 PASS
launchers 0 test chacun
Les deux tests d'intégration Git réels continuent de prouver refresh, résolution, snapshots, référence invalide et snapshot sale.
Contrôles structurels et frontières
L'audit spécifique passe :
Knowledge 0.0.2-alpha.5 sync/format-order audit: clean
Il confirme notamment :
- neuf packages Cargo exactement ;
knowledge-app-libdépend uniquement deknowledge-git-apietknowledge-sync-apien production ;knowledge-domain-libreste uniquement une dépendance de test pour cette crate ;Changed/Unchanged,previous_revision, refresh, résolution et snapshot sont matérialisés ;- aucune dépendance PostgreSQL, Gitea/GitHub/GitLab, Actix, Tokio ou scheduler dans le cas d'usage ;
cargo fmt --allprécède les audits Rust dans les owners locaux de validation.
Cargo.lock est présent localement, ignoré et non suivi. Web/ reste sans diff. Aucun adapter forge ni store PostgreSQL n'est créé.
Après staging, git diff --cached --check passe.
Décision
0.0.2-alpha.5 est PASS.
Le scope fonctionnel alpha de 0.0.2 est fermé. La transition autorisée est :
appliquer ce history
-> git add / diff --cached --check / status
-> commit exact "0.0.2-alpha.5"
-> push origin master
-> vérifier le workspace propre
-> appliquer seulement ensuite 0.0.2-beta.1
beta.1 doit rester une tranche de réconciliation, stabilisation et revue d'horizon sans grande fonctionnalité nouvelle.