92 lines
3.5 KiB
Markdown
92 lines
3.5 KiB
Markdown
<!-- file: deltas/0.1.4/pre.017.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Delta `0.1.4-pre.017` — panneau Test Logging
|
|
|
|
## Base
|
|
|
|
`0.1.4-pre.016-fix.002` est validée : `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets` sont propres ; 56 tests `ksp-app-config-desk`, 88 tests `ksp-config-lib`, 37 tests unitaires `ksp-logging-lib`, les audits ownership, APIs publiques et tests runtime/intégration passent.
|
|
|
|
## Objectif
|
|
|
|
Ajouter une surface manuelle et contrôlée pour démontrer le routing réel du runtime Logging avant/après hot reload, sans contourner `ksp-logging-lib` et sans introduire de target dynamique arbitraire.
|
|
|
|
## Changements
|
|
|
|
### Backend contrôlé
|
|
|
|
Config Desk ajoute `emit_logging_test` et deux DTO TS-RS :
|
|
|
|
- `LoggingTestRequestDto` ;
|
|
- `LoggingTestResultDto`.
|
|
|
|
Le service accepte :
|
|
|
|
- niveau `trace`, `debug`, `info`, `warn`, `error` ou `all` ;
|
|
- target logique `app` -> `ksp-app-config-desk` ;
|
|
- target logique `logging_test` -> `ksp-app-config-desk.logging-test` ;
|
|
- domain `absent`, `known` ou `custom`.
|
|
|
|
Les domains connus sont limités à `config.logging_test`, `config.logging_runtime` et `frontend`. Un domain personnalisé est borné à 80 caractères ASCII alphanumériques plus `.`, `_` et `-`. Le message doit contenir de 1 à 500 octets.
|
|
|
|
Les targets restent des callsites statiques. L'application n'importe pas `tracing` et émet exclusivement via les macros `ksp-logging-lib`.
|
|
|
|
Le mode `all` émet exactement cinq événements, un par niveau. Le résultat ne réexpose pas le message ; il contient uniquement le nombre d'événements, le niveau demandé, target/domain effectifs et la génération runtime active.
|
|
|
|
### Frontend
|
|
|
|
La vue Logging ajoute **Test Logging — routing contrôlé** avec :
|
|
|
|
- message ;
|
|
- niveau ;
|
|
- target backend contrôlé ;
|
|
- domain absent/connu/personnalisé ;
|
|
- **Log backend** ;
|
|
- **Log via bridge frontend**.
|
|
|
|
La voie frontend réutilise le bridge existant et conserve son contrat fixe `target=ksp-app-config-desk.frontend.main`, `domain=frontend`. Elle permet de comparer le routing d'un événement backend et celui d'un événement issu de la WebView dans les mêmes sinks.
|
|
|
|
Le message du panneau est volontairement journalisé : l'UI rappelle explicitement de ne jamais y placer de Secret.
|
|
|
|
### Tests
|
|
|
|
Les tests ajoutés couvrent :
|
|
|
|
- les cinq niveaux et le mode batch `all` ;
|
|
- les deux targets statiques ;
|
|
- les trois modes de domain ;
|
|
- le rejet des domains personnalisés non sûrs ;
|
|
- la borne du message ;
|
|
- les exports TS-RS des DTO.
|
|
|
|
## Version technique
|
|
|
|
```text
|
|
workspace.package.version = 0.1.4-pre.17
|
|
```
|
|
|
|
## Validation attendue
|
|
|
|
```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 test -p ksp-logging-lib
|
|
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
|
|
```
|
|
|
|
Scénario fonctionnel :
|
|
|
|
1. avec le profil actif actuel, lancer `tous` sur `ksp-app-config-desk.logging-test` + `config.logging_test` ;
|
|
2. noter quels niveaux apparaissent en console et dans les file sinks ;
|
|
3. modifier niveaux/targets/domains, **Sauvegarder et appliquer** ;
|
|
4. relancer exactement le même test sans redémarrage ;
|
|
5. vérifier que le routing suit immédiatement le nouveau runtime ;
|
|
6. répéter avec **Log via bridge frontend** et vérifier le target `ksp-app-config-desk.frontend.main` / domain `frontend`.
|
|
|
|
## Suite
|
|
|
|
`0.1.4-pre.018` couvrira robustesse/extensibilité/tests desktop : source invalide au démarrage, audits, tests frontend/Tauri/build et ajout futur d'un `file_id`/editor sans refonte du shell.
|