From 513f57dd213387950f1aac0f95ea1af6ce4b0e7c Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sun, 16 Aug 2026 08:06:38 +0200 Subject: [PATCH] v0.1.3-rel.001 --- CHANGELOG.md | 6 +- Cargo.toml | 4 +- README.md | 4 +- ROADMAP.md | 6 +- deltas/0.1.3/rel.001.md | 182 ++++++++++++++++++ docs/000-README.md | 4 +- docs/plans/000-README.md | 4 +- docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md | 14 +- .../005-V0_1_3_CONFIG_FOUNDATION_PLAN.md | 12 +- 9 files changed, 214 insertions(+), 22 deletions(-) create mode 100644 deltas/0.1.3/rel.001.md diff --git a/CHANGELOG.md b/CHANGELOG.md index 67a6a86..169ac46 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,10 +1,14 @@ - + # Changelog KSP Ce changelog résume uniquement les releases KSP considérées comme stables, dans l'ordre chronologique décroissant. Les détails de chaque livraison restent dans `deltas/`. +## 0.1.3 — Configuration foundation — 2026-08-16 + +`0.1.3` stabilise `ksp-config-lib` comme propriétaire KSP unique des documents Config, schemas, profils, compositions, variables `KSP_*`/`KSPB_*`, `.env`, placeholders et persistence autorisée. La release introduit le bootstrap non récursif `cfgpath`/`schemapath`, le registre logique `file_id -> filename`, JSON Schema, globals/profils/`default_profile`, compositions par `file_id`, priorité process env > `.env` > fallback, sensibilité `Public`/`Internal`/`Secret`, représentations real/safe avec provenance, management/persistence atomique JSON et `.env`, ainsi que l'adapter vers `ksp_logging_lib::LoggingSettings` et les audits d'ownership. Elle complète également `ksp-logging-lib` avec les contrats/runtime multi-sink, routing structuré `domain` et hot reload nécessaires au premier document `std.logging.json`, puis prépare `0.1.4 — ksp-app-config-desk` comme validation desktop/Tauri extensible de cette fondation. + ## 0.1.2 — Logging foundation — 2026-08-14 `0.1.2` stabilise `ksp-logging-lib` comme façade KSP unique de logging/tracing runtime. La release introduit les événements et spans KSP, le takeover des targets, le subscriber global unique, `LoggingSettings`, les sorties console/fichier non bloquantes, rotation, stripping ANSI, compteurs de lignes abandonnées, hot reload transactionnel et instrumentation async indépendante de l'executor. La stack `tracing`, `tracing-subscriber` et `tracing-appender` reste possédée exclusivement par Logging ; Tokio est limité aux tests réels d'instrumentation async. diff --git a/Cargo.toml b/Cargo.toml index 39323a2..e228879 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,12 +1,12 @@ # file: Cargo.toml -# version: 60 +# version: 61 [workspace] resolver = "3" members = ["crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"] [workspace.package] -version = "0.1.3-pre.15" +version = "0.1.3" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project" diff --git a/README.md b/README.md index 9c3bdb5..f768a6e 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # Khadhroony Solana Project @@ -35,7 +35,7 @@ Les besoins du trading constituent une priorité produit à court terme mais ne - Les jobs utilisent le préfixe `ksp-job-`. - Une application ou un outil de démonstration se termine par `-demo`. - Les crates Rust sont placées directement sous `crates/`, sans sous-répertoires de catégories. -- Les applications sont placées sous `apps/` lorsqu'elles sont introduites. +- Les applications Tauri, workers, jobs et autres packages Rust KSP sont des crates workspace placées directement sous `crates/`; leur nom encode leur rôle (`ksp-app-*`, `ksp-worker-*`, `ksp-job-*`). - Les composants réutilisables restent séparés de leurs applications de manipulation ou de démonstration. - Les applications et demos restent des interfaces/compositions ; les opérations réutilisables appartiennent aux composants KSP de niveau approprié. - Les exécutables KSP ne dépendent pas directement de crates externes relatives à Solana ou à un protocole Solana. diff --git a/ROADMAP.md b/ROADMAP.md index b4bded8..682d6f2 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # Roadmap KSP @@ -33,10 +33,10 @@ Regrouper les releases consacrées aux fondations N1. Chaque release concrète e - [X] `0.1.1` — Stabiliser `ksp-core-lib` : `Error`/`Result`, Program IDs fondamentaux et primitives réellement N1. - [X] `0.1.2` — Introduire `ksp-logging-lib` comme façade KSP de `tracing`, `tracing-appender` et `tracing-subscriber`. -- [/] `0.1.3` — Introduire `ksp-config-lib` : documents, profils, résolution, validation et modifications autorisées. +- [X] `0.1.3` — Stabiliser `ksp-config-lib` : documents, profils, résolution, validation, environnement KSP/KSPB, management/persistence et adapter Logging. - [ ] `0.1.4` — Introduire `ksp-app-config-desk` pour valider réellement Config et la frontière Tauri. -`0.1.1` et `0.1.2` sont fixées. `0.1.3` / `0.1.4` constituent la séquence par défaut : si le `pre.001` de Config démontre que son périmètre doit être scindé, une release supplémentaire est insérée et les numéros suivants sont décalés plutôt que de surcharger une release. +`0.1.1`, `0.1.2` et `0.1.3` sont désormais stables. `0.1.4` constitue l'étape active suivante avec `ksp-app-config-desk`, première validation desktop/Tauri de Config et modèle des futures applications Tauri KSP. Les contrats publics supplémentaires ne sont introduits que lorsqu'une release concrète en démontre le besoin. diff --git a/deltas/0.1.3/rel.001.md b/deltas/0.1.3/rel.001.md new file mode 100644 index 0000000..4dd74b6 --- /dev/null +++ b/deltas/0.1.3/rel.001.md @@ -0,0 +1,182 @@ + + + +# Delta `0.1.3-rel.001` — publication stable Configuration foundation + +## Base requise + +`0.1.3-pre.015` avec les correctifs documentaires `pre.015-fix.001` et `pre.015-fix.002`, au sens des commits de livraison correspondants, avec : + +```text +workspace.package.version = "0.1.3-pre.15" +``` + +Les deux fixes de `pre.015` ne modifient pas la version Cargo. + +## Objectif + +Publier la release stable `0.1.3`, clôturer `Configuration foundation` et préparer l'ouverture de `0.1.4 — ksp-app-config-desk` sans ajouter de nouvelle fonctionnalité runtime. + +## Version Cargo + +`workspace.package.version` passe de : + +```text +0.1.3-pre.15 +``` + +à : + +```text +0.1.3 +``` + +Le header de `Cargo.toml` passe de version 60 à 61. + +Aucune dépendance ni feature Cargo n'est ajoutée ou retirée par cette publication. + +## Validations finales exécutées par le user + +Commandes communiquées avec succès le 2026-08-16 sur `0.1.3-pre.15` après application de `pre.015-fix.001` et `pre.015-fix.002` : + +```bash +cargo fmt --all +cargo check --workspace +cargo clippy --workspace --all-targets +cargo test --workspace +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 +``` + +Résultats communiqués : + +- `cargo check --workspace` : succès ; +- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ; +- `cargo test --workspace` : succès ; +- `ksp-config-lib` : 80 tests unitaires, 4 audits ownership et 11 tests publics réussis ; +- `ksp-core-lib` : 14 tests unitaires et 3 tests publics réussis ; +- `ksp-logging-lib` : 34 tests unitaires et toutes les intégrations exécutées réussies ; le probe d'overhead reste volontairement `ignored` par défaut ; +- `cargo tree -p ksp-config-lib -d` : seul doublon observé, `syn 2.0.119` / `syn 3.0.3`, transitif via `jsonschema` et ses dépendances ; +- `cargo tree -p ksp-config-lib -e normal` : graphe runtime cohérent avec Core, Logging, `serde`, `serde_json` et `jsonschema` ; +- `cargo tree -p ksp-logging-lib -d` : aucun doublon. + +## Surface stable publiée + +`0.1.3` stabilise notamment : + +- `ksp-config-lib` comme propriétaire unique KSP des documents Config, schemas, profils, compositions, variables applicatives KSP/KSPB, `.env`, interpolation et persistence autorisée ; +- le bootstrap non récursif `cfgpath` / `schemapath` et les overrides physiques `--filemap==` ; +- le registre logique `file_id -> filename` et l'association logique document/schema ; +- parsing JSON, validation JSON Schema Draft 2020-12 et validation sémantique KSP ; +- globals, `default_profile`, profils, provenance de sélection et compositions par `file_id` ; +- priorité `process environment > .env > fallback > missing`, avec chaîne vide explicitement définie ; +- placeholders `${NAME}` et `${NAME:-fallback}` sous contrôle exclusif de Config ; +- sensibilité `Public` / `Internal` / `Secret`, valeurs réelle/sûre et provenance par segment/pointeur JSON ; +- redaction des secrets dans les surfaces sûres et accès réel explicite pour les consumers/management légitimes ; +- `Config -> ksp_logging_lib::LoggingSettings`, validation effective de `logs_directory`, console, multi-sinks, formats, rotations, targets et domains ; +- management typé de `std.logging.json`, lecture management du source brut et persistence atomique ; +- create/update/remove `.env`, preservation des commentaires/lignes non ciblées, permissions existantes et mode `0600` pour un nouveau `.env` sur Unix ; +- rapports de changement distinguant source/effective/shadowing/reload ; +- audits d'ownership empêchant les crates hors Config de contourner Config pour les variables KSP/KSPB ou les ressources physiques gérées ; +- audit automatique de couverture `.env.example` ; +- documentation durable `ksp-config-lib/README.md`, `USAGE.md` et `TODO.md`. + +La release complète également `ksp-logging-lib` avec les capacités nécessaires au contrat `std.logging.json` : settings multi-output, runtime multi-sink, routing niveau/target/domain, formats et hot reload transactionnel, sans introduire de dépendance inverse Logging -> Config. + +## Documentation de clôture + +Le présent delta : + +- ajoute `0.1.3` en tête de `CHANGELOG.md` ; +- marque `0.1.3` réalisée dans `ROADMAP.md` ; +- clôt `005-V0_1_3_CONFIG_FOUNDATION_PLAN.md` comme plan historique ; +- actualise les index docs/plans et la séquence fonctionnelle ; +- corrige dans le README racine l'ancienne mention `apps/` : les packages Rust KSP, y compris les applications Tauri, vivent directement sous `crates/` selon la convention workspace retenue ; +- conserve `prompts/004-V0_1_4_START_PROMPT.md` comme prompt final d'ouverture de la release suivante. + +## Fichiers ajoutés + +```text +deltas/0.1.3/rel.001.md +``` + +## Fichiers modifiés + +```text +Cargo.toml +CHANGELOG.md +ROADMAP.md +README.md +docs/000-README.md +docs/plans/000-README.md +docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md +docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md +``` + +## Fichiers supprimés + +Aucun. + +## Décisions + +Aucune nouvelle décision fonctionnelle Config n'est introduite par `rel.001`. + +La publication stable confirme les décisions prises pendant `0.1.3`, notamment l'ownership exclusif de Config, la séparation source/effective, la politique de sensibilité/redaction, la persistence atomique et la frontière Config -> Logging. + +Les conventions Tauri ajoutées dans `pre.015-fix.001/.002` servent de contraintes d'entrée pour `0.1.4`, mais leur implémentation appartient à cette release suivante. + +## Validation du commit stable + +Ce delta modifie `Cargo.toml` et de la documentation, mais aucun fichier Rust. Conformément aux règles KSP, `cargo fmt --all` n'est pas requis par une modification Rust dans ce delta. + +Avant publication/tag, exécuter sur `workspace.package.version = "0.1.3"` : + +```bash +cargo check --workspace +cargo clippy --workspace --all-targets +cargo test --workspace +cargo tree -p ksp-config-lib +cargo tree -p ksp-config-lib -d +cargo tree -p ksp-config-lib -e normal +cargo tree -p ksp-logging-lib -d +``` + +`cargo test --workspace` est approprié ici car il s'agit précisément de la fermeture d'une version stable. + +## Publication Git + +Après validation du delta : + +1. vérifier le working tree ; +2. créer le commit de release : + +```text +v0.1.3-rel.001 +``` + +3. créer le tag stable : + +```text +v0.1.3 +``` + +Aucun tag des prereleases/fixes intermédiaires n'est requis. + +## Suite + +Après le tag `v0.1.3`, ouvrir : + +```text +0.1.4-pre.001 +``` + +avec : + +```text +prompts/004-V0_1_4_START_PROMPT.md +``` + +`0.1.4-pre.001` commence par brainstorming, audit de la base Tauri de khadhroony-bot3 et planification détaillée avant implémentation de `ksp-app-config-desk`. diff --git a/docs/000-README.md b/docs/000-README.md index 429f222..46aae4f 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation KSP @@ -54,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 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`. +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 la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). La prochaine release active est `0.1.4 — ksp-app-config-desk`, ouverte à partir du prompt [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). `IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales. diff --git a/docs/plans/000-README.md b/docs/plans/000-README.md index ebcc1f0..de78ea1 100644 --- a/docs/plans/000-README.md +++ b/docs/plans/000-README.md @@ -1,5 +1,5 @@ - + # 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 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`. +- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`. Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre. diff --git a/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md b/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md index fcc2ef4..87e884e 100644 --- a/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md +++ b/docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md @@ -1,5 +1,5 @@ - + # Séquence des releases fonctionnelles KSP @@ -36,9 +36,9 @@ Séquence par défaut : 0.1.4 ksp-app-config-desk ``` -`0.1.1` et `0.1.2` sont fixées. +`0.1.1`, `0.1.2` et `0.1.3` sont désormais des releases stables. -`0.1.3` et `0.1.4` sont la séquence par défaut. Si le `pre.001` de Config démontre qu'une seule release ne permet pas un développement propre, Config est scindé et les numéros suivants sont décalés. +`0.1.4 — ksp-app-config-desk` est l'étape active suivante. Elle doit valider réellement la fondation Config et établir le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application. ## `0.1.1` — Core foundation @@ -155,7 +155,7 @@ rel.001 publication stable validée de 0.1.2 ## `0.1.3` — Configuration foundation -### Dépendances candidates +### Dépendances stabilisées ```text ksp-config-lib @@ -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` 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`. +`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` la documentation durable et le prompt `0.1.4`, complétés par deux fixes documentaires sur les validations et le modèle Tauri. `rel.001` publie cette surface sous `0.1.3` stable. Trajectoire réellement suivie : @@ -246,7 +246,9 @@ 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 +pre.015-fix.001 règles validation/docs + modèle Tauri/PRESENTATION +pre.015-fix.002 tracing Tauri + critères fonctionnels de clôture 0.1.4 +rel.001 publication stable validée de 0.1.3 ``` ## `0.1.4` — Config desktop par défaut diff --git a/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md b/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md index aa15e08..9b9b939 100644 --- a/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md +++ b/docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md @@ -1,15 +1,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 `${...}`, `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`. +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 jusqu'à `pre.015` et ses fixes documentaires. La validation finale de `pre.015-fix.002` a été communiquée le 2026-08-16 avec `cargo check --workspace`, `cargo clippy --workspace --all-targets`, `cargo test --workspace` et les audits `cargo tree` Config/Logging attendus. `0.1.3-rel.001` publie désormais cette fondation sous la version stable `0.1.3`; le présent document devient un plan historique clôturé. La base auditée reste la release stable `v0.1.2`. -La release `0.1.3` introduira `ksp-config-lib` comme **propriétaire unique KSP de la configuration applicative**. À terme, les autres crates et applications KSP ne doivent pas : +La release stable `0.1.3` introduit `ksp-config-lib` comme **propriétaire unique KSP de la configuration applicative**. À terme, les autres crates et applications KSP ne doivent pas : - lire directement les documents JSON de configuration ; - valider elles-mêmes ces documents contre leurs schémas ; @@ -1893,7 +1893,11 @@ Tranche livrée : - 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é. +`pre.015-fix.001` a ensuite figé les règles de validation courante/ciblée, les README/USAGE de clôture et le modèle documentaire Tauri (`PRESENTATION.md` uniquement lorsqu'une présentation UI existe). `pre.015-fix.002` a figé l'usage de la stack Tauri tracing — et non `tauri-plugin-log` — ainsi que les critères fonctionnels minimaux de `0.1.4` pour la gestion multi-profils Logging et le hot reload observable. + +La validation finale de `pre.015-fix.002` est acquise le 2026-08-16 : `cargo check --workspace`, `cargo clippy --workspace --all-targets`, `cargo test --workspace`, `cargo tree -p ksp-config-lib`, `-d`, `-e features`, `-e normal` et `cargo tree -p ksp-logging-lib -d` passent. Les tests rapportés comprennent 80 tests unitaires Config, 4 audits ownership, 11 tests publics Config, 14 tests unitaires Core + 3 publics, 34 tests unitaires Logging et toutes ses intégrations exécutées; le probe d'overhead reste volontairement ignoré par défaut. Le seul doublon Config observé reste `syn 2`/`syn 3` transitif via `jsonschema`; Logging n'a aucun doublon signalé. + +`0.1.3-rel.001` clôt la release : `workspace.package.version = "0.1.3"`, changelog/roadmap/index synchronisés, puis tag `v0.1.3` après validation du commit stable. 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.