v0.1.3-pre.001-fix.002

deltas/0.1.3/pre.001-fix.002.md

@@ -0,0 +1,213 @@
+<!-- file: deltas/0.1.3/pre.001-fix.002.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-pre.001-fix.002
+
+## Base requise
+
+Livraison précédente appliquée et commitée :
+
+```text
+0.1.3-pre.001-fix.001
+```
+
+Ce correctif reste documentaire et doit être validé avant toute ouverture de `pre.002`.
+
+## Type de livraison
+
+```text
+ksp-doc-0.1.3-pre.001-fix.002.zip
+```
+
+## Objectif
+
+Compléter le plan Config avec les décisions de bootstrap/fichiers et corriger le modèle Logging trop pauvre du fix précédent.
+
+Le correctif fixe notamment :
+
+- un registre KSP des fichiers connus avec `file_id` unique et mapping `file_id -> filename` ;
+- des mappings distincts pour documents Config et schemas, tous identifiés dans un namespace logique unique ;
+- des filenames par défaut codés dans `ksp-config-lib` mais surchargeables au démarrage ;
+- deux chemins bootstrap non récursifs avec défauts codés en dur : `config` et `config/schemas` ;
+- surcharge de ces chemins uniquement par `--cfgpath` / `--schemapath` ou options programmatiques explicites ;
+- surcharge répétable d'un filename connu par `--filemap=<file_id>=<filename>` ;
+- références des composites par `file_id` et jamais par filename ;
+- sélection/remplacement indépendant du filename d'un schema ;
+- choix de `serde`, `serde_json` et `jsonschema` comme base candidate du moteur JSON/schema ;
+- modèle `std.logging.json` enrichi avec profils identifiés, console configurable et plusieurs sinks fichier ;
+- routing Logging attendu par niveau, target et domain, avec rotation/format/ANSI selon le sink ;
+- constat explicite que `ksp-logging-lib 0.1.2` ne couvre pas encore toute cette surface ;
+- décision de compléter cette surface dans `ksp-logging-lib` sans déplacer le routing dans Config et sans créer de dépendance Logging -> Config.
+
+## Version Cargo
+
+Ce correctif modifie uniquement la documentation de planification.
+
+Conformément à `VER-ID-008`, `workspace.package.version` reste :
+
+```text
+0.1.3-pre.1
+```
+
+Identifiant de livraison/commit :
+
+```text
+0.1.3-pre.001-fix.002
+```
+
+## Fichiers ajoutés
+
+- `deltas/0.1.3/pre.001-fix.002.md`
+
+## Fichiers modifiés
+
+- `docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md` — version documentaire 2 -> 3 ;
+- `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` — version documentaire 7 -> 8 ;
+- `docs/plans/000-README.md` — version documentaire 9 -> 10.
+
+## Registre logique des fichiers
+
+Le plan retient un namespace unique de `file_id` :
+
+```text
+cfg.std.logging
+schema.std.logging
+schema.composite
+cfg.composite.<consumer>
+```
+
+Premier mapping :
+
+```text
+cfg.std.logging    -> std.logging.json
+schema.std.logging -> std.logging.schema.json
+schema.composite   -> composite.schema.json
+```
+
+Un override ne change jamais le `file_id`, uniquement son filename physique.
+
+Exemples :
+
+```text
+--filemap=cfg.std.logging=my.logging.json
+--filemap=schema.std.logging=my.logging.schema.json
+```
+
+Un composite référence donc :
+
+```text
+cfg.std.logging
+```
+
+et continue de fonctionner sans modification si le filename est remplacé au bootstrap.
+
+## Bootstrap hors documents Config
+
+Les seules racines nécessaires avant le chargement de Config sont :
+
+```text
+cfgpath    = config
+schemapath = config/schemas
+```
+
+Elles ne sont résolues ni depuis JSON, ni depuis `.env`, ni depuis `KSP_*`/`KSPB_*`.
+
+Seules les interfaces bootstrap suivantes peuvent les remplacer :
+
+```text
+--cfgpath=/path/to/configs
+--schemapath=/path/to/schemas
+```
+
+ou leur équivalent programmatique explicite possédé par `ksp-config-lib`.
+
+## Audit Logging
+
+L'audit du code stable `v0.1.2` confirme actuellement :
+
+```text
+1 console optionnelle
+1 fichier optionnel
+rotation never/hourly/daily
+filtre global
+TargetFilter par préfixe de target
+initialize/reinitialize + LoggingGuard
+```
+
+Il ne fournit pas encore :
+
+```text
+plusieurs fichiers simultanés
+console_ansi configurable
+format configurable par sink
+routing indépendant par sink/target/domain/level
+```
+
+La configuration historique bot3 possédait déjà plusieurs sorties console/fichier, niveaux, targets, rotation, format et ANSI.
+
+`0.1.3` ne doit pas figer une configuration Logging régressive. Les capacités manquantes sont donc prévues comme une complétion bornée du domaine `ksp-logging-lib` avant gel du schema Logging. La propriété du subscriber, des layers, writers, settings, guard et du lifecycle reste intégralement dans Logging.
+
+## Dépendances candidates vérifiées
+
+Vérification documentaire effectuée le 15 août 2026 :
+
+```text
+serde       1.0.229 -> ^1.0
+serde_json  1.0.151 -> ^1.0
+jsonschema  0.49.6  -> ^0.49
+```
+
+Aucune de ces dépendances n'est ajoutée par ce correctif. Elles devront être revérifiées au delta qui les introduit réellement puis déclarées sous `[workspace.dependencies]`.
+
+## Découpage révisé
+
+La prévision devient :
+
+```text
+pre.002 bootstrap Config + registre file_id
+pre.003 complétion bornée du contrat Logging
+pre.004 serde/serde_json/jsonschema + std.logging.json
+pre.005 profils + composition par file_id
+pre.006 .env + resolver ${...}
+pre.007 secrets real/safe + adapter Logging
+pre.008 management + persistence JSON/.env
+pre.009 audits ownership + robustesse
+pre.010 clôture
+```
+
+Le découpage reste souple ; aucune tranche fonctionnelle n'est ouverte avant validation du plan corrigé.
+
+## Validations exécutées
+
+Sur le delta documentaire :
+
+- comparaison statique avec `pre.001-fix.001` ;
+- contrôle des headers `file:` / `version:` des quatre fichiers livrés ;
+- contrôle de la présence du nouveau delta ;
+- contrôle que l'archive ne contient que les trois documents modifiés et le delta ajouté ;
+- contrôle que `Cargo.toml` n'est pas livré par ce fix ;
+- contrôle des références `file_id`, `cfgpath`, `schemapath`, `--filemap` et du découpage `pre.002` -> `pre.010` dans le plan ;
+- contrôle de l'absence de secret réel dans le delta.
+
+## Validations non exécutées
+
+Aucune commande Cargo n'est déclarée réussie pour ce correctif documentaire :
+
+- le delta ne modifie ni code Rust, ni manifest, ni configuration runtime ;
+- `cargo` n'est pas disponible dans le sandbox de préparation utilisé pour cette livraison.
+
+Les validations Cargo restent obligatoires dès les tranches fonctionnelles applicables.
+
+## Décisions prises
+
+- `file_id` est l'identité logique stable d'un fichier Config/schema ;
+- le filename est une localisation physique remplaçable ;
+- les composites dépendent de `file_id`, pas d'un nom de fichier ;
+- `cfgpath`/`schemapath` sont des paramètres bootstrap hors graphe Config ;
+- `serde_json` + `jsonschema` seront utilisés pour éviter une validation JSON maison ;
+- le modèle Logging doit rester au moins aussi expressif que les besoins utiles déjà présents dans bot3 ;
+- Config ne compense jamais un manque du backend Logging par un routing parallèle.
+
+## Questions ouvertes avant `pre.002`
+
+Aucune question bloquante n'est conservée par défaut. Le plan corrigé doit néanmoins être validé par le user avant ouverture de `pre.002`.