khadhroony-solana-project/deltas/0.1.4/pre.007.md

0.1.4-pre.007 — Bridge frontend logging KSP

1. Base validée

La base 0.1.4-pre.6.fix.1 a été validée localement avec :

cargo fmt --all
cargo check --workspace
cargo test -p ksp-app-config-desk
cargo test -p ksp-config-lib
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json

Les tests de l'application et de Config passent, Vite démarre sur 1430, le binaire Tauri s'exécute et le fallback Logging transitoire reste observable lorsque std.logging.json n'est pas disponible depuis les paths actifs.

2. Objectif

Cette tranche reprend/refond le mécanisme frontend_log.ts éprouvé dans khadhroony-bot3 afin que les événements techniques des WebViews passent par la façade Logging KSP.

Elle introduit :

• FrontendLogPayloadDto avec binding TS-RS ;
• frontend/ts/frontend_log.ts ;
• les helpers frontendTrace / frontendDebug / frontendInfo / frontendWarn / frontendError ;
• un bridge console.* pour trace, debug, log, info, warn et error ;
• la commande Tauri centralisée emit_frontend_log ;
• une whitelist d'identifiants de targets frontend ;
• des callsites tracing KSP statiques et filtrables ;
• des tests unitaires de validation level/target.

Le panneau manuel Logging Test, ses targets de test et ses domaines personnalisables restent hors scope de pre.007.

3. Version technique

La tranche modifie le runtime Rust et TypeScript :

workspace.package.version = "0.1.4-pre.7"

Les versions frontend/Tauri applicatives restent 0.1.4.

4. Différence volontaire avec bot3

Bot3 acceptait un target texte frontend puis réémettait tous les événements sous un seul callsite Rust fixe, le target frontend demandé étant conservé comme champ structuré.

Config Desk doit pouvoir valider les filtres réels par target de ksp-logging-lib. pre.007 ne transporte donc plus un target tracing libre. Le DTO expose un targetId logique limité à :

frontend
main
splash

Rust mappe ces identifiants vers les callsites statiques :

frontend -> ksp-app-config-desk.frontend
main     -> ksp-app-config-desk.frontend.main
splash   -> ksp-app-config-desk.frontend.splash

Un identifiant arbitraire est rejeté. Le frontend ne peut donc ni usurper un target d'une autre crate ni créer dynamiquement une taxonomie de targets.

5. Niveau et domaine

Les seuls niveaux acceptés sont :

trace
debug
info
warn
error

La casse et les espaces périphériques sont normalisés côté Rust. Tout autre niveau produit config_desk.frontend_log_level_invalid.

Les événements techniques du bridge utilisent le domaine structuré fixe :

frontend

Le domaine reste distinct du target. Les domaines personnalisables appartiendront au panneau manuel Logging Test et ne sont pas ajoutés à ce DTO technique.

6. Ownership Logging

Le chemin est :

frontend helper / console bridge
-> invoke("emit_frontend_log")
-> wrapper #[tauri::command] dans tauri.rs
-> frontend_logging service
-> ksp-logging-lib::{trace,debug,info,warn,error}!
-> subscriber KSP déjà installé

ksp-app-config-desk n'importe pas directement tracing et tauri-plugin-tracing n'installe toujours aucun subscriber par défaut.

Le package @fltsci/tauri-plugin-tracing reste l'adaptateur frontend correspondant au plugin Tauri, mais le contrat applicatif KSP à target filtrable passe par la commande dédiée ci-dessus.

7. DTO et binding TS-RS

Le nouveau DTO est :

FrontendLogPayloadDto
├── level
├── targetId
└── message

Le binding est généré sous :

frontend/ts/bindings/ksp_app_config_desk/frontend_logging/FrontendLogPayloadDto.ts

Le message est une donnée technique fournie par le frontend. Cette surface ne doit pas être utilisée pour recopier des secrets Config ou des résultats de reveal.

8. Bridge console

installFrontendConsoleBridge(targetId) conserve les méthodes console originales puis route :

console.trace -> trace
console.debug -> debug
console.log   -> info
console.info  -> info
console.warn  -> warn
console.error -> error

L'affichage WebView original est conservé. Si invoke("emit_frontend_log") échoue, le diagnostic est écrit avec originalConsole.error, et non avec le console.error remplacé, afin d'éviter une récursion du bridge.

main.ts installe le bridge avec main; splash.ts avec splash. Les deux émettent également un événement info lors de leur DOMContentLoaded.

9. Erreurs applicatives

Deux codes stables sont ajoutés :

config_desk.frontend_log_level_invalid
config_desk.frontend_log_target_invalid

Le wrapper Tauri transforme ces erreurs avec le CommandErrorDto borné déjà introduit en pre.006.

10. Tests

Les tests unitaires hors src/ vérifient :

• les cinq niveaux reconnus et leur normalisation ;
• le rejet d'un niveau inconnu ;
• les trois targetId whitelistés ;
• le rejet d'un target arbitraire.

Le derive TS-RS ajoute le test d'export de FrontendLogPayloadDto.

11. Fichiers

Fichier	Action
Cargo.toml	modifié
crates/ksp-app-config-desk/src/constants.rs	modifié
crates/ksp-app-config-desk/src/errors.rs	modifié
crates/ksp-app-config-desk/src/frontend_logging.rs	ajouté
crates/ksp-app-config-desk/src/lib.rs	modifié
crates/ksp-app-config-desk/src/tauri.rs	modifié
crates/ksp-app-config-desk/unit_tests/frontend_logging.rs	ajouté
crates/ksp-app-config-desk/frontend/ts/frontend_log.ts	ajouté
crates/ksp-app-config-desk/frontend/ts/main.ts	modifié
crates/ksp-app-config-desk/frontend/ts/splash.ts	modifié
crates/ksp-app-config-desk/README.md	modifié
crates/ksp-app-config-desk/USAGE.md	modifié
crates/ksp-app-config-desk/TODO.md	modifié
deltas/0.1.4/pre.007.md	ajouté

12. Validations à exécuter

Depuis la racine du workspace :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-config-desk
cargo test -p ksp-config-lib
cargo tree -p ksp-app-config-desk
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json

Après les tests Rust, vérifier la présence du binding :

crates/ksp-app-config-desk/frontend/ts/bindings/ksp_app_config_desk/frontend_logging/FrontendLogPayloadDto.ts

Au lancement avec le fallback Logging Info, les événements Config Desk splash frontend loaded doivent être observables sous le target ksp-app-config-desk.frontend.splash. Le target main deviendra observable dans le lifecycle réel du shell lorsque la fenêtre principale sera affichée.

13. Suite

Après validation, pre.008 traite le shell et le lifecycle splash configurable : readiness frontend, fermeture/masquage du splash, affichage de main, et temporisation issue de Config/env plutôt qu'une constante environnementale codée en dur.