v0.1.4-pre.004

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 22 -->
+<!-- version: 23 -->
 
 # Règles spécifiques à KSP
 
@@ -214,6 +214,10 @@
 - **KSP-APP-019** — Les applications Tauri KSP utilisent l'écosystème `tracing` à leur frontière desktop via le plugin Tauri de tracing retenu (`tauri-plugin-tracing` ou successeur explicitement validé) et des adapters similaires au modèle éprouvé de khadhroony-bot3. Elles n'utilisent pas `tauri-plugin-log` ni la façade `log`, sauf décision architecturale future explicite qui remplacerait cette règle. L'application ne configure pas directement `tracing-subscriber`/`tracing-appender` : `ksp-logging-lib` reste propriétaire du runtime Logging, le plugin Tauri servant d'adapter d'intégration desktop.
 - **KSP-APP-020** — La première version de `ksp-app-config-desk` n'est clôturable que si l'UI permet de créer, modifier, sauvegarder et sélectionner plusieurs profils Logging, dont au minimum un profil mono-fichier et un profil multi-fichiers avec sorties séparées plus sortie logiciel/console, puis de recharger à chaud la configuration Logging et de constater effectivement le nouveau routage sans redémarrage de l'application.
 - **KSP-APP-021** — `ksp-app-config-desk` est conçu comme un gestionnaire Config extensible : la première version peut fournir un éditeur Logging typé, mais son architecture/navigation/état ne doit pas figer l'application sur `std.logging.json`. De futurs `file_id`, schemas et éditeurs spécialisés doivent pouvoir être ajoutés sans déplacer la propriété des documents, de leur validation ou de leur persistence hors de `ksp-config-lib`.
+- **KSP-APP-022** — La construction d'un `tauri::Builder` KSP reste progressive et lisible : une variable builder est configurée/réassignée par étapes courtes ou helpers ciblés plutôt qu'au moyen d'une longue chaîne monolithique, afin qu'un plugin, state, setup ou groupe de commandes puisse être désactivé sans restructurer l'ensemble du runtime.
+- **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** — npm est utilisé directement pour installer ou mettre à jour les dépendances frontend (`npm i -D ...`). Le cycle normal de développement/build d'une application Tauri passe par les commandes Tauri, qui déclenchent les scripts npm configurés via `beforeDevCommand`/`beforeBuildCommand`; les lockfiles frontend restent non versionnés.
 
 ## Data plane / control plane