v0.2.6-pre.014

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 36 -->
+<!-- version: 37 -->
 
 # Règles spécifiques à KSP
 
@@ -224,15 +224,15 @@
 - **KSP-APP-023** — Le gabarit Tauri KSP place les sources web sous `frontend/`, les modules TypeScript sous `frontend/ts/`, les styles SCSS sous `frontend/sass/` et les bindings TS-RS générés sous `frontend/ts/bindings/`. Les bindings et artefacts générés ne sont pas versionnés ; les DTO Rust applicatifs restent la source des contrats TS-RS.
 - **KSP-APP-024** — Chaque application desk Tauri KSP possède un couple de ports Vite/HMR exclusif. L'allocation commence à `1430/1431` pour `ksp-app-config-desk` puis progresse par paires (`1432/1433`, `1434/1435`, etc.). Le port Vite est strict afin qu'une collision échoue explicitement au lieu de sélectionner silencieusement un autre port.
 - **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-026** — Dans un workspace Rust multi-app, `-c/--config` de Tauri est un overlay de configuration et ne sélectionne pas la crate applicative. Les commandes Tauri sont donc exécutées depuis le répertoire de la crate ciblée : `(cd crates/<app> && cargo tauri dev)` ou `(cd crates/<app> && cargo tauri build)`. Le lancement depuis la racine avec `-c crates/<app>/tauri.conf.json` est interdit comme sélecteur d’application.
 - **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.
+- **KSP-APP-029** — En développement workspace, Tauri est lancé depuis `crates/<app>` conformément à `KSP-APP-026`. Le processus Rust peut ensuite normaliser son current working directory vers la racine du workspace avant le bootstrap Config lorsque les chemins de développement KSP y sont enracinés. 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 runtime distribué ne doit pas dépendre d’un checkout source.
 - **KSP-APP-030** — Lorsqu’une application KSP persiste des logs applicatifs, chaque lancement doit disposer d’un fichier propre et non partagé avec un lancement précédent. Le nom encode au minimum l’identité applicative et un horodatage de démarrage, par exemple `app-name.YYYYMMDD-HHMMSS.log` / `.json` / `.jsonl` selon le format du sink ; une rotation quotidienne ne doit pas fusionner plusieurs exécutions applicatives dans le même fichier.
 - **KSP-APP-031** — Le niveau de logging spécifique à une application/crate peut être élevé temporairement à `debug` ou `trace` pendant une phase de développement ou correction. Avant la clôture/release de cette application/crate, son niveau de référence est ramené à `info` ou `warn` selon le besoin opératoire ; il n’est remonté que lorsqu’un développement/correctif est explicitement rouvert.
 - **KSP-APP-032** — Les interfaces desk KSP n’utilisent pas les dialogues bloquants natifs du navigateur (`window.alert`, `window.confirm`, `window.prompt`) pour les interactions applicatives normales. Les confirmations destructives ou privilégiées utilisent un modal Bootstrap intégré à l’UI, instrumenté par le bridge Logging ; toute exception doit être explicitement justifiée et documentée.
 - **KSP-APP-033** — Un test d’une application ou d’un manager qui peut modifier un document Config du workspace ne traite jamais les valeurs courantes de ce document comme une fixture immuable. Les tests de valeurs exactes utilisent une fixture isolée ; les tests qui lisent la Config workspace vérifient uniquement des invariants, la validité et la cohérence source → résolution → runtime afin de rester valides après une édition légitime par Config Desk.
-- **KSP-APP-034** — Pour une application Tauri KSP, npm n'est jamais invoqué directement pour lancer les scripts applicatifs de développement, contrôle ou build. Conformément à `KSP-APP-025`, les seules commandes npm directes sont celles nécessaires à l'installation ou à la mise à jour des dépendances déclarées dans `package.json` (`npm i -D` lors de l'installation initiale retenue par le gabarit, ou `npm update` lors d'une mise à jour). Le cycle applicatif passe par `cargo tauri dev -c crates/<app>/tauri.conf.json` et `cargo tauri build -c crates/<app>/tauri.conf.json`; Tauri déclenche lui-même les scripts configurés via `beforeDevCommand` et `beforeBuildCommand`. Dans une séquence de validation finale, `cargo tauri build -c crates/<app>/tauri.conf.json` est exécuté **en toute dernière opération**, après `fmt/check/clippy`, les tests et le parcours fonctionnel `cargo tauri dev`.
+- **KSP-APP-034** — Pour une application Tauri KSP, npm n’est jamais invoqué directement pour lancer les scripts applicatifs de développement, contrôle ou build. Les seules commandes npm directes servent à installer ou mettre à jour les dépendances déclarées. Le cycle applicatif est crate-local : `(cd crates/<app> && cargo tauri dev)` et `(cd crates/<app> && cargo tauri build)` ; Tauri déclenche lui-même les hooks `beforeDevCommand` / `beforeBuildCommand`, dont le `cwd` reste explicitement la crate. Dans une validation finale, le `cargo tauri build` crate-local est exécuté **en toute dernière opération**, après fmt/audit/check/clippy, tests et parcours fonctionnel.
 
 ## Data plane / control plane