v0.1.3-pre.015-fix.001

prompts/004-V0_1_4_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/004-V0_1_4_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->
 
 # Prompt de démarrage `0.1.4` — ksp-app-config-desk
 
@@ -99,7 +99,13 @@ L'application est une composition/interface. Elle ne devient pas propriétaire :
 - du mapping Logging ;
 - de la persistence Config.
 
-La structure sous `apps/` et l'intégration au workspace doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles.
+La crate applicative est placée directement sous :
+
+```text
+crates/ksp-app-config-desk
+```
+
+conformément au layout KSP. Son intégration au workspace et l'organisation interne frontend/Tauri doivent être confirmées dans le plan `pre.001` à partir des règles KSP actives et des contraintes Tauri actuelles.
 
 ## 5. Capacités desktop à valider
 
@@ -159,6 +165,42 @@ Conserver les règles KSP déjà retenues :
 
 Le `pre.001` doit vérifier les versions actuelles de Tauri et des dépendances frontend réellement nécessaires avant leur ajout. Les dépendances communes sont déclarées au niveau workspace lorsqu'elles sont partagées ; aucune dépendance n'est ajoutée sans usage immédiat.
 
+### 6.1 Gabarit Tauri de référence à établir
+
+`ksp-app-config-desk` doit servir de **modèle de référence** pour les futures applications Tauri KSP. `pre.001` doit auditer la base khadhroony-bot3 puis décider précisément ce qui est réutilisé/refondu, notamment :
+
+- organisation SASS/SCSS et dépendances frontend/package utiles ;
+- même gabarit visuel initial à affiner et même icône de base tant qu'aucune identité graphique KSP plus spécifique n'est décidée ;
+- `vite.config.ts`, `tsconfig.json` et fichiers frontend/build équivalents structurés de manière cohérente avec le modèle éprouvé ;
+- package Rust mixte `lib` + `bin`, avec noms de cibles distincts ;
+- `main.rs` minimal : verrou single-instance, parsing/bootstrap des éventuels arguments CLI nécessaires, puis appel de la fonction `run` exposée par la bibliothèque applicative ;
+- `lib.rs` limité aux déclarations de modules et réexports nécessaires ;
+- `tauri.rs` propriétaire de `run`, des wrappers `#[tauri::command]` et des helpers Tauri/démarrage partagés (`init_rustls`, `open_or_focus_window`, etc.) ;
+- fonctions métier/fenêtre implémentées dans leurs modules puis appelées par les wrappers de `tauri.rs` ; aucune annotation `#[tauri::command]` dispersée hors de cette frontière ;
+- modules spécifiques aux fenêtres nommés `tw_*` (`Tauri window`) sauf meilleure convention explicitement décidée pendant `pre.001` ;
+- helpers communs regroupés dans des modules partagés et non copiés entre fenêtres.
+
+Cette réutilisation de bot3 est une référence de conception : le `pre.001` doit vérifier ce qui reste pertinent avec les versions Tauri/Vite/TypeScript actuelles avant intégration.
+
+### 6.2 Splashscreen commun
+
+Le splashscreen et ses fonctionnalités doivent devenir une capacité commune aux applications Tauri KSP :
+
+- même lifecycle de splashscreen réutilisable ;
+- comportement configurable plutôt que recopié par application ;
+- durée/temporisation configurée via Config/.env ;
+- le nom exact de la ou des variables est décidé au moment où le besoin runtime est implémenté, en respectant `KSP_*`/`KSP_PUBLIC_*` selon l'exposition nécessaire ;
+- toute nouvelle clé est ajoutée à `.env.example` avec commentaire **dans le même delta que sa première utilisation** ;
+- aucune temporisation sensible à l'environnement n'est codée en dur dans chaque application.
+
+### 6.3 Documentation affichée dans l'UI
+
+Ne jamais charger `README.md` comme contenu d'une fenêtre Tauri. Le README reste la documentation du package.
+
+Si `ksp-app-config-desk` retient une vue/fenêtre de présentation, créer un `PRESENTATION.md` dédié et utiliser `markdown-it` comme renderer de référence, après vérification de la version réellement actuelle/compatible avant ajout de la dépendance. `PRESENTATION.md` ne contient aucun lien navigable Markdown ou HTML susceptible de modifier la navigation de la webview ou d'ouvrir/casser une fenêtre.
+
+Si l'application finale est monofenêtre et n'affiche aucune présentation, ne pas créer `PRESENTATION.md` et ne pas ajouter `markdown-it` uniquement par symétrie avec bot3.
+
 ## 7. Sécurité et redaction
 
 Le desktop Config est une application de management privilégiée, mais cela ne supprime pas les frontières de sécurité :
