# History 0.0.3-alpha.1 — cadrage de l'écriture Git contrôlée ## Statut `PARTIAL` ## Baseline observée La tranche a été appliquée sur la stable autoritaire `v0.0.2` puis a porté `VERSION` et le workspace Cargo à : ```text 0.0.3-alpha.1 ``` ## Preuves opérateur reçues Les preuves transmises le `2026-09-29` montrent : - contrôle `VERSION` / `workspace.package.version` conforme ; - `git diff --check` propre ; - audits Markdown headers/liens/tables propres ; - `cargo fmt --all` puis `cargo fmt --all -- --check` PASS ; - audits Rust structurels propres sur les neuf crates / trente-deux fichiers concernés ; - `cargo metadata --format-version 1 --no-deps` exécuté ; - `cargo check --workspace` PASS ; - `cargo clippy --workspace --all-targets --all-features -- -D warnings` PASS ; - `cargo test -p knowledge-git-lib --test git_read_path` : `2 passed` ; - `cargo test --workspace --all-targets --all-features` : tous les tests observés PASS. Les comptes observés dans la gate workspace restent cohérents avec la stable : ```text knowledge-app-lib 3 PASS knowledge-domain-lib 3 PASS knowledge-git-api 1 PASS knowledge-git-lib 8 unit + 2 integration PASS knowledge-sync-api 1 PASS knowledge-web-lib 4 PASS launchers 0 test chacun, compilation PASS ``` ## Limites de la gate reçue Le retour fourni s'arrête après `cargo test --workspace --all-targets --all-features`. Les commandes de fin annoncées dans le delta `alpha.1` ne sont donc pas présentées comme exécutées : - audit Python spécifique de cadrage `alpha.1` ; - audit d'hygiène texte ; - vérifications finales `crates/` / `Web/`, lockfiles et absence de history prématuré ; - `git add -A`, `git diff --cached --check` et `git status --short`. Cette absence suffit à empêcher un statut `PASS` intégral de la gate telle qu'elle était spécifiée. ## Revue opérateur du cycle documentaire La revue manuelle a en outre identifié trois corrections de gouvernance/documentation à matérialiser avant de poursuivre le développement fonctionnel : 1. `CHANGELOG.md` ne doit pas être rédigé au démarrage d'une release ; il doit synthétiser les changements réellement acquis vers les phases de stabilisation/fin de release ; 2. le prompt de démarrage de la release suivante doit normalement être préparé pendant les dernières phases de la release en cours, après revue d'horizon ; l'ajout de `prompts/003-V0_0_3_START_PROMPT.md` pendant `0.0.3-alpha.1` est accepté uniquement comme rattrapage parce que `0.0.2` avait été fermée sans ce handoff ; 3. `ROADMAP.md` doit montrer à la fois la release en cours et un horizon borné des releases suivantes, en distinguant clairement l'engagement courant des versions d'horizon encore révisables. Ces défauts ne remettent pas en cause la mission Git choisie pour `0.0.3`, mais rendent le cadrage documentaire incomplet. ## Décision `0.0.3-alpha.1` est conservée avec le statut `PARTIAL`. La correction reste bornée au workflow documentaire et utilise : ```text 0.0.3-alpha.1.fix.1 ``` Le fix doit : - retirer la section candidate `0.0.3` prématurée du changelog ; - transformer la roadmap en roadmap courante + horizon prévisionnel ; - rendre explicite chez les owners locaux le moment de rédaction du changelog et du prompt de release suivante ; - mettre à jour le plan `0.0.3` pour refléter cette correction sans modifier la mission Git ; - ne modifier aucun code sous `crates/` ni aucun fichier sous `Web/`.