diff --git a/deltas/0.1.3/pre.015-fix.002.md b/deltas/0.1.3/pre.015-fix.002.md new file mode 100644 index 0000000..d3d96dd --- /dev/null +++ b/deltas/0.1.3/pre.015-fix.002.md @@ -0,0 +1,78 @@ + + + +# 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`. diff --git a/docs/rules/RULES_KSP.md b/docs/rules/RULES_KSP.md index 9494387..1a76317 100644 --- a/docs/rules/RULES_KSP.md +++ b/docs/rules/RULES_KSP.md @@ -1,5 +1,5 @@ - + # 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](...)`, ``, 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 diff --git a/prompts/004-V0_1_4_START_PROMPT.md b/prompts/004-V0_1_4_START_PROMPT.md index 7534294..7d7f819 100644 --- a/prompts/004-V0_1_4_START_PROMPT.md +++ b/prompts/004-V0_1_4_START_PROMPT.md @@ -1,5 +1,5 @@ - + # 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 ;