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

v0.1.3-pre.007

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-15 20:57:13 +02:00
parent b7323fe961
commit 96753e4ba1
17 changed files with 1647 additions and 44 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: 13 -->
<!-- version: 14 -->
# 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` ferme maintenant le routing structuré `domain` avant le premier schema Logging de `pre.007`.
- [`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` et `pre.007` livre maintenant le moteur JSON/JSON Schema et le premier `std.logging.json`; `pre.008` poursuit avec globals/profils/`default_profile`.
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: 11 -->
<!-- version: 12 -->
# 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.
Après validation de `pre.005-fix.001`, `pre.006` ferme le routing Logging structuré `domain`; `pre.007` redevient donc la prochaine tranche Config avec JSON/JSON Schema et le premier document `std.logging.json`.
`pre.006` a fermé le routing Logging structuré `domain`; `pre.007` livre le moteur JSON/JSON Schema et le premier document `std.logging.json`. Après validation utilisateur de `pre.007`, la prochaine tranche est `pre.008` pour globals, profils et `default_profile`.
## `0.1.4` — Config desktop par défaut

33
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: 9 -->
<!-- version: 10 -->
# 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 et `pre.006` ferme le routing structuré `domain`. Le premier schema Logging peut donc commencer en `pre.007` après validation utilisateur de cette tranche.
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` et `pre.007` introduit le moteur JSON/JSON Schema ainsi que le premier document runtime `std.logging.json`. La prochaine tranche est `pre.008` pour la résolution des globals/profils/`default_profile`.
La base auditée reste la release stable `v0.1.2`.
@@ -280,10 +280,9 @@ Premier mapping codé dans `ksp-config-lib` :
```text
cfg.std.logging -> std.logging.json
schema.std.logging -> std.logging.schema.json
schema.composite -> composite.schema.json
```
Le descriptor `cfg.std.logging` référence logiquement `schema.std.logging`; il ne contient pas le nom physique du schema.
Le descriptor `cfg.std.logging` référence logiquement `schema.std.logging`; il ne contient pas le nom physique du schema. Le futur `schema.composite` n'est ajouté au registre qu'avec la tranche composite qui en a réellement besoin.
Un futur consumer pourra introduire par le registre KSP :
@@ -1701,19 +1700,25 @@ Implémentation candidate livrée par `pre.006` :
Aucune dépendance externe ou feature Cargo supplémentaire n'est nécessaire pour cette tranche. `pre.007` peut donc construire `std.logging.schema.json` sur une surface Logging qui représente et exécute réellement les trois dimensions de routing retenues : level, target et domain.
La validation utilisateur de `pre.006` reste requise avant l'ouverture de `pre.007`.
La validation utilisateur de `pre.006` est acquise : `fmt/check/clippy/test` et les trois graphes Cargo demandés sont propres.
### `0.1.3-pre.007` — JSON/JSON Schema + premier document Logging
- `serde`/`serde_json`/`jsonschema` au workspace avec versions revérifiées ;
- infrastructure générique de lecture JSON ;
- association descriptor -> schema par `file_id` ;
- validation JSON Schema ;
- `config/`, `config/schemas/`, `config/examples/` ;
- `std.logging.schema.json` aligné sur les contrats Logging réellement stabilisés en `pre.004/.005/.006` ;
- runtime `config/std.logging.json` ;
- exemple Logging ;
- parse/schema/validation sémantique de base.
Tranche livrée :
- `serde ^1.0`, `serde_json ^1.0` et `jsonschema ^0.49` sont déclarés au workspace puis consommés avec `.workspace = true` par `ksp-config-lib` ; les versions observées au moment de l'ajout sont respectivement `1.0.229`, `1.0.151` et `0.49.9` ;
- `jsonschema` est consommé avec `default-features = false` : `0.1.3` n'a besoin d'aucune récupération HTTP/file de références externes pour le schema Logging autonome ;
- `ConfigFileDescriptor` possède désormais l'association logique optionnelle `schema_file_id`; `cfg.std.logging` référence `schema.std.logging` ;
- le registre vérifie qu'un schema référencé existe réellement et possède `ConfigFileKind::Schema` ;
- `ConfigDocumentEngine` centralise la lecture des JSON enregistrés, la validation du document schema contre son meta-schema, la validation de l'instance puis les invariants sémantiques propres au document ;
- les diagnostics distinguent lecture impossible, syntaxe JSON invalide, schema invalide, échec de validation schema et invalidité sémantique ;
- `config/std.logging.json`, `config/schemas/std.logging.schema.json` et `config/examples/std.logging.example.json` constituent la première surface Config réelle ;
- le schema est JSON Schema Draft 2020-12 et reflète la surface Logging stabilisée : filtre global, lifecycle spans, console, multi-fichiers, `output_id`, rotation, formats, ANSI et routing `level/target/domain` ;
- le document source contient déjà `logs_directory`, `default_profile` et `profiles[]`, mais `pre.007` ne résout encore aucun profil et ne vérifie pas encore l'unicité des `profile_id` ni que `default_profile` référence un profil existant ; ces responsabilités restent explicitement à `pre.008` ;
- la validation sémantique de base couvre notamment les `output_id` fichier, chemins relatifs sous `logs_directory`, ANSI fichier interdit, incompatibilité ANSI+JSON console, selectors wildcard/target KSP et unicité des `output_id` dans un profil ;
- aucune interpolation `${...}` n'est encore exécutée : `${KSP_LOGS_DIRECTORY:-logs}` reste une string source schema-valide jusqu'au resolver de `pre.010`.
Aucune dépendance à `ksp-logging-lib` n'est encore nécessaire dans Config : le mapping vers `LoggingSettings` reste réservé à `pre.012`.
### `0.1.3-pre.008` — globals + profils + `default_profile`