v0.1.3-pre.015-fix.002

prompts/004-V0_1_4_START_PROMPT.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/004-V0_1_4_START_PROMPT.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Prompt de démarrage `0.1.4` — ksp-app-config-desk
 
@@ -148,8 +148,16 @@ Le brainstorming `pre.001` doit au minimum cadrer une UI permettant de tester r
 - construire la configuration effective via `load_resolved_logging_config()` ;
 - initialiser/reconfigurer `ksp-logging-lib` ;
 - conserver `LoggingGuard` dans l'état applicatif/orchestration approprié ;
+- permettre depuis l'UI la création et la modification de plusieurs profils Logging ;
+- valider au minimum un profil mono-fichier et un profil multi-fichiers avec sorties séparées plus sortie logiciel/console ;
+- permettre la sélection du profil à appliquer, sa sauvegarde puis le rechargement à chaud du runtime Logging ;
+- prouver le hot reload par un changement observable du routage/format/sink sans redémarrage de l'application, idéalement au moyen d'événements de test contrôlés ;
 - vérifier qu'une erreur de nouvelle configuration ne détruit pas le runtime Logging déjà valide.
 
+Ces capacités constituent le **critère fonctionnel minimal de clôture de la première version de `ksp-app-config-desk`**. Une UI qui ne fait qu'afficher ou sauvegarder `std.logging.json` sans démontrer plusieurs profils et le rechargement effectif n'est pas suffisante pour clore `0.1.4`.
+
+L'architecture de l'application doit en parallèle rester extensible. `0.1.4` peut implémenter un éditeur Logging spécialisé et typé, mais le shell de management, la navigation et l'état applicatif doivent pouvoir accueillir ultérieurement de nouveaux `file_id`, schemas et panneaux/éditeurs spécialisés sans faire de l'application le propriétaire du parsing, de la validation ou de la persistence Config.
+
 ## 6. Frontière Tauri
 
 Conserver les règles KSP déjà retenues :
@@ -159,7 +167,9 @@ Conserver les règles KSP déjà retenues :
 - le `pre.001` doit décider et formaliser l’emplacement exact des `#[tauri::command]`; conserver comme direction héritée un adapter Tauri centralisé plutôt que des annotations dispersées ;
 - pas de `?`, `unwrap`, `expect` ou `panic` dans les commandes ;
 - l'application reste mince et appelle des fonctions/services internes qui réutilisent les crates KSP ;
-- aucune dépendance directe aux crates `tracing*` dans l'application : Logging reste la façade ;
+- aucune utilisation directe de `tracing`, `tracing-subscriber` ou `tracing-appender` pour posséder/configurer le runtime : `ksp-logging-lib` reste la façade et le propriétaire ;
+- intégrer à la frontière Tauri le plugin de tracing retenu (`tauri-plugin-tracing` ou successeur explicitement validé) et les adapters nécessaires, sur le modèle éprouvé de khadhroony-bot3 ; cette intégration desktop est l'exception prévue à la règle d'absence d'usage direct des crates `tracing*` ;
+- ne pas utiliser `tauri-plugin-log` ni construire une seconde pile basée sur la crate `log` ;
 - aucune lecture directe `std::env::var*` pour `KSP_*` / `KSPB_*` ;
 - aucune lecture/écriture directe des fichiers physiques Config/`.env`.
 
@@ -179,6 +189,7 @@ Le `pre.001` doit vérifier les versions actuelles de Tauri et des dépendances
 - 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.
+- modules/adapters Tauri de tracing repris/refondus depuis le modèle khadhroony-bot3, en utilisant `tauri-plugin-tracing` plutôt que `tauri-plugin-log`, tout en laissant `ksp-logging-lib` posséder la configuration/runtime `tracing`.
 
 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.
 
@@ -273,11 +284,13 @@ Il doit produire au minimum :
 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 ;
+12. dépendances externes réellement nécessaires et versions actuelles vérifiées, dont le plugin Tauri de tracing ; confirmer explicitement l'absence de `tauri-plugin-log` ;
 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.
+16. critères de validation de la release et documentation finale `README.md` / `USAGE.md` / `PRESENTATION.md` conditionnel ;
+17. matrice de validation fonctionnelle de clôture couvrant au minimum : création/modification de plusieurs profils Logging, profil mono-fichier, profil multi-fichiers + sortie logiciel/console, sauvegarde, sélection et hot reload observable sans redémarrage ;
+18. stratégie d'extensibilité permettant d'ajouter de futurs `file_id`/schemas/éditeurs sans refondre le shell de management ni contourner `ksp-config-lib`.
 
 Ne commencer `pre.002` qu'après validation de ce plan.
 
@@ -289,6 +302,8 @@ La dernière prerelease de `0.1.4` devra comme d'habitude :
 - 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 ;
+- démontrer les critères fonctionnels de clôture : plusieurs profils Logging créés/modifiés via l'UI, un profil mono-fichier, un profil multi-fichiers avec sortie logiciel/console, sauvegarde et hot reload observable sans redémarrage ;
+- vérifier que l'application reste structurée pour accueillir de futurs documents/schemas Config sans duplication de la logique de `ksp-config-lib` ;
 - fermer/report explicitement les TODO ;
 - nettoyer/archiver ce qui doit l'être ;
 - synchroniser le changelog général lors de la publication stable ;