v0.1.3-pre.015-fix.001

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 19 -->
+<!-- version: 21 -->
 
 # Règles spécifiques à KSP
 
@@ -200,6 +200,17 @@
 - **KSP-APP-005** — Les applications spécialisées précèdent toute future application globale ; aucune app globale n'est un livrable actuel.
 - **KSP-APP-006** — Une app manager worker utilise le control plane et ne modifie pas directement l'état interne de processing du worker en base.
 - **KSP-APP-007** — Une future application globale est conservée comme idée produit et sera cadrée seulement après validation suffisante des apps spécialisées/demos.
+- **KSP-APP-008** — `ksp-app-config-desk` est l'application desktop de référence destinée à établir le gabarit des futures applications Tauri KSP. Les applications suivantes réutilisent ce gabarit sauf justification explicite documentée.
+- **KSP-APP-009** — Le gabarit desktop KSP réutilise/refond les éléments éprouvés de khadhroony-bot3 : organisation SASS/SCSS, dépendances frontend utiles, gabarit visuel initial, icône de base et fichiers de build TypeScript/Vite similaires. Cette référence est auditée et adaptée ; elle n'est pas copiée aveuglément.
+- **KSP-APP-010** — Une application Tauri KSP est un package Rust mixte avec cible bibliothèque et cible binaire de noms distincts. Le binaire reste un launcher mince.
+- **KSP-APP-011** — `main.rs` d'une application Tauri appelle essentiellement la fonction publique `run` de la bibliothèque applicative ; il porte uniquement le bootstrap strictement exécutable, notamment le verrou single-instance et les arguments CLI lorsqu'ils sont nécessaires.
+- **KSP-APP-012** — `lib.rs` d'une application Tauri reste un point de déclaration de modules et de réexport des fonctions/contrats nécessaires ; la logique des fenêtres et opérations n'y est pas accumulée.
+- **KSP-APP-013** — `tauri.rs` possède la fonction `run`, les wrappers `#[tauri::command]` vers les fonctions déclarées dans leurs modules, ainsi que les helpers Tauri/démarrage communs lorsqu'ils sont réellement partagés (`init_rustls`, `open_or_focus_window`, etc.). Les annotations `#[tauri::command]` ne sont pas dispersées dans les modules métier/fenêtre.
+- **KSP-APP-014** — Les modules propres à une fenêtre Tauri utilisent le préfixe `tw_` (`Tauri window`) sauf convention équivalente explicitement décidée avant implémentation. Les helpers réutilisables entre fenêtres sont regroupés dans des modules communs au lieu d'être dupliqués.
+- **KSP-APP-015** — Toutes les applications Tauri KSP réutilisent un splashscreen commun et son lifecycle de démarrage. Les paramètres de temporisation du splashscreen sont configurables via Config/.env, jamais codés en dur dans chaque application.
+- **KSP-APP-016** — Toute variable d'environnement introduite pour le splashscreen ou une autre capacité desktop respecte les namespaces KSP/KSPB et est ajoutée à `.env.example`, avec commentaire, dans le même delta que sa première utilisation runtime conformément à `KSP-CONFIG-005/006`.
+- **KSP-APP-017** — Le `README.md` d'une application Tauri documente le package et ne sert jamais de source Markdown chargée dans une fenêtre de présentation. Lorsqu'une application affiche une présentation embarquée, le contenu UI appartient à un fichier dédié `PRESENTATION.md`; `markdown-it` est la référence de rendu issue de khadhroony-bot3 lorsque ce besoin existe et sa version est auditée avant ajout.
+- **KSP-APP-018** — `PRESENTATION.md` est optionnel : une application monofenêtre qui ne possède aucune vue de présentation n'en crée pas. Lorsqu'il existe, il contient du contenu Markdown statique destiné à l'UI et aucun lien navigable Markdown ou HTML (`[texte](...)`, `<a ...>`, URL brute destinée à la navigation) susceptible de détourner ou casser le comportement des fenêtres Tauri.
 
 ## Data plane / control plane
 
@@ -219,3 +230,10 @@
 - **KSP-REL-006** — Une release ou prerelease trop grosse est scindée plutôt que compressée pour respecter un numéro prévu.
 - **KSP-REL-007** — La dernière prerelease d'une release fonctionnelle réalise par défaut validations finales, documentation, nettoyage/archivage, changelog et prompt de la release suivante.
 - **KSP-REL-008** — La première release fonctionnelle sélectionnée est `0.1.1`, dédiée à la stabilisation de `ksp-core-lib`.
+- **KSP-REL-009** — Après toute modification d'un fichier Rust, la tranche concernée exécute avant livraison au minimum `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets`. Une commande non exécutée n'est jamais déclarée réussie.
+- **KSP-REL-010** — Pendant le développement courant d'une crate, les tests Rust privilégient la portée ciblée `cargo test -p <crate>` et, si utile, ses tests d'intégration nommés. `cargo test --workspace` est conservé pour l'ouverture ou la fermeture d'une session/version et pour les validations globales explicitement justifiées.
+- **KSP-REL-011** — Les validations d'une crate incluent les audits `cargo tree` pertinents pour son graphe réel : arbre normal, doublons et features lorsque ces vues apportent une information utile. Les crates fondamentales/complétées conservent leurs canaries de dépendances.
+- **KSP-REL-012** — Toute crate ou composant KSP considéré comme complété possède un `README.md` descriptif durable avant clôture de sa release.
+- **KSP-REL-013** — Toute bibliothèque KSP considérée comme complétée possède un `USAGE.md` durable, sans notes de version, présentant sa surface publique et un exemple d'utilisation pour chaque API publique destinée à être consommée directement ; plusieurs APIs étroitement liées peuvent partager un même exemple lorsque leur usage réel est composé. Les changements de release appartiennent au changelog/delta, pas au guide d'utilisation.
+- **KSP-REL-014** — Toute application/binaire Tauri KSP considéré comme complété possède un `USAGE.md` durable décrivant ses fenêtres, leurs objectifs, leurs flux principaux et leur utilisation opérateur.
+- **KSP-REL-015** — Une application Tauri complétée ne crée `PRESENTATION.md` que si elle possède réellement une vue de présentation embarquée ; dans ce cas le fichier est finalisé comme contenu UI sans liens navigables et reste distinct du `README.md` et du `USAGE.md`.