Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.3-pre.012

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-16 05:01:33 +02:00
parent 6a13cea614
commit a9405ec7ff
13 changed files with 1139 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/plans/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 18 -->
<!-- version: 19 -->
# Plans KSP
@@ -13,7 +13,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles ;
- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à `0.1.1-rel.001`.
- [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan actif de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, complété par `pre.001-fix.002` pour le registre `file_id`/bootstrap/non-régression Logging, regranularisé par `pre.001-fix.003`, puis rescindé pendant `pre.005`; `pre.006` a fermé le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema et le premier `std.logging.json`, `pre.008` la résolution globals/profils/`default_profile`, puis `pre.009` les compositions génériques par `file_id`; `pre.010` a livré `.env`, process env, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeur réelle/sûre, redaction et provenance; `pre.012` poursuivra avec l'adapter Config -> Logging.
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan actif de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, corrigé par `pre.001-fix.001`, complété par `pre.001-fix.002` pour le registre `file_id`/bootstrap/non-régression Logging, regranularisé par `pre.001-fix.003`, puis rescindé pendant `pre.005`; `pre.006` a fermé le routing structuré `domain`, `pre.007` le moteur JSON/JSON Schema et le premier `std.logging.json`, `pre.008` la résolution globals/profils/`default_profile`, puis `pre.009` les compositions génériques par `file_id`; `pre.010` a livré `.env`, process env, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeur réelle/sûre, redaction et provenance; `pre.012` livre l'adapter Config -> Logging et la validation effective des chemins Logging; `pre.013` poursuivra avec management/persistence.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

4
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 16 -->
<!-- version: 17 -->
# Séquence des releases fonctionnelles KSP
@@ -219,7 +219,7 @@ pre.015 clôture
Cette prévision n'est pas un plafond : chaque prerelease doit rester une petite tranche, avec scission explicite si l'objectif dépasse environ 15–20 minutes de travail effectif.
`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` a ajouté les compositions génériques par `file_id`, avec `schema.composite` mais sans composite runtime fictif; `pre.010` a ajouté le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` ajoute sensibilité, valeurs réelle/sûre, redaction et provenance enrichie. Après validation utilisateur, `pre.012` construira l'adapter Config -> Logging.
`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` a livré le moteur JSON/JSON Schema et `std.logging.json`; `pre.008` a ajouté la résolution générique globals/profils/`default_profile`; `pre.009` a ajouté les compositions génériques par `file_id`, avec `schema.composite` mais sans composite runtime fictif; `pre.010` a ajouté le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` a ajouté sensibilité, valeurs réelle/sûre, redaction et provenance enrichie; `pre.012` livre l'adapter Config -> Logging, la validation effective de `logs_directory`/`files[].path` et le contrat de non-usage des secrets par Logging. Après validation utilisateur, `pre.013` ouvrira management + persistence JSON/.env.
## `0.1.4` — Config desktop par défaut

28
docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
View File

@@ -1,11 +1,11 @@
<!-- file: docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md -->
<!-- version: 14 -->
<!-- version: 15 -->
# 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, `pre.008` la résolution des globals/profils/`default_profile`, `pre.009` les compositions génériques par `file_id`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, puis `pre.011` la sensibilité et les représentations real/safe/provenance. La prochaine tranche est `pre.012` pour l'adapter Config -> Logging.
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`, `pre.009` les compositions génériques par `file_id`, `pre.010` le snapshot process + `.env` et le resolver `${...}`, puis `pre.011` la sensibilité et les représentations real/safe/provenance. `pre.012` livre maintenant l'adapter Config -> Logging, avec validation effective des paths et frontière anti-secret. La prochaine tranche est `pre.013` pour management + persistence JSON/.env.
La base auditée reste la release stable `v0.1.2`.
@@ -1824,13 +1824,23 @@ Tranche livrée :
### `0.1.3-pre.012` — adapter Config -> Logging
- `ResolvedLoggingConfig` ;
- conversion explicite vers les contrats publics `ksp_logging_lib::*` ;
- aucune dépendance inverse ;
- démonstration `initialize/reinitialize` ;
- `LoggingGuard` orchestration-owned ;
- tests de mapping multi-output/filter/domain ;
- vérification qu'aucune valeur secrète n'est utilisée dans les diagnostics Logging.
Tranche livrée :
- `ResolvedLoggingConfig` conserve `file_id`, source path, profil sélectionné, source de sélection, arbre effectif détaillé real/safe/provenance, root Logging résolu et `ksp_logging_lib::LoggingSettings` ;
- `ConfigDocumentEngine::load_resolved_logging_config(requested_profile, environment)` charge `cfg.std.logging`, sélectionne le profil, applique process > `.env` > fallback puis convertit explicitement tous les contrats Logging ;
- mapping complet de `LogFilterLevel`, `SpanEvents`, `ConsoleOutput`, `LogFormat`, `FileRotation`, `OutputFilter`, `TargetFilter`, console et multi-fichiers ;
- `files[].path` est séparé en directory relatif + file-name prefix pour `FileSettings`, sous un `logs_directory` commun ;
- `logs_directory` absolu est conservé ; relatif, il est ancré sur `std::env::current_dir()` au moment de l'adaptation ; un root inexistant est accepté pour permettre à Logging de le créer ; un path existant non-directory ou impossible à inspecter est rejeté ;
- une valeur explicite `KSP_LOGS_DIRECTORY=` vide est une valeur présente et produit `config.effective_config_invalid` : aucun fallback silencieux vers `logs` ;
- les `files[].path` sont revalidés après interpolation et doivent rester relatifs sans `.`/`..`/root/prefix, empêchant une variable d'environnement de faire sortir un sink du root Logging ;
- l'adapter rejette toute configuration Logging effective dont la sensibilité agrégée est `Secret`; Logging n'a aucun besoin fonctionnel de secrets et ses diagnostics filesystem ne doivent jamais recevoir de valeur secrète ;
- les erreurs de validation finales de `LoggingSettings` sont encapsulées par Config avec uniquement le code Logging stable, sans recopier les contextes runtime susceptibles de contenir des valeurs effectives ;
- `ResolvedLoggingConfig` possède un `Debug` manuel qui expose l'arbre effectif via sa représentation sûre et n'affiche ni les settings réels ni le root réel séparément ;
- un test démontre que les settings issus de Config peuvent réellement `initialize` puis `reinitialize` `ksp-logging-lib`; le `LoggingGuard` reste détenu par l'orchestration/test, jamais stocké comme singleton Config ;
- l'initialisation Logging crée les sous-répertoires de sinks configurés lorsqu'ils n'existent pas ;
- aucune nouvelle variable d'environnement, aucune modification de `.env.example`, aucune nouvelle dépendance Cargo.
La validation utilisateur de `pre.011-fix.001` est acquise le 2026-08-16 : `fmt/check/clippy/test` passent, `ksp-config-lib` compte 61 tests unitaires + 9 tests publics, et le graphe conserve uniquement le doublon transitif `syn 2`/`syn 3` déjà connu via `jsonschema`; `ksp-logging-lib -d` reste sans doublon.
### `0.1.3-pre.013` — management + persistence JSON/.env