v0.1.4-pre.001

Cargo.toml

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

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 
 # Roadmap KSP
 
@@ -34,9 +34,9 @@ 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`.
 - [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.4` — Introduire `ksp-app-config-desk` pour valider réellement Config et la frontière Tauri.
 
-`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.
+`0.1.1`, `0.1.2` et `0.1.3` sont désormais stables. `0.1.4` est ouverte par `pre.001` avec le plan `docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md` ; elle introduit `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.
 

deltas/0.1.4/pre.001.md

@@ -0,0 +1,278 @@
+<!-- file: deltas/0.1.4/pre.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-pre.001
+
+## Base requise
+
+Release stable/taguée attendue :
+
+```text
+v0.1.3
+```
+
+L'archive fournie `khadhroony-solana-project-v0.1.3.zip` contient bien :
+
+- `workspace.package.version = "0.1.3"` ;
+- `ksp-core-lib` ;
+- `ksp-logging-lib` ;
+- `ksp-config-lib` ;
+- les ressources `config/` et `.env.example` attendues ;
+- `deltas/0.1.3/rel.001.md` ;
+- `prompts/004-V0_1_4_START_PROMPT.md`.
+
+L'archive n'embarque pas `.git` ; le tag `v0.1.3` n'est donc pas revérifiable localement depuis le zip. La base stable fournie est utilisée comme prérequis validé de la session.
+
+## Objectif
+
+Ouvrir `0.1.4` par la tranche obligatoire de brainstorming, audit et planification de `ksp-app-config-desk`, sans commencer l'implémentation Tauri fonctionnelle.
+
+Le plan détaillé est ajouté dans :
+
+```text
+docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
+```
+
+## Version Cargo
+
+Conformément à `VER-ID-009`, `workspace.package.version` passe de :
+
+```text
+0.1.3
+```
+
+à :
+
+```text
+0.1.4-pre.1
+```
+
+L'identifiant de livraison reste `0.1.4-pre.001`.
+
+Aucune dépendance Tauri/frontend n'est ajoutée par cette tranche.
+
+## Audit de la base Config/Logging
+
+La surface `0.1.3` répond déjà à l'essentiel de la future application : bootstrap, registre, validation, profils, environnement, sensibilité, management, persistence Logging/.env, mapping Logging et hot reload.
+
+Deux lacunes publiques ont cependant été identifiées avant tout code UI :
+
+1. `ConfigFileRegistry` n'expose pas encore d'itération publique sur les descripteurs enregistrés ;
+2. `ConfigManagement::read_source()` sait lire un document invalide, mais aucune API publique ne permet encore de soumettre un texte corrigé, le faire revalider par Config puis le persister atomiquement.
+
+Décision : compléter ces deux contrats dans `ksp-config-lib` avant de construire l'UI correspondante. L'application ne codera pas une liste parallèle de `file_id` et n'écrira jamais directement le fichier physique.
+
+## Audit Tauri bot3
+
+La référence `kb-app-demo-desktop` confirme la valeur des choix suivants :
+
+- package Rust mixte `lib` + `bin` ;
+- single-instance ;
+- `tauri.rs` central ;
+- `LoggingGuard` durable dans l'état ;
+- splash + main ;
+- Vite/Vanilla TypeScript ;
+- SCSS/Bootstrap/Font Awesome ;
+- DTO TS-RS applicatifs.
+
+Ne sont pas recopiés tels quels :
+
+- timings splash codés en dur ;
+- gros ensemble de dépendances de démo ;
+- `markdown-it` sans vue de présentation ;
+- `init_rustls` sans besoin TLS réel ;
+- package JS tracing déclaré mais inutilisé.
+
+## Audit dépendances actuelles
+
+Versions candidates vérifiées le 2026-08-16 depuis les sources officielles :
+
+```text
+tauri                          2.11.5
+tauri-build                    2.6.3
+tauri-plugin-tracing           0.3.4
+ts-rs                           12.0.1
+fs2                              0.4.3
+@tauri-apps/api                 2.11.1
+@tauri-apps/cli                 2.11.4
+vite                             8.2.1
+typescript                       7.0.2
+sass-embedded                    1.102.0
+bootstrap                        5.3.8
+@fortawesome/fontawesome-free    7.3.1
+```
+
+Elles seront revérifiées lors de leur ajout réel. `pre.001` n'ajoute rien par anticipation.
+
+## Décision tracing Tauri
+
+`tauri-plugin-tracing 0.3.4` ne pose pas de subscriber global par défaut ; KSP utilisera donc le plugin Rust **sans** `with_default_subscriber()`. `ksp-logging-lib` reste l'unique propriétaire du subscriber/runtime global.
+
+L'audit source du plugin montre que sa commande frontend `log` émet actuellement avec un target vide. Cela est incompatible avec la politique de targets `ksp-*` de `ksp-logging-lib`.
+
+Décision :
+
+- plugin Rust intégré à la frontière Tauri ;
+- pas de `tauri-plugin-log` ;
+- pas de second subscriber ;
+- pas d'assouplissement de Logging pour accepter le target vide ;
+- pas de package JS tracing tant qu'un adapter réellement compatible `ksp-*` n'existe pas ;
+- probes Logging de `0.1.4` émis par la façade `ksp-logging-lib` avec target KSP contrôlé.
+
+## Architecture décidée
+
+La future crate :
+
+```text
+crates/ksp-app-config-desk
+```
+
+sera :
+
+- mixte `lib` + `bin` ;
+- monofenêtre fonctionnelle (`main`) + splash ;
+- Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome ;
+- sans framework frontend ;
+- sans vue de présentation ;
+- sans `PRESENTATION.md` ni `markdown-it` ;
+- avec toutes les commandes `#[tauri::command]` dans `tauri.rs` ;
+- avec services Rust séparés pour Config/Environment/Logging/Secrets ;
+- avec modules `tw_main.rs` et `tw_splash.rs` ;
+- avec DTO ordinaires séparés des DTO de reveal Secret.
+
+## Ownership Logging
+
+L'état cible conserve :
+
+```text
+ConfigManagement
+Mutex<LoggingRuntimeState>
+    ├── LoggingGuard
+    ├── active_profile_id
+    └── generation
+```
+
+La sauvegarde du document et l'application d'un profil sont deux actions distinctes. Un reload échoué ne modifie pas les métadonnées runtime et doit laisser le guard/runtime précédent valide.
+
+## Sécurité secrets
+
+Le reveal est une action séparée et explicitement confirmée. `0.1.4` protège avant tout contre la divulgation accidentelle : pas de secret réel dans snapshots/DTO généraux/logs/diagnostics/state persistant.
+
+Aucune ré-authentification biométrique/keychain ou mot de passe maison n'est ajoutée. La session desktop locale constitue l'identité de base ; le reveal est une autorisation applicative explicite et transitoire.
+
+## Splash
+
+`0.1.4` établira la référence commune KSP sans créer prématurément une crate Tauri partagée avec un seul consumer.
+
+Les noms exacts des variables Config/.env de timing seront fixés dans la tranche qui implémente le splash. Elles respecteront `KSP_*`/`KSP_PUBLIC_*` et seront ajoutées à `.env.example` dans le même delta que leur première utilisation.
+
+## Présentation
+
+Décision : aucune vue de présentation dans `0.1.4`.
+
+Donc :
+
+```text
+PRESENTATION.md absent
+markdown-it absent
+README.md jamais chargé dans une webview
+```
+
+## Extensibilité
+
+Le shell Documents doit découvrir les documents depuis le registre Config. Logging est le premier éditeur spécialisé lié à `cfg.std.logging`, mais le mécanisme shell/diagnostic/source reste générique.
+
+Un futur `file_id` pourra ajouter son adapter/panneau spécialisé sans dupliquer parsing, validation ou persistence Config.
+
+## Prévision souple
+
+Le plan fixe l'ordre candidat suivant :
+
+```text
+pre.001  audit + plan
+pre.002  extensions Config nécessaires au desktop
+pre.003  squelette Tauri/frontend + single-instance + tracing plugin
+pre.004  bootstrap/AppState/LoggingGuard/errors
+pre.005  shell + splash configurable
+pre.006  documents/diagnostics/réparation
+pre.007  profils/provenance
+pre.008  environnement/.env/shadow
+pre.009  reveal secrets
+pre.010  Logging editor contrats
+pre.011  opérations profils + persistence
+pre.012  apply/hot reload/probe
+pre.013  matrice fonctionnelle Logging
+pre.014  robustesse/extensibilité/audits desktop
+pre.015  clôture/docs/validations/prompt suivant
+```
+
+Chaque tranche vise environ 15–20 minutes de travail effectif et peut être scindée.
+
+## Fichiers ajoutés
+
+```text
+docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
+deltas/0.1.4/pre.001.md
+```
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+docs/000-README.md
+docs/plans/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+ROADMAP.md
+```
+
+## Fichiers supprimés
+
+Aucun.
+
+## Validations exécutées
+
+- audit statique de l'archive KSP `0.1.3` ;
+- audit ciblé de `ksp-config-lib` : registre, document engine, management, environment, logging adapter et error codes ;
+- audit ciblé de `ksp-logging-lib` : `LoggingGuard`, `initialize`, `reinitialize`, target filters ;
+- audit de l'archive bot3 Tauri : Cargo lib/bin, `main.rs`, `tauri.rs`, AppState, splash, Vite, TypeScript, SCSS et package frontend ;
+- vérification web des versions actuelles des dépendances candidates depuis crates.io/npm/Tauri/Vite et du comportement actuel de `tauri-plugin-tracing` ;
+- contrôle documentaire final de la livraison et de l'archive d'échange.
+
+## Validations non exécutées
+
+Aucune source Rust applicative n'est ajoutée ou modifiée dans ce delta.
+
+Le sandbox de préparation ne fournit pas le binaire `cargo`. Les validations Cargo suivantes n'ont donc pas pu être exécutées ici :
+
+```text
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+```
+
+Le `Cargo.toml` modifié est néanmoins validé syntaxiquement par le parseur TOML disponible dans le sandbox. Les commandes Cargo devront être exécutées sur le poste de développement avant commit/validation définitive de `pre.001`.
+
+## Décisions prises
+
+- première application Tauri = référence KSP, mais pas duplication de logique Config ;
+- deux petites extensions Config précèdent l'UI ;
+- shell monofenêtre + splash ;
+- Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome ;
+- aucune présentation/markdown-it ;
+- `tauri.rs` frontière unique des commandes ;
+- `LoggingGuard` durable dans AppState ;
+- save Logging séparé de apply ;
+- probe Logging contrôlé ;
+- reveal Secret séparé/transitoire ;
+- pas de `tauri-plugin-log` ;
+- plugin tracing sans subscriber propre ;
+- pas de JS tracing tant que le target vide du plugin reste incompatible avec `ksp-*` ;
+- splash configurable via Config/.env, variables nommées lors de l'implémentation ;
+- extensibilité fondée sur le registre Config + éditeurs spécialisés par `file_id`.
+
+## Questions ouvertes
+
+Aucune question ne bloque `pre.002` après validation du plan par l'utilisateur.
+
+Les détails reportés à leur tranche sont listés dans le plan : nom final des nouvelles APIs Config, nom des variables splash, features Cargo minimales et forme exacte du fallback Logging de réparation au démarrage.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Documentation KSP
 
@@ -37,7 +37,8 @@ docs/
 │   ├── 002-FUNCTIONAL_RELEASE_SEQUENCE.md
 │   ├── 003-V0_1_1_CORE_FOUNDATION_PLAN.md
 │   ├── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
-│   └── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
+│   ├── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
+│   └── 006-V0_1_4_CONFIG_DESKTOP_PLAN.md
 └── rules/
     ├── FILE_CONTRACTS.md
     ├── PROMPT_STRUCTURE.md
@@ -54,7 +55,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 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).
+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 release active `0.1.4 — ksp-app-config-desk` est ouverte par `pre.001` et son plan détaillé est [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md) ; son prompt d'ouverture reste [`../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.
 

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 23 -->
+<!-- version: 24 -->
 
 # Plans KSP
 
