v0.1.4-pre.018-fix.001

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 29 -->
+<!-- version: 30 -->
 
 # Règles spécifiques à KSP
 
@@ -226,6 +226,7 @@
 - **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, un contrôle frontend standalone (`npm run check` ou équivalent) ne construit pas le bundle de production : il se limite au type-check/lint/tests frontend nécessaires. Le build frontend de production appartient au hook Tauri `beforeBuildCommand`. Dans une séquence de validation, `cargo tauri build -c crates/<app>/tauri.conf.json` est exécuté **en dernière opération**, uniquement après `fmt/check/clippy`, les tests, les contrôles frontend standalone et le parcours fonctionnel `cargo tauri dev`.
 
 ## Data plane / control plane