v0.1.3-pre.009

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: 11 -->
+<!-- version: 12 -->
 
 # 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 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`.
+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` et `pre.009` les compositions génériques par `file_id`. La prochaine tranche est `pre.010` pour `.env`, process env et le resolver `${...}`.
 
 La base auditée reste la release stable `v0.1.2`.
 
@@ -409,7 +409,30 @@ config/composite.ksp-app-wallet-desk.json
 
 Leur identité logique reste `cfg.composite.<consumer>`; le filename peut être remplacé par `--filemap` sans modifier leur contenu logique.
 
-Aucun composite runtime fictif n'est créé avant l'existence d'un consumer concret. Le moteur et le schéma génériques peuvent néanmoins être testés dans `0.1.3` par fixtures/examples.
+Aucun composite runtime fictif n'est créé avant l'existence d'un consumer concret. Le moteur et le schéma génériques sont exercés par `config/examples/composite.example.json` et par un descriptor de test privé à `ksp-config-lib`.
+
+Contrat générique livré en `pre.009` :
+
+```json
+{
+  "format_version": 1,
+  "default_profile": "local",
+  "profiles": [
+    {
+      "profile_id": "local",
+      "documents": [
+        {
+          "component_id": "logging",
+          "file_id": "cfg.std.logging",
+          "profile_id": "local_dev"
+        }
+      ]
+    }
+  ]
+}
+```
+
+`component_id` est local au profil composite et unique dans celui-ci. `file_id` référence exclusivement un document standard `cfg.std.*` connu du registre. `profile_id` est optionnel : absent, il conserve le `default_profile` autonome du document référencé ; présent, il sélectionne explicitement ce profil au nom du composite. Les composites ne référencent jamais les filenames physiques et ne s'imbriquent pas dans cette première surface.
 
 ### 6.6 Schémas
 
@@ -419,7 +442,7 @@ Les schémas appartiennent par défaut sous :
 config/schemas/
 ```
 
-Première surface candidate :
+Surface actuelle :
 
 ```text
 config/schemas/std.logging.schema.json
@@ -1740,12 +1763,21 @@ La validation utilisateur de `pre.007` est acquise : `fmt/check/clippy/test` pas
 
 ### `0.1.3-pre.009` — compositions génériques par `file_id`
 
-- contrat composite générique ;
-- schema/example composite ;
-- références de documents exclusivement par `file_id` ;
-- sélection/remplacement de profils documentaires ;
-- résolution composition -> document -> profil/global ;
-- aucun composite runtime fictif obligatoire.
+Tranche livrée :
+
+- `schema.composite` est enregistré par défaut vers `config/schemas/composite.schema.json` et reste surchargeable par `--filemap` ;
+- aucun `cfg.composite.<consumer>` n’est enregistré tant qu’un consumer concret n’existe pas ;
+- `config/examples/composite.example.json` exerce le contrat sans devenir une source runtime implicite ;
+- un composite utilise `format_version`, `default_profile` et `profiles[]` comme les documents standards profilés ;
+- chaque profil composite contient `documents[]` avec `component_id`, `file_id` et `profile_id` optionnel ;
+- `component_id` est unique dans un profil composite ;
+- les références ciblent exclusivement des `cfg.std.*` déjà enregistrés, jamais des filenames ni d’autres composites ;
+- `profile_id` absent laisse le document référencé choisir son `default_profile` autonome ;
+- `profile_id` présent impose ce profil et marque sa source de sélection `ConfigProfileSelectionSource::Composite` ;
+- `ResolvedConfigComposite` conserve le composite sélectionné et ses `ResolvedCompositeComponent`, chacun portant le `ResolvedConfigProfile` complet du document référencé ;
+- les provenances `Global` / `Profile` du document spécialisé sont donc conservées sous la composition ;
+- `ConfigDocumentEngine::load_resolved_composite(file_id, requested_profile)` est prêt pour les futurs descriptors `cfg.composite.<consumer>` ;
+- les tests utilisent un descriptor composite privé à la crate pointant vers l’exemple versionné afin de valider la résolution complète sans créer un composite runtime fictif.
 
 ### `0.1.3-pre.010` — `.env` + process env + resolver `${...}`