Files
khadhroony-solana-project/deltas/0.0.2/pre.001-fix.002.md
2026-08-13 16:09:07 +02:00

99 lines
3.6 KiB
Markdown

<!-- file: deltas/0.0.2/pre.001-fix.002.md -->
<!-- version: 2 -->
# 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.