<!-- file: deltas/0.1.3/pre.005-fix.001.md -->
<!-- version: 1 -->

# Delta 0.1.3-pre.005-fix.001

## Base requise

Livraison précédente :

```text
0.1.3-pre.005
```

Version technique de cette base :

```text
workspace.package.version = "0.1.3-pre.5"
Cargo.toml header version = 45
```

Validations utilisateur exécutées le 2026-08-15 :

```text
cargo fmt --all                         OK
cargo check --workspace                 OK
cargo clippy --workspace --all-targets  OK
cargo test --workspace                  FAILED — 1 test d'intégration Logging
cargo tree -p ksp-logging-lib            OK
cargo tree -p ksp-logging-lib -d         OK — aucune duplication
cargo tree -p ksp-logging-lib -e features OK
```

Échec isolé :

```text
global_runtime_supports_takeover_non_blocking_outputs_hot_reload_and_single_initialization
assertion failed: json_text.contains("logging info marker")
```

## Cause

Le test utilisait le même event pour vérifier deux comportements différents :

```text
logging info <ANSI>marker</ANSI>
```

Cet event était envoyé à la fois au sink `Human` et au sink `Json`.

Pour le sink humain, `StripAnsiWriter` reçoit les octets ANSI bruts après formatage et les supprime, ce qui produit bien :

```text
logging info marker
```

Pour le formatter JSON, les caractères de contrôle présents dans la valeur structurée sont échappés par le JSON avant l'écriture. La représentation persistée contient donc une forme JSON échappée de l'ESC plutôt qu'une séquence terminal brute ; la sous-chaîne littérale `logging info marker` n'est alors plus contiguë.

L'échec provenait donc d'une hypothèse incorrecte du test et non d'une perte de l'event par le routing multi-sink.

## Correction

Le test d'intégration sépare désormais les responsabilités :

- `LOGGING_TARGET` continue de vérifier le sink `Human` et le stripping ANSI persistant ;
- un target KSP dédié `JSON_KSP_TARGET = "ksp-logging-json-test"` alimente le sink JSON ;
- les events JSON utilisent des messages neutres : `json info marker` et `json error marker` ;
- les assertions JSON vérifient ces marqueurs et le target JSON dédié ;
- le routing indépendant par target reste ainsi testé explicitement sans dépendre de la représentation d'échappement JSON d'un caractère de contrôle.

Aucun code runtime de `ksp-logging-lib` n'est modifié.

## Version technique

Comme un fichier Rust de test est modifié :

```text
workspace.package.version = "0.1.3-pre.5.fix.1"
Cargo.toml header version = 46
crates/ksp-logging-lib/tests/runtime.rs header version = 7
```

## Fichiers modifiés

```text
Cargo.toml
crates/ksp-logging-lib/tests/runtime.rs
```

## Fichier ajouté

```text
deltas/0.1.3/pre.005-fix.001.md
```

## Hors scope

Ce fix n'ouvre pas `pre.006` et ne modifie pas :

- le runtime multi-sink ;
- le routing `level`/`target` ;
- le futur routing structuré `domain` ;
- Config, JSON Config ou JSON Schema ;
- les dépendances ou features Cargo.

## Validations à exécuter

```bash
cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace
cargo tree -p ksp-logging-lib
cargo tree -p ksp-logging-lib -d
cargo tree -p ksp-logging-lib -e features
```

Aucune validation Cargo n'est déclarée réussie tant qu'elle n'a pas été exécutée sur le workspace utilisateur.