v0.1.3-pre.011

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Plans KSP
 
@@ -13,7 +13,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 - [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles ;
 - [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à `0.1.1-rel.001`.
 - [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
-- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan actif de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, complété par `pre.001-fix.002` pour le registre `file_id`/bootstrap/non-régression Logging, regranularisé par `pre.001-fix.003`, puis rescindé pendant `pre.005`; `pre.006` a fermé le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema et le premier `std.logging.json`, `pre.008` la résolution globals/profils/`default_profile`, puis `pre.009` les compositions génériques par `file_id`; `pre.010` a livré `.env`, process env, `.env.example` et le resolver `${...}`; `pre.011` poursuivra avec sensibilité, valeur réelle/sûre et provenance.
+- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan actif de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, complété par `pre.001-fix.002` pour le registre `file_id`/bootstrap/non-régression Logging, regranularisé par `pre.001-fix.003`, puis rescindé pendant `pre.005`; `pre.006` a fermé le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema et le premier `std.logging.json`, `pre.008` la résolution globals/profils/`default_profile`, puis `pre.009` les compositions génériques par `file_id`; `pre.010` a livré `.env`, process env, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeur réelle/sûre, redaction et provenance; `pre.012` poursuivra avec l'adapter Config -> Logging.
 
 Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
 

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -219,7 +219,7 @@ pre.015  clôture
 
 Cette prévision n'est pas un plafond : chaque prerelease doit rester une petite tranche, avec scission explicite si l'objectif dépasse environ 15–20 minutes de travail effectif.
 
-`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` a ajouté les compositions génériques par `file_id`, avec `schema.composite` mais sans composite runtime fictif; `pre.010` ajoute le snapshot process + `.env`, `.env.example` et le resolver `${...}`. Après validation utilisateur, `pre.011` ajoutera sensibilité, valeur réelle/sûre et provenance enrichie.
+`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` a ajouté les compositions génériques par `file_id`, avec `schema.composite` mais sans composite runtime fictif; `pre.010` a ajouté le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeurs réelle/sûre, redaction et provenance enrichie. Après validation utilisateur, `pre.012` construira l'adapter Config -> Logging.
 
 ## `0.1.4` — Config desktop par défaut
 

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: 13 -->
+<!-- version: 14 -->
 
 # 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, `pre.005` le runtime multi-sink sur niveau/target/formats, `pre.006` le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema, `pre.008` la résolution des globals/profils/`default_profile`, `pre.009` les compositions génériques par `file_id` et `pre.010` le snapshot process + `.env` et le resolver `${...}`. La prochaine tranche est `pre.011` pour sensibilité, valeur réelle/sûre et provenance enrichie.
+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, `pre.006` le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema, `pre.008` la résolution des globals/profils/`default_profile`, `pre.009` les compositions génériques par `file_id`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, puis `pre.011` la sensibilité et les représentations real/safe/provenance. La prochaine tranche est `pre.012` pour l'adapter Config -> Logging.
 
 La base auditée reste la release stable `v0.1.2`.
 
@@ -583,6 +583,8 @@ Décisions :
 
 - `logs_directory` est global, hors profils ;
 - son fallback est exprimé dans le document au point d'usage ;
+- après interpolation, `logs_directory` peut être absolu ou relatif ; un chemin relatif est interprété relativement au current working directory du processus qui initialise Logging, et non automatiquement relativement au répertoire du binaire ;
+- un `KSP_LOGS_DIRECTORY` explicitement présent mais invalide n'active jamais le fallback : le fallback reste réservé à l'absence de la variable et l'adapter Config -> Logging doit retourner un diagnostic de configuration effective invalide ;
 - `default_profile` est global et référence un `profile_id` existant ;
 - `profile_id` est obligatoire et unique dans le document ;
 - `default_filter` gouverne le comportement général du profil ;
@@ -1802,15 +1804,23 @@ Tranche livrée :
 - la règle durable impose désormais d'ajouter toute nouvelle variable runtime KSP/KSPB à `.env.example`, avec commentaire d'usage, dans le même delta que sa première utilisation ;
 - `.gitignore` possédait déjà la règle correcte `.env`, `.env.*`, `!.env.example`; aucun changement n'est nécessaire.
 
+La validation utilisateur de `pre.010-fix.001` est acquise : `fmt/check/clippy/test` passent, les 53 tests unitaires Config et 8 tests publics passent, et le graphe Cargo reste conforme avec le doublon transitif `syn 2`/`syn 3` déjà connu via `jsonschema`.
+
 ### `0.1.3-pre.011` — sensibilité + valeurs real/safe/provenance
 
-- `Public/Internal/Secret` ;
-- propagation de sensibilité par chaîne composée ;
-- redaction par segment ;
-- contrat `ResolvedValue` ou équivalent ;
-- valeur réelle + représentation sûre + provenance ;
-- interdiction des secrets dans logs/diagnostics ordinaires ;
-- tests canary de non-divulgation.
+Tranche livrée :
+
+- `ConfigSensitivity::{Public, Internal, Secret}` dérive la classification directement des namespaces KSP/KSPB et conserve l'ordre `Secret > Internal > Public` ;
+- `ConfigEnvironmentValue` conserve désormais valeur réelle, valeur sûre, sensibilité, source et provenance ; son `Debug` utilise uniquement la valeur sûre ;
+- `ResolvedConfigText` conserve la chaîne réelle, sa représentation sûre, la sensibilité la plus forte et une provenance ordonnée ;
+- les segments issus de `KSP_SECRET_*`/`KSPB_SECRET_*` sont remplacés par `********` dans la représentation sûre, y compris lorsqu'ils viennent d'un fallback ;
+- les chaînes composées propagent la sensibilité la plus forte des placeholders utilisés ; une chaîne sans placeholder est `Internal` ;
+- `ConfigValueProvenance` distingue `DocumentLiteral`, `EnvironmentProcess`, `EnvironmentDotEnv` et `EnvironmentFallback` sans embarquer les valeurs elles-mêmes ;
+- `ResolvedConfigJson` conserve arbres réel/sûr, sensibilité agrégée et provenance indexée par JSON Pointer ;
+- les APIs existantes `resolve_text`, `resolve_json` et `resolve_effective_environment` restent compatibles et retournent uniquement les valeurs réelles ; les variantes `*_detailed` exposent le contrat enrichi ;
+- la provenance Global/Profile déjà portée par `ResolvedConfigProfile` reste distincte et inchangée ; `resolve_effective_environment_detailed` ajoute la provenance de la couche environnement ;
+- des canaries de tests vérifient qu'une valeur secrète process, fallback ou imbriquée dans un JSON n'apparait pas dans `safe_value` ni dans `Debug` ;
+- aucune nouvelle dépendance Cargo et aucune nouvelle variable d'environnement ne sont introduites dans cette tranche.
 
 ### `0.1.3-pre.012` — adapter Config -> Logging