v0.1.4-pre.008-fix.002

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Plan `0.1.4` — `ksp-app-config-desk`
 
@@ -316,7 +316,8 @@ Décision `0.1.4` :
 - reprendre/refondre le pont `frontend_logging` de bot3 : helpers TypeScript -> commande Tauri dédiée -> service Rust -> façade `ksp-logging-lib` ;
 - normaliser/whitelister les targets frontend et de test côté Rust afin qu'un texte arbitraire reçu depuis la webview ne devienne jamais un target de callsite arbitraire ;
 - utiliser le package officiel pour les fonctions réellement utiles du plugin (`attachConsole` ou autre) uniquement lorsque leur comportement reste compatible avec le runtime KSP ;
-- ne pas utiliser directement `interceptConsole()` / `takeoverConsole()` comme unique pont JS -> Rust si cela produit des événements impossibles à router selon les targets KSP ;
+- le bridge KSP actuel couvre WebView -> Rust et conserve les appels JavaScript dans la console WebKit, mais ne couvre pas encore Rust -> WebKit ; avec le subscriber custom de KSP, `attachConsole()` requiert une `tauri_plugin_tracing::WebviewLayer` intégrée au subscriber possédé par `ksp-logging-lib` ; cette capacité sera ajoutée seulement via un adapter qui préserve cet ownership ;
+- ne pas utiliser directement `interceptConsole()` / `takeoverConsole()` comme unique pont JS -> Rust si cela produit des événements impossibles à router selon les targets KSP ou une boucle/double émission avec le bridge KSP ;
 - pour les événements de test Logging de `0.1.4`, utiliser la façade/macros de `ksp-logging-lib` avec un target KSP contrôlé et un `domain` structuré optionnel ;
 - revérifier ce point lors de l'introduction réelle des dépendances, car une nouvelle version du plugin pourrait étendre son contrat frontend.
 
@@ -950,7 +951,15 @@ KSP_DESK_SPLASH_FADE_MS=300
 
 Elles sont résolues uniquement via `ConfigEnvironment` avec priorité process > `.env` > fallback. `KSP_DESK_SPLASH_MINIMUM_MS` est bornée à 60 000 ms et `KSP_DESK_SPLASH_FADE_MS` à 10 000 ms. Une valeur invalide ne doit pas rendre Config Desk inutilisable : l’application conserve les timings de fallback en mémoire, journalise seulement domaine/code de l’erreur et laisse la future surface `.env` permettre la réparation.
 
-Le frontend ne reçoit que la durée d’animation réellement nécessaire dans les ordres du splash; la durée minimale reste backend. Aucun close delay distinct n’est nécessaire : Rust attend la durée de fade-out avant d’afficher/focaliser `main` puis de détruire `splash`. Les variables sont ajoutées à `.env.example` dans `pre.008`.
+Le frontend ne reçoit que la durée d’animation réellement nécessaire dans les ordres du splash; la durée minimale reste backend. La référence temporelle est la readiness frontend : Rust émet `fade_in`, attend `minimum`, émet `fade_out`, attend `fade`, puis affiche/focalise `main` et détruit `splash`. Aucun close delay distinct n’est nécessaire. Avec `minimum=12000` et `fade=3000`, le lifecycle backend attendu est donc proche de `15000 ms`, et non des trois délais indépendants historiques de bot3. `tw_splash` journalise en `debug` la provenance des valeurs, les attentes configurées et réellement observées ainsi que la durée totale. Les variables sont ajoutées à `.env.example` dans `pre.008`.
+
+### 13.3 Racine runtime en développement
+
+Avec le workflow workspace `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json`, Tauri peut lancer le binaire Rust avec la crate applicative comme current working directory. Les defaults Config `config/`, `config/schemas/` et `.env` sont cependant des chemins de projet enracinés à la racine du workspace. En build debug, le launcher replace donc le CWD sur `env!("CARGO_MANIFEST_DIR")/../..` **avant** le bootstrap Config. Il ne lit aucune ressource KSP lui-même ; `ksp-config-lib` continue à gérer paths, `.env`, precedence et validation. Un runtime distribué ne doit pas dépendre de cette racine source et sera cadré séparément.
+
+### 13.4 Header et navigation
+
+Le logo de Config Desk porte déjà l’identité graphique KSP. Le header ne répète donc pas `KSP` en texte : il suit `Config Desk — <vue active>`. Les cinq commandes principales restent des tabs/pills alignées à droite tant que leur nombre reste compact ; les futures applications qui dépassent cette surface utiliseront un dropdown. Les clics/changements de tabs sont tracés (`trace` pour le clic/état technique, `debug` pour l’activation utilisateur significative).
 
 ## 14. Présentation et Markdown
 
