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

v0.1.3-pre.015

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-16 07:52:59 +02:00
parent 92982667ac
commit 64136c99ad
14 changed files with 876 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 11 -->
<!-- version: 12 -->
# Documentation KSP
@@ -36,7 +36,8 @@ docs/
│ ├── 001-V0_0_3_PLAN.md
│ ├── 002-FUNCTIONAL_RELEASE_SEQUENCE.md
│ ├── 003-V0_1_1_CORE_FOUNDATION_PLAN.md
│ └── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
│ ├── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
│ └── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
└── rules/
├── FILE_CONTRACTS.md
├── PROMPT_STRUCTURE.md
@@ -53,7 +54,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
## Documents de planification
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md).
Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de `0.1.3 — Configuration foundation` est conservé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) et entre en clôture avec `pre.015`, avant publication stable `rel.001`.
`IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.

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

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 21 -->
<!-- version: 22 -->
# 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` a livré l'adapter Config -> Logging et la validation effective des chemins Logging; `pre.013` a livré management/persistence JSON/.env; `pre.014` ajoute les ownership audits exécutables et la vérification automatique de `.env.example`; `pre.015` assurera la clôture.
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan de `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001` puis exécuté jusqu'à `pre.014`; `pre.015` consolide la documentation, ferme les TODO de release, prépare le prompt `0.1.4` et place la version en attente de validation finale avant `rel.001`.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

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

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 19 -->
<!-- version: 20 -->
# Séquence des releases fonctionnelles KSP
@@ -219,7 +219,35 @@ 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` a ajouté sensibilité, valeurs réelle/sûre, redaction et provenance enrichie; `pre.012` a livré l'adapter Config -> Logging, la validation effective de `logs_directory`/`files[].path` et le contrat de non-usage des secrets par Logging. `pre.013` a livré management + persistence JSON/.env avec source typée Logging, reports desired/effective/shadow, reveal explicite et écriture atomique. `pre.014` ajoute les audits exécutables d'ownership Config, verrouille la direction Core/Logging ->/ Config, interdit les lectures directes KSP/KSPB et les noms physiques gérés hors Config, puis vérifie automatiquement la couverture de `.env.example`. Après validation, `pre.015` ouvrira la clôture.
`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` les compositions génériques par `file_id`; `pre.010` le snapshot process + `.env`, `.env.example` et le resolver `${...}`; `pre.011` la sensibilité, les valeurs réelle/sûre, la redaction et la provenance enrichie; `pre.012` l'adapter Config -> Logging et la validation effective des chemins; `pre.013` management + persistence JSON/.env; `pre.014` les audits exécutables d'ownership et la couverture automatique de `.env.example`. `pre.015` constitue la prerelease finale : documentation durable de la crate, synthèse changelog, prompt `0.1.4`, clôture des TODO et préparation de `rel.001`.
Trajectoire réellement suivie :
```text
pre.001 brainstorming + audit + plan détaillé
pre.001-fix.001..003 corrections de cadrage, file_id/bootstrap et granularité
pre.002 crate Config + bootstrap cfgpath/schemapath
pre.002-fix.001 correction de la première tranche Config
pre.003 registre file_id + --filemap
pre.004 Logging contracts/settings multi-output
pre.005 Logging runtime multi-sink + routing level/target/formats
pre.005-fix.001 correction du test JSON runtime
pre.006 Logging routing structuré domain
pre.007 moteur JSON/JSON Schema + std.logging.json
pre.008 globals + profils + default_profile
pre.009 compositions génériques par file_id
pre.009-fix.001 correction Clippy du test composite
pre.010 process env + .env + placeholders + .env.example
pre.010-fix.001 correction des racines de fixtures de test
pre.011 sensibilité + real/safe/provenance
pre.011-fix.001 correction Clippy du test de provenance
pre.012 adapter Config -> Logging
pre.013 management + persistence JSON/.env
pre.013-fix.001 correction de syntaxe du warning persistence
pre.014 ownership audits + robustesse
pre.015 clôture/docs/prompt 0.1.4
rel.001 publication stable après validation
```
## `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: 17 -->
<!-- version: 18 -->
# 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 `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` a livré management + persistence JSON/.env et son `fix.001` a corrigé la syntaxe du warning de cleanup. `pre.014` livre maintenant les ownership audits exécutables et la robustesse de frontière. La prochaine tranche est `pre.015` pour la clôture.
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 `${...}`, `pre.011` la sensibilité et les représentations real/safe/provenance, puis `pre.012` l'adapter Config -> Logging. `pre.013` a livré management + persistence JSON/.env et son `fix.001` a corrigé la syntaxe du warning de cleanup. `pre.014` a livré les ownership audits exécutables et la robustesse de frontière puis a été validée intégralement par l'utilisateur. `pre.015` est la prerelease finale : elle consolide la documentation durable, ferme/reporte explicitement les TODO, introduit le changelog général stable, prépare le prompt `0.1.4` et place `0.1.3` en attente de `rel.001`.
La base auditée reste la release stable `v0.1.2`.
@@ -1880,12 +1880,20 @@ La validation utilisateur de `pre.013-fix.001` est acquise le 2026-08-16 : `fmt/
### `0.1.3-pre.015` — clôture
- validations finales ;
- documentation durable ;
- cleanup/archivage requis ;
- TODO fermés ou reportés ;
- prompt `0.1.4 — ksp-app-config-desk` ;
- préparation `rel.001` puis tag stable après validation utilisateur.
Tranche livrée :
- validation utilisateur de `pre.014` enregistrée : `fmt/check/clippy/test` propres, 80 tests unitaires Config, 4 audits ownership, 11 tests publics et aucun doublon dans le graphe Logging ;
- `workspace.package.version = "0.1.3-pre.15"` comme signal technique de la prerelease finale ;
- documentation durable `ksp-config-lib/README.md`, `USAGE.md` et `TODO.md` ;
- `CHANGELOG.md` général introduit selon les règles existantes avec uniquement les releases déjà stables `0.1.2`, `0.1.1` et `0.0.3`; `0.1.3` n'y sera ajouté qu'au `rel.001` ;
- index README/docs/plans/prompts réalignés ;
- prompt final `prompts/004-V0_1_4_START_PROMPT.md` préparé pour ouvrir `ksp-app-config-desk` uniquement après publication stable `v0.1.3` ;
- aucun TODO fonctionnel bloquant `0.1.3` trouvé dans la crate ; les validations Tauri/desktop sont reportées explicitement à `0.1.4`, les futurs documents/composites/watchers restant conditionnés à un besoin concret ;
- aucun cleanup ou archivage destructif nécessaire : les deltas historiques, schemas, exemples et prompts historiques restent intentionnellement conservés ;
- aucune nouvelle API, dépendance, variable runtime ou ressource Config exécutable ;
- `ROADMAP.md` reste en `[/]` pour `0.1.3` jusqu'à validation de cette prerelease et publication `rel.001`.
Après validation de `pre.015`, la seule étape de `0.1.3` est la livraison `rel.001` : passage Cargo à `0.1.3`, synchronisation du changelog/roadmap/plans, puis tag `v0.1.3` sur le commit stable validé.
Le découpage reste souple. Tout dépassement du budget de tranche est corrigé par une nouvelle scission explicite ; le nombre de prereleases n'est pas une cible à minimiser.
@@ -1915,11 +1923,15 @@ Au minimum :
```bash
cargo fmt --all
cargo check --workspace
cargo build -p ksp-config-lib
cargo clippy --workspace --all-targets
cargo test --workspace
cargo test -p ksp-config-lib --test ownership
cargo tree -p ksp-config-lib
cargo tree -p ksp-config-lib -d
cargo tree -p ksp-config-lib -e features
cargo tree -p ksp-config-lib -e normal
cargo tree -p ksp-logging-lib -d
```
Exécuter aussi tout script d'audit réellement présent au moment de la clôture.