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 à :

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 :

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 :

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 ;
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 ;
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 :

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/.

3.5 KiB Raw Blame History