v0.1.3-pre.015-fix.002

deltas/0.1.3/pre.015-fix.002.md

@@ -0,0 +1,78 @@
+<!-- file: deltas/0.1.3/pre.015-fix.002.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-pre.015-fix.002 — tracing Tauri et critères de clôture de ksp-app-config-desk
+
+## Base requise
+
+```text
+0.1.3-pre.015-fix.001
+workspace.package.version = "0.1.3-pre.15"
+```
+
+Ce correctif est exclusivement documentaire. Il ne modifie aucun fichier Rust, manifest Cargo, fichier Config runtime, schema ou variable d'environnement. `workspace.package.version` reste donc `0.1.3-pre.15`.
+
+## Objet
+
+Le correctif complète les règles du gabarit Tauri de référence et les critères fonctionnels de `0.1.4`.
+
+### Intégration tracing des applications Tauri
+
+Les applications Tauri KSP restent dans l'écosystème `tracing` :
+
+- `ksp-logging-lib` reste propriétaire de la configuration et du runtime `tracing` ;
+- la frontière desktop utilise le plugin Tauri de tracing retenu (`tauri-plugin-tracing` ou successeur explicitement validé) et des adapters similaires à ceux éprouvés dans khadhroony-bot3 ;
+- l'application ne possède/configure pas directement `tracing-subscriber` ou `tracing-appender` ;
+- `tauri-plugin-log` et une seconde pile fondée sur la crate `log` sont interdits sauf future décision architecturale explicite remplaçant cette règle.
+
+Le `pre.001` de `0.1.4` devra vérifier la version réellement actuelle/compatible du plugin avant ajout de la dépendance.
+
+### Critères minimaux de clôture de `0.1.4`
+
+La première version de `ksp-app-config-desk` ne pourra être considérée comme validée que si l'application permet réellement de :
+
+1. créer et modifier plusieurs profils Logging depuis l'UI ;
+2. configurer au minimum un profil mono-fichier ;
+3. configurer au minimum un profil multi-fichiers avec sorties séparées et sortie logiciel/console ;
+4. sauvegarder ces modifications via les APIs de management de `ksp-config-lib` ;
+5. sélectionner/appliquer un profil ;
+6. recharger à chaud la configuration Logging ;
+7. constater effectivement le nouveau routage/format/sink sans redémarrage, et pas seulement obtenir un retour `Ok` d'une commande de reload ;
+8. conserver le runtime Logging précédent lorsqu'une nouvelle configuration est invalide.
+
+### Extensibilité du gestionnaire Config
+
+`ksp-app-config-desk` doit devenir un shell de management extensible. La première version peut implémenter un éditeur Logging spécialisé et typé, mais son architecture ne doit pas être figée sur `std.logging.json` : de futurs `file_id`, schemas et éditeurs/panneaux spécialisés devront pouvoir être ajoutés sans déplacer parsing, validation ou persistence hors de `ksp-config-lib`.
+
+## Fichiers modifiés
+
+```text
+docs/rules/RULES_KSP.md
+prompts/004-V0_1_4_START_PROMPT.md
+```
+
+## Fichier ajouté
+
+```text
+deltas/0.1.3/pre.015-fix.002.md
+```
+
+## Version Cargo
+
+Aucune modification :
+
+```text
+workspace.package.version = "0.1.3-pre.15"
+```
+
+## Validation du correctif
+
+Le correctif étant documentaire :
+
+- vérifier les headers `file:` / `version:` ;
+- vérifier l'absence de modification Rust/Cargo/config ;
+- vérifier la cohérence entre les règles KSP et le prompt `0.1.4` ;
+- vérifier que `tauri-plugin-log` n'est cité que comme dépendance interdite ;
+- vérifier que les critères de clôture multi-profils + hot reload sont explicitement présents.
+
+Aucune commande Cargo n'est requise spécifiquement pour ce fix documentaire. La validation globale de fermeture de `0.1.3` reste requise avant `rel.001`.

docs/rules/RULES_KSP.md

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

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 ;