# Delta 0.1.2-pre.002-fix.001 ## Base requise Livraison précédente : ```text 0.1.2-pre.002 ``` Ce correctif traite uniquement les résultats de validation remontés après `pre.002`. Il ne modifie pas le périmètre fonctionnel de la prerelease et n'ouvre pas `pre.003`. ## Résultats de validation à corriger Les commandes exécutées sur le workspace de développement ont montré : - `cargo fmt --all` : exécuté sans erreur ; - `cargo check --workspace` : réussi ; - `cargo clippy --workspace --all-targets` : terminé avec quatre catégories de warnings à nettoyer dans Logging/tests ; - `cargo test --workspace` : tous les tests Core et les tests unitaires Logging réussissent, mais `async_instrumentation_enters_and_exits_span_during_poll` échoue avec `enters = 2` au lieu de l'attente `1`. ## Cause du test async Le test `pre.002` supposait qu'une future instrumentée n'entrait dans son span que pendant son unique `poll`. Le contrat de `tracing::Instrument` est plus précis : la future instrumentée entre dans le span lors de chaque `poll` **et lors de son `Drop`**. Pour `std::future::ready(42_u32)`, le test observe donc : ```text poll -> enter + exit Drop -> enter + exit ``` Le compteur final `2` est donc conforme au comportement de `tracing`; c'est l'attente du test qui était incorrecte. Le test corrigé vérifie séparément : 1. une paire `enter` / `exit` immédiatement après le `poll` ; 2. une deuxième paire après destruction explicite de la future instrumentée ; 3. l'équilibre final entre le nombre d'entrées et de sorties. Le plan actif documente désormais explicitement cette sémantique afin qu'un futur test async ne réintroduise pas l'hypothèse erronée d'une seule paire `enter` / `exit` sur toute la durée de vie d'une future. ## Nettoyage Clippy ### `collapsible_if` La validation du préfixe de fichier utilise désormais un `if let` avec condition chaînée compatible Rust 2024 au lieu de deux `if` imbriqués. ### `double_must_use` L'attribut `#[must_use]` explicite de `ksp_logging_lib::instrument(...)` est supprimé : la fonction retourne déjà un type `Future`, lui-même marqué `must_use` par son contrat standard. ## Documentation des tests d'intégration Les crates de tests d'intégration : ```text crates/ksp-logging-lib/tests/callsite.rs crates/ksp-logging-lib/tests/public_api.rs ``` reçoivent chacune une documentation crate-root `//! ...` afin de satisfaire `missing_docs = "warn"` lorsque les tests sont compilés comme crates séparées. ## Version Cargo La version reste : ```text 0.1.2-pre.2 ``` Aucune dépendance et aucun manifest ne sont modifiés. L'identifiant de livraison de ce correctif est : ```text 0.1.2-pre.002-fix.001 ``` ## Fichiers modifiés - `crates/ksp-logging-lib/src/settings.rs` - `crates/ksp-logging-lib/src/span.rs` - `crates/ksp-logging-lib/tests/callsite.rs` - `crates/ksp-logging-lib/tests/public_api.rs` - `docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md` ## Fichier ajouté - `deltas/0.1.2/pre.002-fix.001.md` ## Validations statiques exécutées lors de la préparation - contrôle des headers `file:` / `version:` des fichiers du correctif ; - contrôle que `Cargo.toml` n'est pas inclus dans le delta ; - contrôle que la version Cargo de la base reste `0.1.2-pre.2` ; - contrôle de l'absence de nouvelle dépendance ; - contrôle que le correctif ne contient aucun ajout `unwrap`, `expect`, `panic` ou opérateur `?` dans le code production modifié ; - contrôle que l'archive contient uniquement les cinq fichiers modifiés et le nouveau delta. ## Validations à réexécuter sur le workspace ```bash cargo fmt --all cargo check --workspace cargo test --workspace cargo clippy --workspace --all-targets ``` Puis, pour compléter les validations prévues pour `pre.002` si elles ne l'ont pas encore été : ```bash cargo tree -p ksp-logging-lib cargo tree -p ksp-logging-lib -d cargo tree -p ksp-logging-lib -e features ``` Aucune validation Cargo non exécutable dans l'environnement de préparation n'est déclarée réussie par ce delta. ## Suite Une fois ce correctif validé, `0.1.2-pre.002` peut être considérée propre et la session peut passer à `0.1.2-pre.003` pour le subscriber runtime, le takeover, le filtering, la console non bloquante et la fondation du hot reload.