106 lines
4.1 KiB
Markdown
106 lines
4.1 KiB
Markdown
<!-- file: deltas/0.1.4/pre.018.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Delta `0.1.4-pre.018` — robustesse, extensibilité et tests desktop
|
|
|
|
## Base
|
|
|
|
`0.1.4-pre.017` est validée : `cargo fmt --all`, `cargo check --workspace` et `cargo clippy --workspace --all-targets` sont propres ; 62 tests unitaires Config Desk, 88 tests Config, 37 tests unitaires Logging et tous les audits/tests d'intégration associés passent. Le scénario runtime montre également le routing `TRACE` backend puis frontend après hot reload.
|
|
|
|
## Objectif
|
|
|
|
Durcir Config Desk avant la tranche de clôture : tester explicitement le comportement de démarrage sur source Logging invalide, matérialiser le registre d'éditeurs spécialisés prévu par le plan, et ajouter des audits desktop automatisés sur Tauri, le frontend, les secrets et les frontières d'ownership.
|
|
|
|
## Changements
|
|
|
|
### Bootstrap Logging testable avant installation
|
|
|
|
Le bootstrap sépare désormais la résolution d'un `LoggingStartupPlan` de l'installation du subscriber :
|
|
|
|
- `Managed` contient le profil résolu et les `LoggingSettings` ;
|
|
- `Fallback` contient le diagnostic sûr, l'erreur initiale et les settings transitoires.
|
|
|
|
L'installation runtime intervient seulement après cette décision. Un test peut donc fournir un source Logging invalide et vérifier la sélection du fallback sans installer un subscriber global dans le processus de tests.
|
|
|
|
Le fallback reste inchangé fonctionnellement : console stderr, niveau `Info`, aucun fichier et spans désactivés.
|
|
|
|
### Registre shell / éditeurs spécialisés
|
|
|
|
Nouveau `frontend/ts/shell_registry.ts` :
|
|
|
|
- registre unique des cinq vues du shell ;
|
|
- activation générique des panels par `panelId` ;
|
|
- registre séparé `file_id -> éditeur spécialisé` ;
|
|
- premier adapter `cfg.std.logging -> logging` ;
|
|
- événement `ksp:activate-view` pour demander une navigation sans coupler Documents à l'implémentation de Logging.
|
|
|
|
Le panneau Documents affiche **Ouvrir l'éditeur Logging** uniquement lorsqu'un adapter spécialisé existe pour le `file_id` sélectionné. Les documents inconnus du registre spécialisé restent inspectables et réparables via le shell générique.
|
|
|
|
### Audits desktop
|
|
|
|
Deux nouveaux tests d'intégration Config Desk couvrent :
|
|
|
|
- contrat Tauri `splash/main`, main initialement caché et commandes Vite explicites ;
|
|
- scripts frontend `build` et `check` ;
|
|
- présence du registre shell et dispatch d'éditeur spécialisé ;
|
|
- absence de `window.alert`, `window.confirm`, `window.prompt` ;
|
|
- absence de `localStorage` / `sessionStorage` dans le reveal Secret ;
|
|
- centralisation de tous les `#[tauri::command]` dans `tauri.rs` ;
|
|
- présence de `ksp-logging-lib` + `tauri-plugin-tracing` et absence de `tauri-plugin-log`.
|
|
|
|
Les audits Config ownership et Logging ownership existants restent les autorités workspace pour les frontières Config/tracing.
|
|
|
|
### Frontend build
|
|
|
|
`package.json` ajoute :
|
|
|
|
```text
|
|
npm run check
|
|
```
|
|
|
|
qui exécute `tsc --noEmit && vite build`.
|
|
|
|
## Version technique
|
|
|
|
```text
|
|
workspace.package.version = 0.1.4-pre.18
|
|
```
|
|
|
|
## Validation attendue
|
|
|
|
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 test -p ksp-logging-lib
|
|
```
|
|
|
|
Depuis `crates/ksp-app-config-desk` :
|
|
|
|
```bash
|
|
npm run check
|
|
```
|
|
|
|
Puis depuis la racine :
|
|
|
|
```bash
|
|
cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json
|
|
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
|
|
```
|
|
|
|
Parcours fonctionnel minimal :
|
|
|
|
1. Documents -> sélectionner `cfg.std.logging` ;
|
|
2. vérifier **Ouvrir l'éditeur Logging** ;
|
|
3. cliquer et vérifier l'activation de la vue Logging ;
|
|
4. revenir à Documents et confirmer que diagnostics/source restent inchangés ;
|
|
5. vérifier le comportement Logging déjà validé (profil runtime, hot reload, Test Logging) après ce refactor de shell.
|
|
|
|
## Suite
|
|
|
|
`0.1.4-pre.019` est la tranche de clôture : validation workspace/build complète, matrice fonctionnelle finale, retour du target applicatif de `debug` vers `info`/`warn`, README/USAGE/TODO/changelog, nettoyage/archivage et préparation de `rel.001` ainsi que du prompt de session suivant.
|