# Delta 0.0.2-pre.001-fix.002 ## Base requise `0.0.2-pre.001` avec les corrections de `0.0.2-pre.001-fix.001`. ## Objectifs - formaliser la règle de synchronisation sélective entre identifiant de delta et version Cargo ; - distinguer la politique de commit de la phase fondatrice de celle applicable à partir de `0.1.x` ; - expérimenter temporairement une séparation physique des tests unitaires hors de `src/` ; - vérifier simultanément qu'un vrai test d'intégration n'utilise que l'API publique. ## Version Cargo Cette livraison ajoute/modifie des fichiers `.rs`. Conformément à la règle proposée, le `Cargo.toml` racine passe donc à : ```text 0.0.2-pre.1.fix.2 ``` La version Cargo correspond à la livraison `0.0.2-pre.001-fix.002`. ## Fichiers modifiés - `Cargo.toml` ; - `crates/ksp-core-lib/src/lib.rs` ; - `docs/rules/FILE_CONTRACTS.md` ; - `docs/rules/RULES_RUST.md` ; - `docs/rules/VERSION_WORKFLOW.md`. ## Fichiers ajoutés temporairement - `crates/ksp-core-lib/src/test_layout_probe.rs` ; - `crates/ksp-core-lib/tests/unit/test_layout_probe.rs` ; - `crates/ksp-core-lib/tests/public_api.rs`. Ces trois fichiers, ainsi que les modifications de `lib.rs` associées, sont un banc d'essai et devront être retirés après décision sur la convention de tests. ## Expérience attendue `src/test_layout_probe.rs` contient : - une fonction publique temporaire réexportée au crate-root ; - une fonction privée ; - un module de test `#[cfg(test)]` dont la source physique est `tests/unit/test_layout_probe.rs`. Le fichier `tests/unit/test_layout_probe.rs` doit : - être exécuté dans la cible de tests unitaires de `ksp-core-lib` ; - pouvoir appeler la fonction privée via `super::...` ; - ne pas apparaître comme une cible d'intégration autonome. Le fichier `tests/public_api.rs` doit : - être compilé comme test d'intégration Cargo distinct ; - utiliser seulement `ksp_core_lib::public_increment_probe` ; - valider la façade publique de la crate. ## Commandes de validation demandées ```bash cargo fmt --all cargo check --workspace cargo test --workspace cargo clippy --workspace --all-targets ``` Pour confirmer précisément le découpage des tests, conserver aussi la sortie complète de : ```bash cargo test -p ksp-core-lib ``` Le résultat recherché est une section `Running unittests ...` contenant le test privé, une cible `tests/public_api.rs` contenant le test public, et aucune cible autonome correspondant à `tests/unit/test_layout_probe.rs`. ## Critère de décision - si cette structure fonctionne proprement avec Cargo, rustfmt, Clippy et les règles de visibilité KSP, elle pourra être généralisée après suppression du probe ; - si elle échoue ou introduit une complexité disproportionnée, les tests unitaires resteront dans le module qu'ils testent ; - dans les deux cas, les tests de l'API publique devront être placés en tests d'intégration lorsque cela est techniquement possible. ## Validations effectuées lors de la préparation - reconstruction statique de la base `pre.001 + fix.001` ; - vérification des chemins et versions de fichiers ; - vérification TOML syntaxique avec Python pour les manifestes/configurations concernés. ## Validations non exécutées Les commandes Cargo n'ont pas été exécutées dans l'environnement de préparation, qui ne fournit pas `cargo`/`rustc`. La validation décisive doit donc être réalisée dans le workspace KSP local. ## Temporaire Cette livraison ne décide pas encore définitivement de la disposition des tests. Le code `test_layout_probe` est explicitement temporaire et doit disparaître après l'expérience.