# 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==` ; - 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. ``` 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`.