@@ -190,6 +232,10 @@ Conserver notamment :
 - versions caret de génération compatibles ;
 - aucun `Cargo.lock`/lockfile frontend versionné selon la politique KSP actuelle ;
 - chaque delta `0.1.x` est commité ; un défaut livré est corrigé par un `fix`, jamais réécrit silencieusement.
+- après toute modification Rust : `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets` sont obligatoires avant livraison ;
+- pendant une tranche de développement, préférer `cargo test -p <crate>` pour la crate travaillée ; réserver `cargo test --workspace` aux ouvertures/fermetures de session/version et aux contrôles globaux justifiés ;
+- exécuter les `cargo tree` pertinents pour les crates modifiées/complétées ;
+- toute crate complétée possède un `README.md`; une bibliothèque complétée possède un `USAGE.md` version-neutral centré sur l'API publique avec exemples ; une application Tauri complétée possède un `USAGE.md` décrivant ses fenêtres et leur utilisation.
 
 ## 9. Hors scope par défaut de `0.1.4`
 
@@ -218,16 +264,20 @@ Il doit produire au minimum :
 
 1. audit exact de la base stable `v0.1.3` ;
 2. audit des règles Tauri/app existantes ;
-3. choix du layout `apps/ksp-app-config-desk` et de son intégration workspace ;
+3. choix du layout interne de `crates/ksp-app-config-desk` et de son intégration workspace ;
 4. matrice commandes Tauri / services internes / APIs Config appelées ;
 5. matrice DTO ordinaires / DTO secrets privilégiés ;
 6. modèle d'état applicatif et ownership de `LoggingGuard` ;
 7. écrans/panneaux minimums et flux utilisateur ;
-8. stratégie de tests Rust, Tauri et frontend ;
-9. dépendances externes réellement nécessaires et versions actuelles vérifiées ;
-10. hors-scope confirmés ;
-11. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ;
-12. critères de validation de la release.
+8. stratégie de tests Rust, Tauri et frontend, avec tests ciblés par package pendant le développement et `cargo test --workspace` aux frontières globales ;
+9. audit du gabarit bot3 à réutiliser/refondre : SASS/SCSS, packages, Vite/TypeScript, icône, layout frontend et splashscreen ;
+10. contrat exact `lib` + `bin`, `main.rs`, `lib.rs`, `tauri.rs`, modules `tw_*`, helpers communs et single-instance ;
+11. stratégie de splashscreen commun et choix futur de la/des variable(s) Config/.env avec mise à jour obligatoire de `.env.example` lors de leur première utilisation ;
+12. dépendances externes réellement nécessaires et versions actuelles vérifiées ;
+13. hors-scope confirmés ;
+14. prévision souple des prereleases, chaque tranche visant environ 15–20 minutes de travail effectif ;
+15. décision explicite sur la présence d'une vue de présentation : `PRESENTATION.md` + `markdown-it` si elle existe, aucun fichier/dépendance de présentation si elle n'existe pas ;
+16. critères de validation de la release et documentation finale `README.md` / `USAGE.md` / `PRESENTATION.md` conditionnel.
 
 Ne commencer `pre.002` qu'après validation de ce plan.
 
@@ -235,8 +285,10 @@ Ne commencer `pre.002` qu'après validation de ce plan.
 
 La dernière prerelease de `0.1.4` devra comme d'habitude :
 
-- exécuter les validations finales ;
+- exécuter les validations finales, dont `cargo test --workspace` puisque la release se ferme ;
 - consolider la documentation ;
+- finaliser le `README.md` de l'application et son `USAGE.md` décrivant chaque fenêtre et son utilisation ;
+- finaliser `PRESENTATION.md` uniquement si l'application possède réellement une vue de présentation, et vérifier l'absence de liens navigables Markdown/HTML ;
 - fermer/report explicitement les TODO ;
 - nettoyer/archiver ce qui doit l'être ;
 - synchroniser le changelog général lors de la publication stable ;