v0.1.4-pre.014

crates/ksp-app-config-desk/README.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-config-desk/README.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # `ksp-app-config-desk`
 
@@ -29,6 +29,7 @@ Le gabarit desktop actif fournit maintenant :
 - le panneau Documents générique alimenté par le registre `ksp-config-lib`, avec diagnostics backend et réparation validée ;
 - le panneau Profils générique pour `default_profile`, sélection explicite, vues global/profil/effective sûre et provenance ;
 - le panneau Environnement alimenté uniquement par `ConfigManagement`, avec rapport desired/effective sûr, source/shadowing, management atomique `.env` et reveal Secret privilégié/transitoire ;
+- le panneau Logging en lecture typée, alimenté par `ConfigManagement::load_logging_document()` et projetant profils, console, fichiers, filtres, targets et domains sans parsing frontend ;
 - `tauri-plugin-tracing` côté Rust et `@fltsci/tauri-plugin-tracing` côté frontend ;
 - les ports dédiés `1430` pour Vite HTTP et `1431` pour le WebSocket de développement ;
 - la destination frontend externe commune à Tauri et Vite;
@@ -53,6 +54,7 @@ frontend/
 │   ├── environment.ts
 │   ├── frontend_log.ts
 │   ├── invoke.ts
+│   ├── logging.ts
 │   ├── main.ts
 │   ├── profiles.ts
 │   ├── secret_reveal.ts
@@ -130,7 +132,7 @@ KSP_DESK_SPLASH_FADE_MS=300
 
 Après la readiness frontend, Rust émet `fade_in`, attend la durée minimale, émet `fade_out`, attend la durée de fade puis `tw_main.rs` affiche/focalise `main` avant destruction du splash. Le backend journalise en `debug` les valeurs résolues, leur provenance (`process`, `dotenv` ou `fallback`), chaque attente réellement observée et la durée totale. Avec `12000/3000`, la durée backend attendue entre readiness et activation de `main` est donc d'environ `15000 ms`. Une valeur splash invalide ne bloque pas le manager : des timings de fallback sûrs restent en mémoire afin que la future surface `.env` puisse permettre la réparation.
 
-Le shell principal expose les cinq routes de référence `Vue d'ensemble`, `Documents`, `Profils`, `Environnement / .env` et `Logging`. Le logo porte déjà l'identité KSP ; le texte du header suit donc la forme `Config Desk — <vue active>` au lieu de répéter `KSP`. Les quelques commandes principales restent des pills/tabs à droite ; un dropdown sera préféré lorsqu'une application possède trop de commandes pour conserver ce format lisible. Les routes non encore fonctionnelles affichent un placeholder sans réimplémenter les services prévus par les prereleases suivantes.
+Le shell principal expose les cinq routes de référence `Vue d'ensemble`, `Documents`, `Profils`, `Environnement / .env` et `Logging`. Le logo porte déjà l'identité KSP ; le texte du header suit donc la forme `Config Desk — <vue active>` au lieu de répéter `KSP`. Les quelques commandes principales restent des pills/tabs à droite ; un dropdown sera préféré lorsqu'une application possède trop de commandes pour conserver ce format lisible. La route Logging expose maintenant la lecture typée du document et de ses profils ; les mutations/persistence et le hot reload restent réservés aux prereleases suivantes.
 
 
 ## Panneau Profils
@@ -139,6 +141,12 @@ La vue **Profils** inspecte les documents validés qui exposent le contrat stand
 
 L'inspection expose le profil par défaut ou une sélection explicite, les vues source `globals` et `profile`, ainsi que l'effective après résolution environnementale. Cette dernière est toujours sérialisée depuis `ResolvedConfigJson::safe_value()` afin qu'une substitution Secret soit redacted. La provenance top-level distingue `global` / `profile`; la provenance environnement n'expose que JSON Pointer, nom de variable, source `process`/`.env`/fallback et sensibilité, jamais la valeur résolue.
 
+## Panneau Logging — lecture typée
+
+La vue **Logging** charge le document standard exclusivement avec `ConfigManagement::load_logging_document()`. Rust mappe ensuite les types publics `LoggingConfigDocument`, `LoggingProfileConfig`, `LoggingConsoleConfig`, `LoggingFileConfig`, `LoggingOutputFilterConfig` et `LoggingTargetFilterConfig` vers des DTO TS-RS dédiés. Le frontend ne parse donc ni le JSON source ni son schema.
+
+La tranche de lecture expose `format_version`, `logs_directory`, `default_profile`, tous les profils, la console, les fichiers persistants, les filtres locaux, les target overrides et les listes de targets/domains. La sélection d'un profil ne modifie rien : `pre.014` est strictement read-only. Les mutations typées et la persistence via `save_logging_document()` appartiennent à `pre.015`.
+
 ## Traçabilité frontend
 
 Les actions utilisateur significatives et changements d'état sont journalisés en `debug`; les opérations plus fines (rendu/remplacement DOM, étapes IPC, animations et événements fréquents) en `trace`. Le wrapper `invoke.ts` trace début/fin des commandes sans journaliser leurs arguments, afin de ne pas créer ultérieurement de fuite de valeurs sensibles.