v0.1.3-pre.015

CHANGELOG.md

@@ -0,0 +1,18 @@
+<!-- file: CHANGELOG.md -->
+<!-- version: 1 -->
+
+# 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.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.
+
+## 0.1.1 — Core foundation — 2026-08-14
+
+`0.1.1` stabilise `ksp-core-lib` avec le contrat commun `ErrorCode` / `ErrorContext` / `Error` / `Result<T>`, la primitive `Pubkey`, les Program IDs Solana fondamentaux possédés par KSP et leur registre canonique recherché/filtrable. La release fixe également la taxonomie de classification et la politique Cargo workspace utilisée par les crates suivantes.
+
+## 0.0.3 — Fondation architecture et règles — 2026-08-14
+
+`0.0.3` clôt la phase fondatrice : nomenclature KSP, règles Rust/Cargo/documentation, architecture en couches, contrats des composants, workers/jobs/pipelines/scénarios/apps, politique de versions/deltas et séquence des premières releases fonctionnelles. Elle prépare explicitement l'ouverture de `0.1.1` sans ajouter de fonctionnalité métier Solana.

Cargo.toml

@@ -1,12 +1,12 @@
 # file: Cargo.toml
-# version: 59
+# version: 60
 
 [workspace]
 resolver = "3"
 members = ["crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"]
 
 [workspace.package]
-version = "0.1.3-pre.14"
+version = "0.1.3-pre.15"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Khadhroony Solana Project
 
@@ -51,6 +51,7 @@ Les besoins du trading constituent une priorité produit à court terme mais ne
 
 - [`RULES.md`](RULES.md) — index des règles normatives ;
 - [`ROADMAP.md`](ROADMAP.md) — trajectoire globale du projet ;
+- [`CHANGELOG.md`](CHANGELOG.md) — synthèse des releases stables ;
 - [`docs/000-README.md`](docs/000-README.md) — point d'entrée de la documentation ;
 - [`docs/IDEAS.md`](docs/IDEAS.md) — idées et sujets à explorer ;
 - [`prompts/000-README.md`](prompts/000-README.md) — prompts de reprise ;

crates/ksp-config-lib/README.md

