# Utilisation de `ksp-app-config-desk` ## État actuel Le gabarit Rust/Tauri et le frontend Vite/TypeScript/SCSS sont présents. Le backend initialise désormais Config, le runtime Logging et `AppState`; les panneaux métier Config restent volontairement absents à ce stade. 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. ## Première installation des dépendances frontend Depuis : ```text crates/ksp-app-config-desk ``` installer les dépendances déclarées avec la commande de gestion prévue par le projet : ```bash npm i -D cd ../../ ``` `npm i -D` sans nom de package installe les dépendances déclarées du package ; la classification `dependencies` / `devDependencies` reste celle de `package.json`. Les lockfiles frontend restent ignorés et ne sont pas versionnés. Après cette installation, les commandes Cargo/Tauri sont exécutées depuis la racine du workspace. ## Développement normal Le frontend n'est pas lancé directement avec npm. KSP est un workspace Rust multi-app : depuis la racine du workspace, la configuration Tauri de l'application doit être sélectionnée explicitement : ```bash cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json ``` 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. Depuis la racine du workspace : ```bash cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json ``` `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. ## Bootstrap backend Les arguments `--cfgpath`, `--schemapath` et `--filemap=...` sont transmis tels quels à `ksp-config-lib`. Le profil Logging initial est le `default_profile` de `std.logging.json`. Si cette configuration ne peut pas être utilisée, l'application doit rester démarrable pour permettre sa réparation : elle utilise alors un fallback Logging console/stderr en mémoire. Le fallback n'écrit aucun fichier de configuration et n'écrase aucune valeur utilisateur. La commande Tauri `get_app_snapshot` expose un état sûr du bootstrap. Ses types TypeScript sont générés par `cargo test -p ksp-app-config-desk` sous `frontend/ts/bindings/`. ## Asset font du splash La police bot3 de référence est `DOS_Amazigh.ttf`. Vérifier l'asset local contre l'empreinte documentée dans `frontend/fonts/README.md` avant la tranche de finition du splash.