v0.2.6-pre.014

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: 26 -->
+<!-- version: 27 -->
 
 # Plan `0.1.4` — `ksp-app-config-desk`
 
@@ -233,7 +233,7 @@ Les artefacts frontend construits doivent être séparés des sources. Pour `ksp
 
 Cette valeur est utilisée par `build.frontendDist` dans `tauri.conf.json`. `vite.config.ts` utilise la même destination comme `build.outDir` depuis son introduction en `pre.005`. Elle remplace le `../dist`/`../../dist` historique du gabarit bot3.
 
-La gestion npm distingue le runtime frontend du tooling. Les bibliothèques consommées par le bundle appartiennent à `dependencies`; les outils de compilation/développement (`@tauri-apps/cli`, Vite, TypeScript, Sass) et les paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Pour la première installation, l'opérateur se place dans `crates/ksp-app-config-desk`, exécute `npm i -D`, puis revient à la racine avec `cd ../../`. Le cycle normal de développement et de build passe ensuite par Tauri depuis la racine du workspace, avec configuration explicite de l'application : `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json` et `cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json`. Tauri déclenche lui-même `npm run dev` / `npm run build` au travers des hooks configurés. Aucun lockfile npm n'est versionné.
+La gestion npm distingue le runtime frontend du tooling. Les bibliothèques consommées par le bundle appartiennent à `dependencies`; les outils de compilation/développement (`@tauri-apps/cli`, Vite, TypeScript, Sass) et les paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Pour la première installation, l'opérateur se place dans `crates/ksp-app-config-desk` et exécute `npm i -D`. Le cycle normal de développement et de build reste ensuite crate-local : `(cd crates/ksp-app-config-desk && cargo tauri dev)` et `(cd crates/ksp-app-config-desk && cargo tauri build)`. `-c/--config` n'est pas utilisé pour sélectionner l'application car Tauri le traite comme un overlay de configuration. Tauri déclenche lui-même `npm run dev` / `npm run build` au travers des hooks configurés. Aucun lockfile npm n'est versionné.
 
 Chaque application Tauri desk KSP reçoit un couple de ports Vite/HMR propre. La première application réserve :
 
@@ -944,24 +944,25 @@ fade duration
 close delay si techniquement distinct
 ```
 
-`pre.008` fige les deux clés communes nécessaires au lifecycle de référence :
+`0.2.6-pre.014` aligne les deux Desks sur trois clés communes, en reprenant la séparation fonctionnelle du splash kbot3 :
 
 ```text
+KSP_DESK_SPLASH_FADE_IN_MS=300
 KSP_DESK_SPLASH_MINIMUM_MS=1200
-KSP_DESK_SPLASH_FADE_MS=300
+KSP_DESK_SPLASH_FADE_OUT_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.
+Elles sont résolues uniquement via `ConfigEnvironment` avec priorité process > `.env` > fallback. `KSP_DESK_SPLASH_MINIMUM_MS` est bornée à 60 000 ms et chaque fade à 10 000 ms. Une valeur invalide ne rend pas Config Desk inutilisable : l’application conserve les timings de fallback en mémoire et journalise seulement domaine/code de l’erreur.
 
-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`.
+Le frontend reçoit uniquement les durées d’animation nécessaires dans les ordres du splash; la durée minimale reste backend. Après readiness frontend, Rust émet `fade_in`, attend `fade_in`, maintient la splash pleinement visible pendant `minimum`, émet `fade_out`, attend `fade_out`, puis affiche/focalise `main` et détruit `splash`. Avec `fade_in=3000`, `minimum=12000` et `fade_out=3000`, le lifecycle backend attendu est proche de `18000 ms`. Le splash possède en outre le flux de messages généraux en bas et le flux diagnostic debug en haut repris du comportement kbot3.
 
 ### 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.
+Avec le workflow crate-local `(cd crates/ksp-app-config-desk && cargo tauri dev)`, Tauri lance le projet applicatif attendu et le binaire Rust démarre 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).
+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 utilisent désormais des pills verticales dans une sidebar du contenu principal, alignées avec Wallet Desk ; le header conserve uniquement l'identité fonctionnelle et le titre de la vue active. 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
 
@@ -1029,7 +1030,7 @@ Le shell applicatif matérialise désormais cette architecture dans `frontend/ts
 
 Le bootstrap Logging sépare également la **résolution du plan de démarrage** de l'**installation du subscriber**. Une source invalide peut ainsi être testée comme plan fallback sans initialiser le subscriber global du binaire de tests.
 
-La validation frontend de `pre.018` utilise `npm run check` pour **`tsc --noEmit` uniquement**. Le build Vite de production n'est pas lancé séparément : `cargo tauri build` déclenche déjà `npm run build` via `beforeBuildCommand`. Pour KSP, le build Tauri est réservé à la **dernière validation**, après `fmt/check/clippy`, les tests, le type-check frontend et le parcours fonctionnel `tauri dev`.
+La convention desktop actuelle n’exécute plus de script npm de contrôle/dev/build directement côté opérateur. Tauri possède le cycle applicatif et déclenche `npm run dev` / `npm run build` via ses hooks crate-local. Le build Tauri reste réservé à la **dernière validation**, après `fmt/check/clippy`, les tests et le parcours fonctionnel `cargo tauri dev`.
 
 ## 16. Stratégie de tests
 
@@ -1200,7 +1201,7 @@ pre.007  frontend logging commun
 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
+         - KSP_DESK_SPLASH_FADE_IN_MS / KSP_DESK_SPLASH_MINIMUM_MS / KSP_DESK_SPLASH_FADE_OUT_MS + .env.example
          - normalisation du CWD debug vers la racine workspace avant bootstrap Config
          - navigation monofenêtre + header `Config Desk — <vue>`
          - helpers show/focus/destroy
@@ -1456,3 +1457,10 @@ Aucune question n'empêche d'ouvrir le développement après validation du prés
 5. retour Rust -> console WebKit : étudié à la clôture `pre.019` puis **reporté hors `0.1.4`**. Le bridge WebView -> Rust -> KSP et le panneau Test Logging couvrent le besoin fonctionnel de cette release. Une future réflexion Rust -> WebKit devra rester sous ownership de `ksp-logging-lib`, sans second subscriber, double émission ni boucle avec le bridge `console.*`.
 
 Ces points doivent être résolus par code/tests dans les prereleases prévues, pas par contournement applicatif.
+
+
+### Harmonisation desktop `0.2.6-pre.014`
+
+Le polish partagé avec Wallet Desk déplace les pills de navigation Config dans une sidebar verticale du contenu principal, tout en conservant la palette claire historique de Config Desk. Les quatre fichiers HTML des deux Desks utilisent les en-têtes normalisés `file/version`. Le splash reprend les flux kbot3 (messages généraux en bas, diagnostics debug en haut) avec trois timings Config-owned distincts `KSP_DESK_SPLASH_FADE_IN_MS`, `KSP_DESK_SPLASH_MINIMUM_MS` et `KSP_DESK_SPLASH_FADE_OUT_MS`.
+
+Le même chantier corrige le lancement Tauri multi-app : chaque app est lancée depuis sa crate, car `-c/--config` est un overlay et non un sélecteur de backend.