214 lines
6.9 KiB
Markdown
214 lines
6.9 KiB
Markdown
<!-- 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`.
|