@@ -0,0 +1,82 @@
+<!-- file: crates/ksp-config-lib/README.md -->
+<!-- version: 1 -->
+
+# ksp-config-lib
+
+`ksp-config-lib` est le propriétaire unique de la configuration applicative KSP.
+
+La crate centralise les documents JSON, leurs schemas, les profils et compositions, les variables d'environnement `KSP_*` / `KSPB_*`, le fichier `.env`, la résolution effective et les mutations persistantes explicitement autorisées.
+
+## Responsabilités
+
+`ksp-config-lib` possède :
+
+- le bootstrap non récursif `config/` / `config/schemas/` et les overrides `--cfgpath` / `--schemapath` ;
+- le registre logique `file_id -> filename` et les overrides `--filemap=<file_id>=<filename>` ;
+- la lecture JSON et la validation JSON Schema Draft 2020-12 ;
+- les invariants sémantiques KSP des documents connus ;
+- les globals, `default_profile`, profils nommés et leur provenance ;
+- les compositions génériques par `file_id`, sans dépendance à un filename physique ;
+- le snapshot des variables process KSP/KSPB et la lecture de `./.env` ;
+- la priorité `process > .env > fallback > missing` ;
+- les placeholders `${NAME}` et `${NAME:-fallback}` ;
+- la classification `Public`, `Internal`, `Secret` ;
+- les représentations réelle et sûre/redacted ainsi que la provenance des valeurs résolues ;
+- l'adapter du document Logging effectif vers `ksp_logging_lib::LoggingSettings` ;
+- la surface de management pour inspecter les sources, modifier `std.logging.json`, consulter les rapports d'environnement, révéler explicitement une valeur réelle et modifier `.env` ;
+- les écritures atomiques JSON/`.env` et la protection des permissions `.env` ;
+- les audits workspace empêchant les bypass d'ownership Config et les oublis dans `.env.example`.
+
+## Ressources gérées dans `0.1.3`
+
+Le registre par défaut connaît :
+
+```text
+cfg.std.logging    -> config/std.logging.json
+schema.std.logging -> config/schemas/std.logging.schema.json
+schema.composite   -> config/schemas/composite.schema.json
+```
+
+`config/examples/composite.example.json` démontre le format composite sans créer de composite runtime fictif.
+
+Le fichier local d'environnement est :
+
+```text
+./.env
+```
+
+Il n'est ni versionné ni livré. Le dépôt maintient `/.env.example` comme inventaire versionné des variables runtime utilisées. Toute nouvelle variable KSP/KSPB concrète doit y être ajoutée avec un commentaire d'usage dans le même delta que sa première utilisation.
+
+## Frontières
+
+Les autres crates et applications KSP ne doivent pas :
+
+- lire directement les variables applicatives `KSP_*` / `KSPB_*` ;
+- parser ou écrire directement `.env` ;
+- ouvrir directement les documents Config connus par leur filename physique ;
+- réimplémenter la sélection de profils, les compositions ou les placeholders ;
+- reconstruire elles-mêmes la configuration Logging depuis le JSON.
+
+`ksp-config-lib` dépend de `ksp-core-lib` pour `Error`/`Result` et de `ksp-logging-lib` pour les événements Config utiles et le contrat `LoggingSettings`.
+
+La dépendance inverse est interdite : `ksp-core-lib` et `ksp-logging-lib` ne dépendent pas de Config.
+
+Config ne possède pas le `LoggingGuard`. L'application ou le service qui orchestre le runtime construit la configuration effective puis possède le lifecycle `ksp_logging_lib::initialize/reinitialize`.
+
+Tauri et les DTO TS-RS restent hors de cette crate. La future `ksp-app-config-desk` doit rester une frontière applicative mince au-dessus des APIs Config.
+
+## Secrets
+
+Un secret reste accessible au runtime ou au management lorsqu'un consumer autorisé en a réellement besoin, mais les vues ordinaires utilisent la représentation sûre.
+
+Les méthodes `reveal_*` constituent un opt-in explicite au réel. L'authentification/autorisation de l'utilisateur humain appartient à l'application appelante et les valeurs retournées par ces méthodes ne doivent jamais être journalisées.
+
+Le document Logging refuse les valeurs de sensibilité `Secret` dans sa configuration effective.
+
+## Documentation
+
+- [`USAGE.md`](USAGE.md) — construction du moteur, résolution runtime et management ;
+- [`TODO.md`](TODO.md) — points explicitement différés après `0.1.3` ;
+- [`../../docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](../../docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique détaillé de la fondation Config ;
+- [`../../config/std.logging.json`](../../config/std.logging.json) — premier document standard concret ;
+- [`../../.env.example`](../../.env.example) — inventaire versionné des variables d'environnement runtime.

crates/ksp-config-lib/TODO.md

@@ -0,0 +1,38 @@
+<!-- file: crates/ksp-config-lib/TODO.md -->
+<!-- version: 1 -->
+
+# TODO ksp-config-lib
+
+## État de clôture `0.1.3`
+
+Aucun TODO fonctionnel bloquant n'est ouvert pour la fondation Config `0.1.3`.
+
+Les responsabilités prévues pour cette release sont implémentées et couvertes par les tests : bootstrap, registre `file_id`, JSON/JSON Schema, profils, composites, environnement process/`.env`, placeholders, sensibilité/provenance, adapter Logging, management/persistence et audits d'ownership.
+
+## Reporté explicitement à `0.1.4`
+
+La validation applicative desktop appartient à `ksp-app-config-desk` :
+
+- frontière Tauri et DTO TS-RS applicatifs ;
+- affichage des sources et diagnostics Config ;
+- sélection/inspection des profils ;
+- affichage desired/effective/shadow des variables ;
+- actions explicites de reveal de secrets avec contrôle d'autorisation côté application ;
+- édition/sauvegarde de `std.logging.json` via `ConfigManagement` ;
+- édition de `.env` via `ConfigManagement` ;
+- orchestration réelle `Config -> LoggingSettings -> initialize/reinitialize` avec `LoggingGuard` possédé par l'application ;
+- validation UX des erreurs de source invalide, des modifications non effectives car masquées par le process et des besoins de reload.
+
+Ces points ne nécessitent pas de duplication de logique dans `ksp-config-lib`; toute lacune réelle révélée par l'application ouvrira un delta Config explicite.
+
+## Futur, uniquement au besoin
+
+Les capacités suivantes sont différées jusqu'à l'apparition de composants réels :
+
+- nouveaux documents `std.<domain>.json` et schemas associés ;
+- descriptors `cfg.composite.<consumer>` pour de vrais consumers ;
+- contrats typés de management supplémentaires pour les nouveaux documents ;
+- watcher filesystem/reload automatique si une application ou un service démontre le besoin ;
+- intégration éventuelle d'un secrets manager externe.
+
+Ne pas introduire par anticipation un JSON patch arbitraire, un watcher générique, un service distribué de configuration ou un chiffrement maison de `.env`.

crates/ksp-config-lib/USAGE.md

@@ -0,0 +1,184 @@
+<!-- file: crates/ksp-config-lib/USAGE.md -->
+<!-- version: 1 -->
+
+# Utilisation de ksp-config-lib
+
+## 1. Bootstrap et moteur documentaire
+
+Config doit interpréter ses propres arguments de bootstrap avant toute lecture de document :
+
+```rust
+let args: std::vec::Vec<std::ffi::OsString> = std::env::args_os().collect();
+
+let bootstrap = match ksp_config_lib::ConfigBootstrapOptions::from_args(args.as_slice()) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let registry = match ksp_config_lib::ConfigFileRegistry::from_args(args.as_slice()) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let engine = ksp_config_lib::ConfigDocumentEngine::new(bootstrap, registry);
+```
+
+Les arguments compris par Config sont :
+
+```text
+--cfgpath=/path/to/config
+--schemapath=/path/to/schemas
+--filemap=cfg.std.logging=my-logging.json
+```
+
+`cfgpath` et `schemapath` ne sont jamais lus depuis JSON, `.env` ou une variable KSP : cette règle évite un bootstrap récursif.
+
+## 2. Charger et valider un document connu
+
+Les consumers utilisent un `file_id` logique :
+
+```rust
+let file_id = match ksp_config_lib::ConfigFileId::new(ksp_config_lib::FILE_ID_STD_LOGGING) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let document = engine.load_validated_document(&file_id);
+```
+
+Le moteur résout le path physique via le registre, charge le schema associé, valide le schema lui-même, valide l'instance puis applique les invariants sémantiques KSP.
+
+## 3. Environnement effectif
+
+`ConfigEnvironment::load()` capture les variables process KSP/KSPB et lit `./.env` :
+
+```rust
+let environment = match ksp_config_lib::ConfigEnvironment::load() {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+```
+
+La priorité est :
+
+```text
+process environment > .env > fallback > missing
+```
+
+Une chaîne vide explicitement présente est une valeur définie ; elle ne provoque pas l'utilisation du fallback.
+
+Exemples de placeholders :
+
+```text
+${KSP_LOGS_DIRECTORY}
+${KSP_LOGS_DIRECTORY:-logs}
+```
+
+Pour conserver la sensibilité et la provenance, préférer les variantes détaillées :
+
+```rust
+let resolved = environment.resolve_text_detailed("${KSP_SECRET_EXAMPLE}");
+```
+
+`ResolvedConfigText` / `ResolvedConfigJson` séparent valeur réelle et valeur sûre. Une représentation `Debug` ne doit pas révéler le réel d'un secret.
+
+## 4. Construire Logging depuis Config
+
+Le chemin normal consiste à charger le profil Logging, résoudre l'environnement puis construire directement le contrat Logging public :
+
+```rust
+let resolved = match engine.load_resolved_logging_config(std::option::Option::None, &environment) {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+
+let settings = resolved.into_settings();
+let initialized = ksp_logging_lib::initialize(&settings);
+let mut logging_guard = match initialized {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+```
+
+L'application/service possède `logging_guard`. Config ne conserve pas de singleton Logging.
+
+Un `logs_directory` relatif est ancré sur le current working directory du processus. Un path absolu est conservé. Une valeur explicite invalide produit une erreur effective : elle ne retombe pas silencieusement sur le fallback du placeholder.
+
+Les `files[].path` restent relatifs sous le root Logging, y compris après interpolation.
+
+## 5. Profils et composites
+
+Pour un document standard profilé :
+
+```rust
+let profile = engine.load_resolved_profile(&file_id, std::option::Option::None);
+```
+
+`None` utilise le `default_profile`; `Some("profile_id")` impose un profil explicite.
+
+Un composite référence les documents par `file_id`, jamais par filename. `load_resolved_composite(...)` conserve chaque `ResolvedConfigProfile` composant et sa provenance plutôt que d'aplatir plusieurs domaines dans une map ambiguë.
+
+## 6. Management de `std.logging.json`
+
+Une application de management construit la façade à partir d'un moteur :
+
+```rust
+let management = ksp_config_lib::ConfigManagement::new(engine);
+
+let document = match management.load_logging_document() {
+    std::result::Result::Ok(value) => value,
+    std::result::Result::Err(error) => return std::result::Result::Err(error),
+};
+```
+
+Le type `LoggingConfigDocument` et ses sous-structures exposent des setters/mutators typés. Après modification, la sauvegarde :
+
+```rust
+let saved = management.save_logging_document(&document);
+```
+
+valide le candidat complet avant toute substitution du fichier. Un candidat invalide ne remplace pas la source existante.
+
+`read_source(file_id)` reste disponible pour une UI de réparation : il peut lire le texte brut d'un document enregistré même lorsque son JSON ou son schema est invalide. Il n'ouvre pas un path arbitraire.
+
+## 7. Management de `.env`
+
+Les rapports ordinaires sont sûrs :
+
+```rust
+let report = management.environment_report();
+```
+
+Ils distinguent notamment valeur souhaitée `.env`, valeur effective, source et shadowing process sans exposer un secret réel.
+
+L'accès au réel est volontairement explicite :
+
+```rust
+let effective = management.reveal_effective_environment_value("KSP_SECRET_EXAMPLE");
+let persisted = management.reveal_dotenv_value("KSP_SECRET_EXAMPLE");
+```
+
+Une application doit contrôler l'autorisation de l'utilisateur avant ces appels et ne jamais journaliser les valeurs retournées.
+
+Les mutations persistantes utilisent :
+
+```rust
+let changed = management.set_dotenv_value("KSP_LOGS_DIRECTORY", "logs");
+let removed = management.remove_dotenv_value("KSP_LOGS_DIRECTORY");
+```
+
+Elles n'altèrent jamais l'environnement hérité du processus. Une valeur process peut donc masquer une modification `.env`; `ConfigEnvironmentChangeReport` distingue `source_changed`, `effective_changed`, `shadowed_by_process_environment` et `reload_required`.
+
+Sur Unix, un nouveau `.env` est créé avec des permissions privées `0600`; les permissions existantes sont préservées lors des remplacements atomiques.
+
+## 8. `.env.example`
+
+`/.env.example` est l'inventaire versionné. `/.env` reste local et ignoré.
+
+Toute nouvelle variable runtime concrète `KSP_*` / `KSPB_*` introduite dans le code ou les documents Config doit être ajoutée à `.env.example` avec un commentaire expliquant son usage. Les audits `ksp-config-lib/tests/ownership.rs` font échouer `cargo test` lorsqu'une clé concrète est oubliée.
+
+## 9. Frontière Tauri
+
+Une application Tauri doit appeler les APIs ci-dessus via ses commandes/DTO applicatifs. Elle ne lit ni JSON ni `.env` directement et ne résout jamais elle-même les placeholders.
+
+Les valeurs `Secret` ne doivent pas être incluses par défaut dans les DTO publics. Une action UI explicitement autorisée peut appeler une méthode `reveal_*` et transporter le résultat par un DTO spécifique, sans log ni diagnostic contenant la valeur réelle.

crates/ksp-config-lib/src/lib.rs

@@ -1,15 +1,15 @@
 // file: crates/ksp-config-lib/src/lib.rs
-// version: 9
+// version: 10
 #![warn(missing_docs)]
 #![deny(unreachable_pub)]
 #![forbid(unsafe_code)]
 
 //! KSP-owned application configuration facade.
 //!
-//! `0.1.3-pre.013` owns bootstrap roots, the logical file registry, generic JSON/JSON Schema loading, standard-document profile resolution, generic composite
+//! The `0.1.3` surface owns bootstrap roots, the logical file registry, JSON/JSON Schema validation, standard-document profiles, generic composites and
-//! resolution and KSP/KSPB environment resolution through process + `.env` + fallback precedence. The standard Logging document remains the first registered
+//! KSP/KSPB environment resolution through process + `.env` + fallback precedence. Resolved values preserve real/safe representations, sensitivity and
-//! runtime document. Environment-derived values preserve real/safe representations, sensitivity and provenance; the standard Logging profile can now be
+//! provenance. The standard Logging document maps explicitly to `ksp_logging_lib::LoggingSettings`, while the management surface provides typed Logging
-//! mapped explicitly to `ksp_logging_lib::LoggingSettings`. Explicit management now owns typed Logging mutation, safe environment reports, privileged reveal calls and atomic JSON/`.env` persistence.
+//! mutation, safe environment reports, explicit privileged reveal calls and atomic JSON/`.env` persistence.
 
 mod bootstrap;
 mod composite;

deltas/0.1.3/pre.015.md

@@ -0,0 +1,242 @@
+<!-- file: deltas/0.1.3/pre.015.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-pre.015 — clôture Config
+
+## Base requise
+
+Livraison précédente validée :
+
+```text
+0.1.3-pre.014
+workspace.package.version = "0.1.3-pre.14"
+Cargo.toml header version = 59
+```
+
+## Validation de `pre.014`
+
+Validations utilisateur exécutées le 2026-08-16 :
+
+```text
+cargo fmt --all                           OK
+cargo check --workspace                  OK
+cargo clippy --workspace --all-targets   OK
+cargo test --workspace                   OK
+cargo tree -p ksp-config-lib             OK
+cargo tree -p ksp-config-lib -d          OK, doublon transitif syn 2/3 connu via jsonschema
+cargo tree -p ksp-config-lib -e features OK
+cargo tree -p ksp-logging-lib -d         OK, aucun doublon
+```
+
+Le test workspace confirme :
+
+```text
+ksp-config-lib unit tests      80 passed
+Config ownership integration   4 passed
+Config public API              11 passed
+ksp-core-lib unit              14 passed
+Core public API                 3 passed
+ksp-logging-lib unit           34 passed
+Logging integrations            all passed
+```
+
+## Objet de `pre.015`
+
+`pre.015` est la prerelease finale prévue de `0.1.3`.
+
+Elle ne développe aucune nouvelle capacité Config. Elle :
+
+- consolide la documentation durable de `ksp-config-lib` ;
+- ferme ou reporte explicitement les TODO de release ;
+- introduit le changelog général selon les règles déjà définies ;
+- prépare le prompt de `0.1.4 — ksp-app-config-desk` ;
+- réaligne les index et plans ;
+- prépare les validations finales précédant `rel.001` ;
+- confirme qu'aucun cleanup destructif supplémentaire n'est nécessaire.
+
+## Version technique
+
+Conformément à `VER-ID-009`, une prerelease non-fix synchronise toujours la version Cargo, même lorsque la tranche est principalement documentaire :
+
+```text
+workspace.package.version = "0.1.3-pre.15"
+Cargo.toml header version = 60
+```
+
+Aucune dépendance ni feature Cargo ne change.
+
+## Documentation durable de `ksp-config-lib`
+
+Ajout de :
+
+```text
+crates/ksp-config-lib/README.md
+crates/ksp-config-lib/USAGE.md
+crates/ksp-config-lib/TODO.md
+```
+
+Le README décrit les responsabilités et frontières stabilisées de Config.
+
+`USAGE.md` documente :
+
+- bootstrap + registre ;
+- chargement/validation ;
+- environnement effectif ;
+- mapping Logging ;
+- profils/composites ;
+- management du document Logging ;
+- management `.env` ;
+- secret reveal explicite ;
+- `.env.example` ;
+- frontière Tauri.
+
+`TODO.md` confirme qu'aucun TODO fonctionnel bloquant ne reste dans `0.1.3`. Les validations desktop/Tauri sont transférées à `0.1.4`; les futurs documents/composites/watchers restent conditionnés à l'apparition d'un besoin concret.
+
+Le crate-level Rustdoc est rendu durable et ne décrit plus la surface comme limitée à `pre.013`.
+
+## Changelog général
+
+Ajout de :
+
+```text
+CHANGELOG.md
+```
+
+Il applique `DOC-ROOT-008` : uniquement les releases stables et ordre décroissant.
+
+Il contient à cette étape :
+
+```text
+0.1.2
+0.1.1
+0.0.3
+```
+
+`0.1.3` n'y figure pas encore car `pre.015` n'est pas une release stable. Son entrée sera ajoutée dans `rel.001` après validation finale.
+
+## Prompt `0.1.4`
+
+Ajout de :
+
+```text
+prompts/004-V0_1_4_START_PROMPT.md
+```
+
+Le prompt ne doit être utilisé qu'après publication stable `v0.1.3`.
+
+Il impose que `0.1.4-pre.001` commence par brainstorming + audit + planification, avant tout développement Tauri significatif, et cadre notamment :
+
+- application `ksp-app-config-desk` mince au-dessus de Config ;
+- DTO/Tauri à la frontière applicative ;
+- management de documents/profils/env ;
+- reveal de secrets explicitement privilégié ;
+- ownership applicatif du `LoggingGuard` ;
+- tests et découpage des prereleases ;
+- hors-scope de la release.
+
+## Cleanup / archivage
+
+Aucune suppression n'est nécessaire.
+
+Sont conservés intentionnellement :
+
+- tous les deltas `0.1.3` et leurs fixes ;
+- les plans historiques `0.1.1`/`0.1.2` ;
+- le plan `0.1.3` ;
+- les prompts historiques ;
+- les schemas et exemples Config ;
+- `.env.example`.
+
+Le fichier local `.env` reste ignoré, non échangé et absent du delta.
+
+Aucun `Cargo.lock`, cache, build output ou archive imbriquée n'est ajouté.
+
+## TODO et reports
+
+Audit du code Config avant livraison : aucun marqueur `TODO`, `FIXME`, `XXX` ou `HACK` n'est présent dans les sources/manifest de la crate.
+
+Les reports utiles sont documentés dans `crates/ksp-config-lib/TODO.md` et concernent principalement :
+
+- validation desktop `0.1.4` ;
+- futurs documents standards quand leurs composants existent ;
+- composites de consumers réels ;
+- watcher/reload automatique uniquement si un besoin concret l'exige ;
+- éventuel secrets manager externe plus tard.
+
+Aucun de ces reports ne bloque `0.1.3`.
+
+## Fichiers ajoutés
+
+```text
+CHANGELOG.md
+crates/ksp-config-lib/README.md
+crates/ksp-config-lib/TODO.md
+crates/ksp-config-lib/USAGE.md
+prompts/004-V0_1_4_START_PROMPT.md
+deltas/0.1.3/pre.015.md
+```
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+README.md
+crates/ksp-config-lib/src/lib.rs
+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
+prompts/000-README.md
+```
+
+## Fichiers supprimés
+
+Aucun.
+
+## Validations finales demandées
+
+```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
+```
+
+Vérifier également localement qu'aucun `.env` réel n'est suivi/ajouté au commit.
+
+## Étape suivante après validation
+
+Si `pre.015` est propre, préparer :
+
+```text
+0.1.3-rel.001
+```
+
+avec :
+
+```text
+workspace.package.version = "0.1.3"
+```
+
+`rel.001` devra :
+
+- enregistrer les validations finales de `pre.015` ;
+- ajouter la synthèse stable `0.1.3` à `CHANGELOG.md` en tête ;
+- marquer `0.1.3` `[X]` dans `ROADMAP.md` ;
+- classer le plan `005` comme historique clôturé ;
+- réaligner les index/séquence ;
+- ne modifier aucune surface fonctionnelle ;
+- préparer le commit stable et, après validation, le tag `v0.1.3`.
+
+La session suivante peut ensuite démarrer avec :
+
+```text
+prompts/004-V0_1_4_START_PROMPT.md
+```

docs/000-README.md

@@ -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.
 

docs/plans/000-README.md

@@ -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.
 

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -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
 

docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md

@@ -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 ;
+Tranche livrée :
-- documentation durable ;
+
-- cleanup/archivage requis ;
+- 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 ;
-- TODO fermés ou reportés ;
+- `workspace.package.version = "0.1.3-pre.15"` comme signal technique de la prerelease finale ;
-- prompt `0.1.4 — ksp-app-config-desk` ;
+- documentation durable `ksp-config-lib/README.md`, `USAGE.md` et `TODO.md` ;
-- préparation `rel.001` puis tag stable après validation utilisateur.
+- `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.

prompts/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/000-README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Prompts KSP
 
@@ -23,4 +23,5 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
 
 - [`001-V0_1_1_START_PROMPT.md`](001-V0_1_1_START_PROMPT.md) — prompt historique ouvrant la première release fonctionnelle `0.1.1` après publication stable de `0.0.3` ;
 - [`002-V0_1_2_START_PROMPT.md`](002-V0_1_2_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.2 — Logging foundation` après publication stable de `0.1.1`.
-- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2`.
+- [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
+- [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.

prompts/004-V0_1_4_START_PROMPT.md

@@ -0,0 +1,244 @@
+<!-- file: prompts/004-V0_1_4_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage `0.1.4` — ksp-app-config-desk
+
+## 1. Mission
+
+Ouvrir `0.1.4` uniquement après publication et tag validés de `v0.1.3`.
+
+La mission de cette release est d'introduire `ksp-app-config-desk`, première application desktop spécialisée KSP, afin de valider réellement `ksp-config-lib` et la frontière Tauri sans déplacer la logique Config dans l'application.
+
+La **première prerelease `0.1.4-pre.001` doit être consacrée au brainstorming, à l'audit et au plan détaillé**. Ne pas commencer directement par une implémentation Tauri dispersée. Le `pre.001` doit décider les écrans, commandes, DTO, lifecycle Logging, risques secrets, packaging et découpage des prereleases avant le développement fonctionnel.
+
+## 2. Base requise
+
+Base stable attendue :
+
+```text
+v0.1.3
+workspace.package.version = "0.1.3"
+```
+
+Le workspace doit contenir au minimum :
+
+```text
+crates/ksp-core-lib
+crates/ksp-logging-lib
+crates/ksp-config-lib
+config/std.logging.json
+config/schemas/std.logging.schema.json
+config/schemas/composite.schema.json
+config/examples/std.logging.example.json
+config/examples/composite.example.json
+.env.example
+```
+
+Avant toute modification, relire :
+
+```text
+README.md
+RULES.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
+crates/ksp-config-lib/README.md
+crates/ksp-config-lib/USAGE.md
+crates/ksp-config-lib/TODO.md
+crates/ksp-logging-lib/README.md
+crates/ksp-logging-lib/USAGE.md
+```
+
+Relire également les règles Tauri/Rust/documentation avant de choisir la structure finale de l'application.
+
+## 3. Surface Config stable à réutiliser
+
+`ksp-config-lib 0.1.3` possède déjà :
+
+- `ConfigBootstrapOptions` et les arguments `--cfgpath` / `--schemapath` ;
+- `ConfigFileRegistry`, `ConfigFileId` et `--filemap` ;
+- `ConfigDocumentEngine` ;
+- validation JSON/JSON Schema et invariants sémantiques ;
+- globals, profils, `default_profile` et provenance ;
+- composites génériques par `file_id` ;
+- `ConfigEnvironment` avec priorité process > `.env` > fallback ;
+- `${NAME}` / `${NAME:-fallback}` ;
+- `Public` / `Internal` / `Secret`, real/safe/provenance ;
+- `ResolvedLoggingConfig` et le mapping vers `ksp_logging_lib::LoggingSettings` ;
+- `ConfigManagement` ;
+- lecture source brute d'un `file_id` connu ;
+- `LoggingConfigDocument` et ses sous-contrats typés mutables ;
+- persistence atomique de `std.logging.json` ;
+- rapports d'environnement desired/effective/shadow ;
+- `reveal_effective_environment_value()` / `reveal_dotenv_value()` comme frontières explicites d'accès au réel ;
+- `set_dotenv_value()` / `remove_dotenv_value()` ;
+- audits workspace de non-contournement Config et couverture `.env.example`.
+
+L'application doit **consommer ces APIs**, pas reproduire leur comportement.
+
+## 4. Architecture cible à auditer pendant `pre.001`
+
+Direction attendue :
+
+```text
+ksp-app-config-desk
+    -> ksp-config-lib
+    -> ksp-logging-lib
+    -> ksp-core-lib via les contrats KSP nécessaires
+```
+
+L'application est une composition/interface. Elle ne devient pas propriétaire :
+
+- du parsing JSON ;
+- des schemas ;
+- de `.env` ;
+- des placeholders ;
+- de la classification des secrets ;
+- du mapping Logging ;
+- de la persistence Config.
+
+La structure sous `apps/` et l'intégration au workspace doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles.
+
+## 5. Capacités desktop à valider
+
+Le brainstorming `pre.001` doit au minimum cadrer une UI permettant de tester réellement :
+
+### Documents et diagnostics
+
+- afficher les documents Config enregistrés par `file_id` ;
+- afficher le source brut lorsqu'un document est invalide afin de permettre sa réparation ;
+- distinguer erreurs JSON, schema, sémantiques et erreurs de configuration effective ;
+- ne jamais demander à l'UI de reconstruire elle-même les validations.
+
+### Profils
+
+- afficher `default_profile` ;
+- lister les profils disponibles ;
+- sélectionner explicitement un profil pour inspection/résolution ;
+- montrer distinctement source/global/profile/effective lorsque cela est utile à l'opérateur.
+
+### Environnement
+
+- afficher les variables KSP/KSPB via les rapports Config ;
+- distinguer desired `.env`, effective, source process/`.env` et shadowing ;
+- ne montrer par défaut que `safe_value` ;
+- créer/modifier/supprimer une entrée `.env` uniquement via `ConfigManagement` ;
+- signaler clairement qu'une valeur process peut masquer une modification `.env` et qu'un process parent ne peut pas être modifié par l'application.
+
+### Secrets
+
+- aucune valeur `Secret` réelle dans un DTO général, un log, un diagnostic ou un état UI persistant par défaut ;
+- une action utilisateur explicitement privilégiée peut appeler une méthode `reveal_*` ;
+- l'authentification/autorisation de cette action appartient à l'application, pas à `ksp-config-lib` ;
+- le `pre.001` doit décider le contrat UX/DTO précis de reveal sans journaliser le secret.
+
+### Logging
+
+- charger `std.logging.json` via Config ;
+- éditer ses profils/sinks via les types de management Config ;
+- sauvegarder via `save_logging_document()` ;
+- construire la configuration effective via `load_resolved_logging_config()` ;
+- initialiser/reconfigurer `ksp-logging-lib` ;
+- conserver `LoggingGuard` dans l'état applicatif/orchestration approprié ;
+- vérifier qu'une erreur de nouvelle configuration ne détruit pas le runtime Logging déjà valide.
+
+## 6. Frontière Tauri
+
+Conserver les règles KSP déjà retenues :
+
+- TS-RS principalement à la frontière de l'application ;
+- les DTO Tauri appartiennent à `ksp-app-config-desk`, pas à `ksp-config-lib`, sauf contrat externe générique explicitement justifié ;
+- le `pre.001` doit décider et formaliser l’emplacement exact des `#[tauri::command]`; conserver comme direction héritée un adapter Tauri centralisé plutôt que des annotations dispersées ;
+- pas de `?`, `unwrap`, `expect` ou `panic` dans les commandes ;
+- l'application reste mince et appelle des fonctions/services internes qui réutilisent les crates KSP ;
+- aucune dépendance directe aux crates `tracing*` dans l'application : Logging reste la façade ;
+- aucune lecture directe `std::env::var*` pour `KSP_*` / `KSPB_*` ;
+- aucune lecture/écriture directe des fichiers physiques Config/`.env`.
+
+Le `pre.001` doit vérifier les versions actuelles de Tauri et des dépendances frontend réellement nécessaires avant leur ajout. Les dépendances communes sont déclarées au niveau workspace lorsqu'elles sont partagées ; aucune dépendance n'est ajoutée sans usage immédiat.
+
+## 7. Sécurité et redaction
+
+Le desktop Config est une application de management privilégiée, mais cela ne supprime pas les frontières de sécurité :
+
+- les secrets ne sont jamais loggés ;
+- `Debug`/diagnostics utilisent les vues sûres ;
+- les APIs `reveal_*` sont appelées uniquement pour une intention explicite ;
+- les DTO de reveal sont séparés des DTO ordinaires ;
+- l'application doit éviter de conserver inutilement les secrets en mémoire/état UI ;
+- une capture d'erreur ne doit pas recopier une valeur réelle dans son message/context ;
+- le fichier `.env` reste non versionné ; `.env.example` reste l'inventaire versionné.
+
+## 8. Règles Rust et projet à conserver
+
+Conserver notamment :
+
+- Rust 2024 ;
+- `unsafe` interdit ;
+- pas de `unwrap`, `expect`, `panic` dans le code production ;
+- pas d'opérateur `?` ;
+- retours explicites selon Clippy workspace ;
+- pas de `mod.rs` ;
+- pas de `pub(super)` / `pub(in ...)` ;
+- code/Rustdoc en anglais ;
+- Markdown projet en français ;
+- tests unitaires hors `src` avec structure miroir ;
+- tests publics dans `tests/` ;
+- dépendances externes communes sous `[workspace.dependencies]` puis `.workspace = true` ;
+- versions caret de génération compatibles ;
+- aucun `Cargo.lock`/lockfile frontend versionné selon la politique KSP actuelle ;
+- chaque delta `0.1.x` est commité ; un défaut livré est corrigé par un `fix`, jamais réécrit silencieusement.
+
+## 9. Hors scope par défaut de `0.1.4`
+
+Ne pas ouvrir automatiquement :
+
+- Wallet ;
+- Store/PostgreSQL ;
+- RPC/WS/provider ;
+- Program/decoder/executor ;
+- workers/jobs/pipelines ;
+- trading/ML ;
+- nouveaux documents Config pour des composants inexistants ;
+- watcher filesystem générique ;
+- service distribué de configuration ;
+- secrets manager distant ;
+- chiffrement maison de `.env` ;
+- application de contrôle globale KSP.
+
+Toute extension doit être justifiée dans `pre.001` ou reportée.
+
+## 10. Première livraison attendue : `0.1.4-pre.001`
+
+`pre.001` doit être un **plan de travail**, pas une grosse implémentation.
+
+Il doit produire au minimum :
+
+1. audit exact de la base stable `v0.1.3` ;
+2. audit des règles Tauri/app existantes ;
+3. choix du layout `apps/ksp-app-config-desk` et de son intégration workspace ;
+4. matrice commandes Tauri / services internes / APIs Config appelées ;
+5. matrice DTO ordinaires / DTO secrets privilégiés ;
+6. modèle d'état applicatif et ownership de `LoggingGuard` ;
+7. écrans/panneaux minimums et flux utilisateur ;
+8. stratégie de tests Rust, Tauri et frontend ;
+9. dépendances externes réellement nécessaires et versions actuelles vérifiées ;
+10. hors-scope confirmés ;
+11. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ;
+12. critères de validation de la release.
+
+Ne commencer `pre.002` qu'après validation de ce plan.
+
+## 11. Clôture future de `0.1.4`
+
+La dernière prerelease de `0.1.4` devra comme d'habitude :
+
+- exécuter les validations finales ;
+- consolider la documentation ;
+- fermer/report explicitement les TODO ;
+- nettoyer/archiver ce qui doit l'être ;
+- synchroniser le changelog général lors de la publication stable ;
+- produire le prompt de la release suivante ;
+- préparer `rel.001` puis le tag stable `v0.1.4` après validation utilisateur.