v0.1.3-pre.006

docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Plan `0.1.3` — Configuration foundation
 
 ## 1. Statut et objectif
 
-Ce plan a été établi par `0.1.3-pre.001`, corrigé par `0.1.3-pre.001-fix.001/.002/.003`, puis exécuté par petites tranches. `pre.002` a livré le bootstrap Config, `pre.003` le registre `file_id`, `pre.004` les contrats publics multi-output de Logging, et `pre.005` active le runtime multi-sink sur niveau/target/formats. Le routing structuré `domain` est scindé en `pre.006` avant le gel du premier schema Logging.
+Ce plan a été établi par `0.1.3-pre.001`, corrigé par `0.1.3-pre.001-fix.001/.002/.003`, puis exécuté par petites tranches. `pre.002` a livré le bootstrap Config, `pre.003` le registre `file_id`, `pre.004` les contrats publics multi-output de Logging, `pre.005` le runtime multi-sink sur niveau/target/formats et `pre.006` ferme le routing structuré `domain`. Le premier schema Logging peut donc commencer en `pre.007` après validation utilisateur de cette tranche.
 
 La base auditée reste la release stable `v0.1.2`.
 
@@ -1677,23 +1677,31 @@ Implémentation candidate de `pre.005` :
 - JSON + ANSI console est refusé comme combinaison incohérente ;
 - aucune dépendance Config n'entre dans Logging.
 
-La validation utilisateur de `pre.005` est requise avant l'ouverture de `pre.006`.
+`pre.005` a d'abord révélé une assertion d'intégration JSON incorrecte : le message de test contenait lui-même une séquence ANSI que le formatter JSON sérialisait comme donnée échappée. `pre.005-fix.001` a séparé le test JSON du test de stripping ANSI sans modifier le runtime. L'utilisateur a ensuite validé `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets`, `cargo test --workspace` et les trois vues `cargo tree -p ksp-logging-lib` sans warning ni échec.
 
 ### `0.1.3-pre.006` — `ksp-logging-lib` : routing structuré `domain`
 
 Objectif unique : fermer proprement la dimension `OutputFilter.domains[]` avant que Config ne fige le schema Logging.
 
-- extraire le champ structuré `domain` des events/spans ;
-- définir la sémantique d'un event portant son propre `domain` ;
-- définir l'héritage depuis le span courant lorsqu'un event ne porte pas de `domain` ;
-- définir le comportement des spans sans domain et des spans imbriqués ;
-- appliquer les selectors domain par output sans casser level/target ;
-- conserver les événements lifecycle `SpanEvents` cohérents avec le domain du span ;
-- préserver les champs formatés requis par les différents formatters ;
-- conserver hot reload, takeover et non-blocking ;
-- tests unitaires/intégration sur events, spans, héritage et plusieurs sinks.
+Implémentation candidate livrée par `pre.006` :
 
-Une solution qui réduirait `domain` à une convention de target est interdite : il s'agit d'une dimension structurée distincte.
+- `domain` reste un champ structuré distinct du target et n'est jamais converti en pseudo-target ;
+- une couche interne `DomainContextLayer` capture le `domain` effectif avant les formatters de sortie ;
+- un event portant directement `domain` remplace le domain hérité pour cet event ;
+- un event sans `domain` hérite du domain effectif de son span ;
+- un span portant `domain` définit son domain effectif ;
+- un span sans `domain` hérite du domain effectif de son parent au moment de sa création ;
+- les lifecycle events `NEW/ENTER/EXIT/CLOSE` utilisent le domain effectif du span concerné ;
+- `domains = ["*"]` reste l'absence de restriction et accepte aussi les events/spans sans domain ;
+- un selector domain nommé correspond par préfixe et ne sélectionne pas une entrée sans domain ;
+- le writer applique conjointement `level`, `target` et le domain effectif ;
+- la politique globale de takeover KSP, le subscriber unique, le hot reload transactionnel et les writers non bloquants restent inchangés ;
+- le contexte domain est thread-local interne au dispatch Logging et n'entre pas dans les contrats publics ;
+- les tests couvrent domain direct, absence de domain, héritage parent/enfant, override d'event, override de span enfant, lifecycle et trois sinks domain distincts.
+
+Aucune dépendance externe ou feature Cargo supplémentaire n'est nécessaire pour cette tranche. `pre.007` peut donc construire `std.logging.schema.json` sur une surface Logging qui représente et exécute réellement les trois dimensions de routing retenues : level, target et domain.
+
+La validation utilisateur de `pre.006` reste requise avant l'ouverture de `pre.007`.
 
 ### `0.1.3-pre.007` — JSON/JSON Schema + premier document Logging