# 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 ├── 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.