<!-- file: deltas/0.1.4/pre.007.md -->
<!-- version: 2 -->

# `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 :

```bash
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 :

```text
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é à :

```text
frontend
main
splash
```

Rust mappe ces identifiants vers les callsites statiques :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
FrontendLogPayloadDto
├── level
├── targetId
└── message
```

Le binding est généré sous :

```text
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 :

```text
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 :

```text
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 :

```bash
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 :

```text
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.