khadhroony-solana-project/deltas/0.1.4/pre.001-fix.001.md

Delta 0.1.4-pre.001-fix.001 — frontend tracing, panneau de test Logging et découpage des prereleases

Base requise

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 :

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 :

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 :

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 :

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 :

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é

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

Le header du plan passe de version: 1 à version: 2.

Fichier ajouté

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 :

0.1.4-pre.1

L'identifiant de livraison est :

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.