@@ -14,6 +14,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 - [`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 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`.
+- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan actif de `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` avant toute implémentation Tauri fonctionnelle.
 
 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: 21 -->
+<!-- version: 22 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -253,7 +253,11 @@ rel.001                  publication stable validée de 0.1.3
 
 ## `0.1.4` — Config desktop par défaut
 
-La décision `0.1.3-pre.001` conserve cette release comme étape suivante par défaut.
+`0.1.4-pre.001` ouvre désormais cette release par l'audit et le plan détaillé :
+
+```text
+docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
+```
 
 Mission :
 
@@ -265,17 +269,26 @@ ksp-app-config-desk
 
 L'application doit valider réellement :
 
-- lecture de documents ;
+- inventaire des documents Config enregistrés ;
-- profils/default profile ;
+- diagnostics JSON/schema/sémantiques/effective ;
-- résolution ;
+- inspection puis réparation validée d'un source invalide ;
-- validation ;
+- profils/default profile et provenance ;
-- édition/sauvegarde ;
+- environnement desired/effective/shadow ;
-- env overrides exposables ;
+- mutation `.env` exclusivement via Config ;
-- diagnostics/errors ;
+- reveal Secret explicitement privilégié et séparé ;
-- intégration logging ;
+- édition typée de plusieurs profils Logging ;
-- conventions Tauri/DTO/TS-RS.
+- profil mono-fichier ;
+- profil multi-fichiers avec console ;
+- sauvegarde séparée de l'activation runtime ;
+- hot reload Logging observable sans redémarrage ;
+- conservation du runtime précédent lorsqu'un reload échoue ;
+- conventions Tauri/DTO/TS-RS servant de référence aux futures apps KSP.
 
-La logique Config reste dans `ksp-config-lib`.
+L'audit `pre.001` révèle deux extensions bornées à apporter d'abord à `ksp-config-lib` : une vue publique des descripteurs du registre et une frontière de sauvegarde d'un source candidat qui reste entièrement parsé, validé et persisté atomiquement par Config. L'application ne doit pas contourner ces manques par une liste parallèle de `file_id` ou par du filesystem direct.
+
+Le shell retenu est une fenêtre principale de management plus splash, avec Vanilla TypeScript/Vite/SCSS/Bootstrap/Font Awesome. Aucune vue de présentation n'est retenue en `0.1.4`, donc aucun `PRESENTATION.md` ni `markdown-it` n'est prévu.
+
+La logique Config reste dans `ksp-config-lib` et le subscriber/runtime `tracing` reste dans `ksp-logging-lib`.
 
 # Règle Git à partir de `0.1.x`