222 lines
8.4 KiB
Markdown
222 lines
8.4 KiB
Markdown
<!-- file: deltas/0.1.4/pre.001-fix.001.md -->
|
||
<!-- version: 1 -->
|
||
|
||
# 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.
|