v0.1.4-pre.015-fix.002

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 28 -->
+<!-- version: 29 -->
 
 # Règles spécifiques à KSP
 
@@ -225,6 +225,7 @@
 - **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.
 
 ## Data plane / control plane