v0.1.3-pre.008

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # 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` et `pre.007` livre maintenant le moteur JSON/JSON Schema et le premier `std.logging.json`; `pre.008` poursuit avec globals/profils/`default_profile`.
+- [`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`, puis `pre.008` la résolution globals/profils/`default_profile`; `pre.009` poursuivra avec les compositions génériques par `file_id`.
 
 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: 12 -->
+<!-- version: 13 -->
 
 # 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` livre le moteur JSON/JSON Schema et le premier document `std.logging.json`. Après validation utilisateur de `pre.007`, la prochaine tranche est `pre.008` pour globals, profils et `default_profile`.
+`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` ajoute la résolution générique globals/profils/`default_profile` avec provenance top-level. Après validation utilisateur, `pre.009` introduira les compositions génériques par `file_id`.
 
 ## `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: 10 -->
+<!-- version: 11 -->
 
 # 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` et `pre.007` introduit le moteur JSON/JSON Schema ainsi que le premier document runtime `std.logging.json`. La prochaine tranche est `pre.008` pour la résolution des globals/profils/`default_profile`.
+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 et `pre.008` la résolution des globals/profils/`default_profile`. La prochaine tranche est `pre.009` pour les compositions génériques par `file_id`.
 
 La base auditée reste la release stable `v0.1.2`.
 
@@ -1722,13 +1722,21 @@ Aucune dépendance à `ksp-logging-lib` n'est encore nécessaire dans Config : l
 
 ### `0.1.3-pre.008` — globals + profils + `default_profile`
 
-- paramètres globaux hors profils ;
-- `profile_id` unique ;
-- `default_profile` autonome ;
-- sélection/résolution d'un profil spécialisé ;
-- héritage/usage des paramètres globaux par les profils selon le contrat retenu ;
-- provenance document/global/profile ;
-- tests sur `std.logging.json`.
+Tranche livrée :
+
+- tout document standard possédant `default_profile` + `profiles` est soumis au contrat générique de profils Config ;
+- les `profile_id` doivent être uniques dans le document ;
+- `default_profile` reste une propriété globale autonome et doit référencer exactement un `profile_id` existant ;
+- `ConfigDocumentEngine::load_resolved_profile(file_id, requested_profile)` sélectionne soit le profil par défaut (`None`), soit un profil explicite (`Some(profile_id)`) ;
+- une sélection explicite inconnue retourne `config.profile_not_found` sans rendre le document source invalide ;
+- `ResolvedConfigProfile` conserve le `file_id`, le path source, le `profile_id` sélectionné, la source de sélection, les globals, le profil et une vue effective ;
+- les globals sont toutes les propriétés top-level hors clés réservées `default_profile` et `profiles` ;
+- la vue effective fusionne les globals puis les propriétés du profil sélectionné ; une clé du profil, si elle existe aussi globalement dans un futur schema, est déterministement prioritaire ;
+- `ConfigValueOrigin::{Global, Profile}` conserve la provenance top-level de chaque clé effective ;
+- aucune interpolation `${...}`, aucun override composite et aucune sensibilité ne sont encore appliqués à cette vue ; ces couches seront ajoutées sans faire perdre la provenance déjà portée ;
+- les tests couvrent le profil par défaut commité, la sélection explicite, la provenance global/profile, un profil demandé absent, les `profile_id` dupliqués et un `default_profile` orphelin.
+
+La validation utilisateur de `pre.007` est acquise : `fmt/check/clippy/test` passent, le moteur Config compte 28 tests unitaires + 5 tests publics et `jsonschema` avec `default-features = false` n'introduit pas de stack HTTP/TLS. Le seul doublon signalé par `cargo tree -d` est `syn 2`/`syn 3`, transitif via l'écosystème `jsonschema` et sans duplication de crate runtime KSP à corriger dans cette tranche.
 
 ### `0.1.3-pre.009` — compositions génériques par `file_id`