@@ -1182,9 +1191,10 @@ pre.008  shell main + splash de référence
          - tw_splash + tw_main
          - lifecycle splash configurable
          - KSP_DESK_SPLASH_MINIMUM_MS / KSP_DESK_SPLASH_FADE_MS + .env.example
-         - navigation monofenêtre
+         - normalisation du CWD debug vers la racine workspace avant bootstrap Config
+         - navigation monofenêtre + header `Config Desk — <vue>`
          - helpers show/focus/destroy
-         - instrumentation debug/trace des interactions et mutations frontend
+         - instrumentation debug/trace des interactions, tabs et timings splash
 
 pre.009  Documents + diagnostics
          - inventaire générique par registre
@@ -1419,6 +1429,6 @@ Aucune question n'empêche d'ouvrir le développement après validation du prés
 2. nom exact et nombre minimal de variables splash Config/.env ;
 3. features Cargo minimales de Tauri/Tokio nécessaires au shell/splash ;
 4. détails du fallback Logging minimal utilisé uniquement lorsque la Config Logging ne peut pas être résolue au démarrage ;
-5. usage exact des helpers console de `@fltsci/tauri-plugin-tracing` (`attachConsole`, `interceptConsole`, `takeoverConsole`) compatible avec le bridge KSP sans boucle/double émission ; si la version introduite permet un target JS namespacé `ksp-*`, l'adapter pourra être simplifié sans affaiblir Logging.
+5. implémentation exacte du retour Rust -> console WebKit : `attachConsole()` est retenu comme capacité candidate, mais seulement après intégration d'une `tauri_plugin_tracing::WebviewLayer` dans le subscriber possédé par `ksp-logging-lib`; `interceptConsole()`/`takeoverConsole()` ne doivent pas doubler le bridge JS -> Rust KSP ni réintroduire des targets non conformes.
 
 Ces points doivent être résolus par code/tests dans les prereleases prévues, pas par contournement applicatif.

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 25 -->
+<!-- version: 26 -->
 
 # Règles spécifiques à KSP
 
@@ -220,6 +220,8 @@
 - **KSP-APP-025** — Dans `package.json`, les bibliothèques consommées par le bundle applicatif appartiennent à `dependencies`; les outils de build/développement et paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Le cycle normal de développement/build passe par Tauri, qui déclenche les scripts npm configurés via `beforeDevCommand`/`beforeBuildCommand`; les lockfiles frontend restent non versionnés.
 - **KSP-APP-026** — KSP étant un workspace Rust multi-app, les commandes Tauri lancées depuis la racine sélectionnent explicitement la configuration de l'application avec `-c crates/<app>/tauri.conf.json` (par exemple `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json`). Après une installation npm effectuée depuis `crates/<app>`, l'opérateur revient à la racine du workspace avant le cycle Cargo/Tauri.
 - **KSP-APP-027** — Les applications Tauri KSP instrumentent systématiquement le comportement frontend via le bridge Logging commun : actions utilisateur et transitions d’état significatives en `debug`, événements techniques fins, rendu/remplacement de sections et étapes fréquentes en `trace`. Les chargements/rafraîchissements de données sont tracés au début et à la fin sans journaliser les payloads sensibles. Cette instrumentation doit permettre de reconstruire le déroulement frontend sans dépendre uniquement de l’état visuel.
+- **KSP-APP-028** — Le header d’une application desk ne répète pas inutilement l’identité déjà portée par son logo : il affiche le nom ou l’abréviation fonctionnelle de l’application, puis un tiret cadratin `—` et le titre de la vue active. Les commandes principales peu nombreuses peuvent utiliser des tabs/pills alignées à droite ; lorsque leur nombre nuit à la lisibilité ou à l’espace disponible, un dropdown est préféré.
+- **KSP-APP-029** — En développement workspace, une application desk Tauri normalise le current working directory du processus Rust vers la racine du workspace avant le bootstrap Config lorsque `cargo tauri ... -c crates/<app>/tauri.conf.json` lance le binaire depuis la crate. Cette adaptation ne lit ni ne parse directement `config/`, `.env` ou les variables `KSP_*`/`KSPB_*` : `ksp-config-lib` reste seul propriétaire de ces ressources. Le comportement de distribution/release reste défini séparément et ne doit pas dépendre d’un checkout source.
 
 ## Data plane / control plane