v0.1.3-pre.014

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 20 -->
+<!-- version: 21 -->
 
 # 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` ajoute sensibilité, valeur réelle/sûre, redaction et provenance; `pre.012` a livré l'adapter Config -> Logging et la validation effective des chemins Logging; `pre.013` livre management/persistence JSON/.env; `pre.014` poursuivra avec ownership audits/robustesse.
+- [`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` a livré l'adapter Config -> Logging et la validation effective des chemins Logging; `pre.013` a livré management/persistence JSON/.env; `pre.014` ajoute les ownership audits exécutables et la vérification automatique de `.env.example`; `pre.015` assurera la clôture.
 
 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: 18 -->
+<!-- version: 19 -->
 
 # 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` a ajouté le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` a ajouté sensibilité, valeurs réelle/sûre, redaction et provenance enrichie; `pre.012` a livré l'adapter Config -> Logging, la validation effective de `logs_directory`/`files[].path` et le contrat de non-usage des secrets par Logging. `pre.013` livre management + persistence JSON/.env avec source typée Logging, reports desired/effective/shadow, reveal explicite et écriture atomique. Après validation utilisateur, `pre.014` ouvrira ownership audits + robustesse.
+`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` a ajouté sensibilité, valeurs réelle/sûre, redaction et provenance enrichie; `pre.012` a livré l'adapter Config -> Logging, la validation effective de `logs_directory`/`files[].path` et le contrat de non-usage des secrets par Logging. `pre.013` a livré management + persistence JSON/.env avec source typée Logging, reports desired/effective/shadow, reveal explicite et écriture atomique. `pre.014` ajoute les audits exécutables d'ownership Config, verrouille la direction Core/Logging ->/ Config, interdit les lectures directes KSP/KSPB et les noms physiques gérés hors Config, puis vérifie automatiquement la couverture de `.env.example`. Après validation, `pre.015` ouvrira la clôture.
 
 ## `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: 16 -->
+<!-- version: 17 -->
 
 # 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`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` livre maintenant management + persistence JSON/.env. La prochaine tranche est `pre.014` pour les ownership audits et la robustesse.
+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 `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` a livré management + persistence JSON/.env et son `fix.001` a corrigé la syntaxe du warning de cleanup. `pre.014` livre maintenant les ownership audits exécutables et la robustesse de frontière. La prochaine tranche est `pre.015` pour la clôture.
 
 La base auditée reste la release stable `v0.1.2`.
 
@@ -1864,12 +1864,19 @@ La validation utilisateur de `pre.012` est acquise le 2026-08-16 : `fmt/check/cl
 
 ### `0.1.3-pre.014` — ownership audits + robustesse
 
-- audits interdisant les accès Config/env directs ailleurs ;
-- invalid documents/env/placeholders/file mappings ;
-- graphe dépendances/features ;
-- corrections de surface publique ;
-- robustesse des diagnostics sans fuite ;
-- vérification de la granularité réelle des responsabilités publiques.
+Livré :
+
+- nouveau test d'intégration `tests/ownership.rs` exécuté par `cargo test --workspace` ;
+- audit de direction garantissant que `ksp-core-lib` et `ksp-logging-lib` ne dépendent pas de `ksp-config-lib` ;
+- audit des crates hors Config interdisant les lectures directes littérales `KSP_*`/`KSPB_*` via `std::env::var`/`var_os` ainsi que l'énumération directe `vars`/`vars_os` ;
+- audit interdisant hors Config les noms physiques gérés `.env`, `std.logging.json`, `std.logging.schema.json` et `composite.schema.json`, afin que les consumers utilisent les contrats/constantes/file_id Config ;
+- audit automatique de toutes les variables KSP/KSPB concrètes présentes dans les JSON de `config/` et le code Rust production ;
+- comparaison de cet inventaire avec `.env.example`, en exigeant une assignment versionnée (active ou commentée) et un commentaire explicatif précédent ;
+- réaudit manuel de la matrice existante : documents/schema invalides, `.env` invalide/dupliqué, placeholders invalides/manquants, file mappings invalides, profils/composites invalides, chemins Logging effectifs, secrets/redaction et persistence atomique sont déjà couverts par les 80 tests unitaires acquis en `pre.013-fix.001` ;
+- aucune correction supplémentaire de surface publique n'est nécessaire dans cette tranche ; la granularité `ConfigEnvironment` / `ConfigDocumentEngine` / `ConfigManagement` / adapter Logging reste cohérente ;
+- aucune nouvelle dépendance ni variable d'environnement.
+
+La validation utilisateur de `pre.013-fix.001` est acquise le 2026-08-16 : `fmt/check/clippy/test` passent, `ksp-config-lib` compte 80 tests unitaires + 11 tests publics, `ksp-logging-lib` 34 tests unitaires + toutes ses intégrations, `ksp-logging-lib -d` est vide et le seul doublon Config reste `syn 2`/`syn 3` transitif via `jsonschema`.
 
 ### `0.1.3-pre.015` — clôture
 

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 18 -->
+<!-- version: 19 -->
 
 # Règles spécifiques à KSP
 
@@ -45,6 +45,8 @@
 - **KSP-CONFIG-014** — La persistence Config n'expose pas de primitive publique d'écriture vers un chemin arbitraire. Un document connu est muté via son contrat source typé, validé complètement puis remplacé atomiquement dans le path résolu par son `file_id`; un échec avant commit conserve l'ancien fichier.
 - **KSP-CONFIG-015** — L'environnement du processus reste read-only. La surface management peut créer/modifier/supprimer uniquement des entrées KSP/KSPB du `.env`; chaque mutation rapporte séparément changement de source persistée, changement effectif courant, shadowing par le process et besoin de reload.
 - **KSP-CONFIG-016** — Les rapports management ordinaires n'exposent que des valeurs sûres/redacted. L'accès en clair à une valeur d'environnement passe par un appel `reveal_*` explicite; l'authentification/autorisation de l'utilisateur final appartient à l'application et cette révélation n'autorise jamais le secret dans les logs/`Debug`/diagnostics génériques.
+- **KSP-CONFIG-017** — Les frontières d'ownership Config sont vérifiées par des audits exécutables du workspace : Core/Logging ne dépendent pas de Config, les crates hors `ksp-config-lib` ne lisent pas directement les variables KSP/KSPB via `std::env::var*`/énumération de l'environnement et ne codent pas en dur les noms physiques des fichiers gérés lorsqu'un contrat Config existe.
+- **KSP-CONFIG-018** — L'inventaire `.env.example` est vérifié automatiquement contre les variables KSP/KSPB concrètes utilisées par les JSON sous `config/` et le code Rust production. Toute clé runtime détectée doit posséder une entrée d'inventaire précédée d'un commentaire explicatif.
 
 ## Programmes et exécution