# Delta 0.1.4-pre.001-fix.001 — frontend tracing, panneau de test Logging et découpage des prereleases ## Base requise ```text 0.1.4-pre.001 workspace.package.version = "0.1.4-pre.1" ``` Ce correctif est exclusivement documentaire. Il corrige le plan de `pre.001` avant son approbation et n'ouvre pas `pre.002`. Le delta historique `deltas/0.1.4/pre.001.md` reste inchangé. Les corrections sont portées par la révision du plan et par le présent fix, conformément à la règle KSP qui interdit de réécrire silencieusement une livraison déjà produite. ## Objet Le correctif fige trois compléments demandés après lecture du plan initial : 1. `@fltsci/tauri-plugin-tracing` est conservé comme package frontend compagnon de `tauri-plugin-tracing` au lieu d'être écarté comme dépendance inutilisée ; 2. le bridge `frontend_logging` éprouvé dans khadhroony-bot3 doit être repris/refondu afin de préserver des targets KSP explicites et de faire passer l'émission backend par `ksp-logging-lib` ; 3. le panneau Logging doit fournir un test manuel réel `message + niveau + target + domain + Log`, et la prévision des prereleases doit rester granulaire autour de tranches d'environ 15–20 minutes de travail effectif. Aucun code Tauri, Rust ou frontend n'est ajouté par ce fix. ## Couple `tauri-plugin-tracing` L'audit du projet officiel confirme le couple d'installation : ```text Rust : tauri-plugin-tracing TS : @fltsci/tauri-plugin-tracing ``` La version auditée reste `0.3.4` des deux côtés au moment de `pre.001`. KSP introduira donc les deux composants ensemble lorsque la tranche desktop correspondante sera implémentée. Les contraintes précédentes restent inchangées : - aucun `tauri-plugin-log` ; - aucun subscriber global parallèle ; - aucun `with_default_subscriber()` dans le plugin ; - `ksp-logging-lib` reste propriétaire du runtime `tracing` ; - aucune détente de la politique de targets `ksp-*` uniquement pour accepter le target vide actuellement produit par la commande JS standard du plugin. Les helpers officiels tels que `attachConsole`, `interceptConsole` ou `takeoverConsole` ne sont utilisés que si la tranche d'intégration confirme l'absence de boucle, double émission ou contournement du routing KSP. ## Reprise/refonte de `frontend_logging` Le modèle bot3 audité utilise : ```text frontend_log.ts -> FrontendLogPayload -> invoke("emit_frontend_log") -> wrapper central dans tauri.rs -> service Rust ``` KSP reprend ce principe avec les adaptations suivantes : - helpers `frontendTrace` / `frontendDebug` / `frontendInfo` / `frontendWarn` / `frontendError` ; - bridge console commun si retenu après test ; - targets frontend normalisés/whitelistés côté Rust ; - émission backend par la façade `ksp-logging-lib`, pas par une seconde ownership directe de `tracing` ; - DTO applicatif TS-RS appartenant à `ksp-app-config-desk` ; - aucune donnée issue d'un reveal Secret injectée automatiquement dans le bridge. Le package officiel `@fltsci/tauri-plugin-tracing` et l'adapter KSP sont donc complémentaires : le premier fournit l'intégration officielle Tauri, le second préserve les conventions/routings KSP que le bridge JS standard ne permet pas encore d'exprimer directement. ## Panneau interactif de test Logging Le panneau Logging doit fournir au minimum : ```text Message : texte libre destiné explicitement au test Niveau : trace | debug | info | warn | error | tous Target : select de targets KSP contrôlés Domain : aucun | domaine connu | personnalisé Bouton : Log ``` Le mode `tous` émet la même intention aux cinq niveaux avec un identifiant commun afin de visualiser les seuils de routing. ### Target Le frontend ne fournit pas une chaîne arbitraire utilisée directement comme target de callsite. Il transmet un `target_id` contrôlé. Le service Rust le mappe vers un ensemble fini de targets KSP, par exemple : ```text ksp-app-config-desk ksp-app-config-desk.frontend ksp-app-config-desk.test.logging ksp-app-config-desk.test.config ksp-app-config-desk.tauri ``` Cela permet de tester réellement les filtres `targets[]` sans créer un target dynamique arbitraire depuis la webview. ### Domain Le `domain` reste un champ structuré distinct. L'UI peut proposer : - aucun domaine ; - les domaines connus/utilisés par la configuration Logging active ; - quelques domaines de test prédéfinis ; - une valeur personnalisée. Le domain personnalisé ne remplace jamais le target propriétaire. ### Commande Tauri Le bouton `Log` appelle une commande dédiée, conceptuellement `emit_logging_test`, dont le service : 1. valide le niveau, le `target_id` et le domaine ; 2. sélectionne un callsite/target KSP contrôlé ; 3. émet via `ksp-logging-lib` ; 4. retourne un identifiant de test, le ou les niveaux émis, target/domain et la génération runtime active ; 5. ne recopie pas inutilement le message dans l'état backend ou le DTO de résultat. Le message n'est jamais prérempli depuis Config, diagnostics ou un reveal Secret. L'UI avertit explicitement que le texte sera journalisé et ne doit contenir aucune donnée sensible. ## Validation fonctionnelle Logging renforcée La démonstration de clôture doit pouvoir prouver depuis l'UI : - filtrage par niveau ; - filtrage par target ; - filtrage par domain ; - profil mono-fichier ; - profil multi-fichiers + console ; - sauvegarde sans apply ; - apply/hot reload sans redémarrage ; - changement observable du routing/format/sink avec le même message de test ; - événement frontend identifiable passant par le bridge `frontend_log.ts` ; - échec d'un reload invalide puis nouvel événement de test encore routé par l'ancien runtime valide. Le vieux probe fixe n'est donc plus l'unique preuve de fonctionnement : le panneau interactif devient un critère fonctionnel explicite. ## Prévision souple des prereleases Le plan est redécoupé pour viser des tranches d'environ **15–20 minutes de travail effectif** : ```text pre.001 audit + plan pre.002 Config : inventaire registre pre.003 Config : réparation source candidate pre.004 squelette Rust Tauri pre.005 squelette frontend + couple plugin tracing pre.006 bootstrap/AppState/LoggingGuard pre.007 frontend_logging commun pre.008 shell + splash pre.009 Documents/diagnostics pre.010 Profils/provenance pre.011 Environnement pre.012 Secrets/reveal pre.013 Logging editor lecture/DTO pre.014 Logging mutations/persistence pre.015 Logging apply/hot reload pre.016 panneau Test Logging + preuve routing pre.017 robustesse/extensibilité/tests desktop pre.018 clôture globale/docs/prompt/rel.001 ``` Ce découpage est **indicatif** : - une tranche trop grande est scindée ; - une tranche triviale peut absorber le début logique de la suivante ; - une dépendance découverte peut entraîner un réordonnancement ; - `pre.018` n'est pas un numéro final contractuel. L'objectif est de conserver des deltas courts, validables et compréhensibles, pas de forcer artificiellement le développement dans un nombre fixé de prereleases. ## Fichier modifié ```text docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md ``` Le header du plan passe de `version: 1` à `version: 2`. ## Fichier ajouté ```text deltas/0.1.4/pre.001-fix.001.md ``` ## Version Cargo Aucune modification de `Cargo.toml`. Le correctif ne touche ni code, build, runtime, Config, schema, migration ou variable d'environnement. `workspace.package.version` reste donc : ```text 0.1.4-pre.1 ``` L'identifiant de livraison est : ```text 0.1.4-pre.001-fix.001 ``` ## Validations du correctif À contrôler avant livraison : - header `file:` / `version:` des deux fichiers ; - absence de modification de `Cargo.toml` ; - absence de modification de `pre.001.md` ; - absence de nouvelle dépendance réellement ajoutée ; - présence de `@fltsci/tauri-plugin-tracing` dans le plan de dépendances futures ; - présence de `frontend_log.ts` dans le layout cible ; - présence du panneau `message + niveau + target + domain + Log` ; - présence des validations niveau/target/domain et bridge frontend ; - prévision souple explicitement calibrée autour de 15–20 minutes par prerelease ; - équilibre des fences Markdown ; - archive de fix limitée au plan modifié et au nouveau delta. Aucune commande Cargo n'est requise spécifiquement pour ce fix documentaire. Les validations Cargo de `pre.001` restent celles déjà prévues sur le poste de développement avant validation définitive de la tranche.