khadhroony-solana-project/deltas/0.1.2/pre.006.md

<!-- file: deltas/0.1.2/pre.006.md -->
<!-- version: 1 -->

# Delta 0.1.2-pre.006

## Base requise

Livraison précédente validée :

```text
0.1.2-pre.005-fix.001
```

La base porte :

```text
workspace.package.version = "0.1.2-pre.5.fix.1"
Cargo.toml header version = 37
```

## Validation de la base

La validation utilisateur de `pre.005-fix.001` est propre :

```text
cargo fmt --all                                                        OK
cargo check --workspace                                               OK
cargo clippy --workspace --all-targets                                OK
cargo test --workspace                                                OK
cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture OK
```

Le stress test concurrent ne produit plus le flux TRACE parasite corrigé par `pre.005-fix.001`.

Le probe diagnostic d'overhead a passé son garde-fou sur 200000 itérations :

```text
baseline = 19.658553 ms
reload   = 28.807958 ms
```

Ces nombres restent des observations diagnostiques et non un benchmark contractuel.

## Objet de pre.006

`pre.006` est la prerelease finale prévue de `0.1.2`.

Elle :

- ajoute une validation des spans async sur un executor Tokio réel ;
- garde Tokio hors des dépendances runtime de `ksp-logging-lib` ;
- consolide la documentation de la crate ;
- ferme les TODO de prerelease ;
- prépare le prompt final de `0.1.3 — ksp-config-lib` ;
- prépare les validations finales précédant `rel.001`.

## Tokio uniquement pour les tests

Version actuelle vérifiée le 2026-08-14 :

```text
tokio 1.53.1
```

Le workspace centralise une contrainte de génération :

```toml
tokio = { version = "^1.53", default-features = false, features = ["rt", "rt-multi-thread", "macros"] }
```

`ksp-logging-lib` le consomme uniquement comme dev-dependency :

```toml
[dev-dependencies]
tokio.workspace = true
```

Aucun source de production de Logging n'importe Tokio. L'API `instrument(span, future)` reste fondée sur `std::future::Future` et reste indépendante de l'executor choisi par le consumer.

## Tests Tokio réels

Nouveau fichier :

```text
crates/ksp-logging-lib/tests/tokio_span.rs
```

### Current-thread

Le premier test utilise :

```text
#[tokio::test(flavor = "current_thread")]
```

Il instrumente une future contenant plusieurs `tokio::task::yield_now().await` et utilise un subscriber de test associé au span pour compter les `enter`/`exit`.

Le test exige plusieurs ré-entrées du span après suspension et un nombre final d'entrées/sorties identique.

### Multi-thread

Le second test utilise :

```text
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
```

Deux futures instrumentées sont lancées avec `tokio::spawn`, effectuent des suspensions répétées puis doivent terminer normalement. Le test vérifie également l'équilibre des `enter`/`exit`.

Ce test démontre l'utilisation correcte de la surface KSP sous un runtime Tokio multi-thread ; il ne prétend pas imposer ni mesurer une migration déterministe d'une même future entre worker threads.

## Documentation finale

Mises à jour :

- `crates/ksp-logging-lib/README.md` : indépendance de l'executor en production et statut test-only de Tokio ;
- `crates/ksp-logging-lib/USAGE.md` : exemple async et frontière executor ;
- `crates/ksp-logging-lib/TODO.md` : seules restent les validations finales et la future livraison stable ;
- `docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md` : statut validé de `pre.005-fix.001`, contenu `pre.006`, validations finales et absence de question architecturale bloquante ;
- `prompts/000-README.md` : ajout du prompt Config ;
- `prompts/003-V0_1_3_START_PROMPT.md` : prompt final pour ouvrir `0.1.3` après `v0.1.2`.

`ROADMAP.md` reste volontairement inchangé : `0.1.2` demeure en cours tant que `rel.001` et le tag `v0.1.2` ne sont pas validés.

Aucun changelog général n'existe actuellement dans le dépôt ; `pre.006` n'en crée pas artificiellement un.

## Version technique

La prerelease devient :

```text
workspace.package.version = "0.1.2-pre.6"
```

L'en-tête du manifest racine devient :

```text
# version: 38
```

Le manifest de `ksp-logging-lib` devient :

```text
# version: 4
```

## Fichiers du delta

```text
Cargo.toml
crates/ksp-logging-lib/Cargo.toml
crates/ksp-logging-lib/README.md
crates/ksp-logging-lib/TODO.md
crates/ksp-logging-lib/USAGE.md
crates/ksp-logging-lib/tests/tokio_span.rs
docs/plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
prompts/000-README.md
prompts/003-V0_1_3_START_PROMPT.md
deltas/0.1.2/pre.006.md
```

## Validations finales à exécuter

```bash
cargo fmt --all
cargo check --workspace
cargo build -p ksp-logging-lib
cargo clippy --workspace --all-targets
cargo test --workspace
cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture
cargo tree -p ksp-logging-lib
cargo tree -p ksp-logging-lib -d
cargo tree -p ksp-logging-lib -e features
cargo tree -p ksp-logging-lib -e normal
cargo tree -p ksp-logging-lib -e dev
```

Contrôles attendus en particulier :

- les deux tests de `tests/tokio_span.rs` passent ;
- `cargo build -p ksp-logging-lib` reste un build normal sans Tokio comme dépendance runtime ;
- le graphe `-e normal` n'inclut pas Tokio ;
- Tokio est visible uniquement via l'usage dev attendu ;
- aucune seconde version évitable n'apparaît ;
- l'audit ownership continue à interdire les contournements de la façade tracing.

Aucune validation Cargo n'est déclarée réussie dans ce delta avant exécution dans l'environnement de développement.

## Suite après validation

Si `pre.006` est propre, la prochaine livraison est :

```text
0.1.2-rel.001
```

Elle publiera :

```text
workspace.package.version = "0.1.2"
```

puis, après validation utilisateur, le commit final recevra :

```text
v0.1.2
```

La session fonctionnelle suivante pourra alors démarrer avec :

```text
prompts/003-V0_1_3_START_PROMPT.md
```