khadhroony-solana-project/deltas/0.1.3/pre.001-fix.002.md

Delta 0.1.3-pre.001-fix.002

Base requise

Livraison précédente appliquée et commitée :

0.1.3-pre.001-fix.001

Ce correctif reste documentaire et doit être validé avant toute ouverture de pre.002.

Type de livraison

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 :

0.1.3-pre.1

Identifiant de livraison/commit :

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 :

cfg.std.logging
schema.std.logging
schema.composite
cfg.composite.<consumer>

Premier mapping :

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 :

--filemap=cfg.std.logging=my.logging.json
--filemap=schema.std.logging=my.logging.schema.json

Un composite référence donc :

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 :

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 :

--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 :

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 :

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 :

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 :

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.