v0.1.4-pre.005

crates/ksp-app-config-desk/USAGE.md

@@ -1,34 +1,81 @@
 <!-- file: crates/ksp-app-config-desk/USAGE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Utilisation de `ksp-app-config-desk`
 
 ## État actuel
 
-La tranche `0.1.4-pre.004` introduit le squelette Rust/Tauri uniquement. Les fenêtres frontend ne deviennent exécutables qu'après l'ajout du gabarit Vite/TypeScript prévu par la tranche suivante.
+Le gabarit Rust/Tauri et le frontend Vite/TypeScript/SCSS sont maintenant présents. Les panneaux métier Config restent volontairement absents à ce stade.
 
-## Entrée binaire
+La fenêtre `splash` est la fenêtre visible au démarrage. La fenêtre `main` est déjà construite et bundlée, mais son lifecycle d'affichage est finalisé dans la tranche splash/shell dédiée afin de ne pas introduire une temporisation codée en dur.
 
-Le binaire `ksp-app-config-desk` :
+## Première installation des dépendances frontend
 
-1. acquiert un verrou single-instance dans le répertoire temporaire du système ;
-2. collecte les arguments de processus sans lire directement de variable `KSP_*`/`KSPB_*` ;
-3. appelle `ksp_app_config_desk_lib::run()` ;
-4. convertit explicitement le résultat en `ExitCode`.
+Depuis :
 
-Les arguments Config `--cfgpath`, `--schemapath` et `--filemap` seront consommés par les APIs `ksp-config-lib` dans la tranche de bootstrap applicatif prévue plus loin ; le binaire ne doit pas en réimplémenter le parsing.
+```text
+crates/ksp-app-config-desk
+```
 
-## Fenêtres réservées
+installer les dépendances déclarées avec la commande de gestion prévue par le projet :
 
-Deux fenêtres sont déjà déclarées dans `tauri.conf.json` :
+```bash
+npm i -D
+```
 
-- `splash` : lifecycle de démarrage commun ;
-- `main` : shell de management Config.
+Les lockfiles frontend restent ignorés et ne sont pas versionnés.
 
-Leur contenu HTML/TypeScript est ajouté avec le gabarit frontend.
+## Développement normal
 
-## Développement frontend
+Le frontend n'est pas lancé directement avec npm. Depuis la crate ou avec le package explicitement sélectionné selon l'environnement Cargo/Tauri, utiliser le cycle Tauri habituel :
 
-Le cycle normal utilisera `cargo tauri dev`. Tauri déclenchera alors `npm run dev` via `beforeDevCommand` et chargera le serveur Vite sur le port `1430`.
+```bash
+cargo tauri dev
+```
 
-Les commandes npm directes sont réservées à la gestion des dépendances (`npm i -D ...` selon la politique du projet), et non au lancement quotidien de l'application.
+Tauri exécute alors le hook :
+
+```text
+npm run dev
+```
+
+Vite écoute strictement sur :
+
+```text
+HTTP : 1430
+WS   : 1431
+```
+
+Si le port HTTP est déjà occupé, le démarrage doit échouer au lieu de sélectionner silencieusement un autre port.
+
+## Build frontend
+
+Le build de l'application passe également par Tauri. `beforeBuildCommand` déclenche :
+
+```text
+npm run build
+```
+
+Vite construit les pages `main.html` et `splash.html` vers :
+
+```text
+../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+```
+
+Cette destination est résolue depuis la racine de la crate dans `vite.config.ts` et correspond au `frontendDist` de `tauri.conf.json`.
+
+## Tracing desktop
+
+`tauri-plugin-tracing` est enregistré côté Rust et la capability contient `tracing:default`. Le package frontend associé est installé avec le gabarit.
+
+Cette tranche n'utilise pas encore le bridge JavaScript pour émettre les logs KSP applicatifs : `frontend_log.ts`, les targets KSP whitelistés et la commande `emit_frontend_log` sont introduits dans la tranche dédiée après initialisation de `ksp-logging-lib`.
+
+## Bindings TS-RS
+
+Le layout cible est :
+
+```text
+frontend/ts/bindings/ksp_app_config_desk/...
+```
+
+Les bindings sont générés au premier DTO Tauri réel ; aucune structure factice n'est ajoutée uniquement pour créer le répertoire.