v0.1.4-pre.019

This commit is contained in:
2026-08-17 08:55:24 +02:00
parent 8f7df2d06e
commit 8099b6cb39
15 changed files with 422 additions and 199 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-app-config-desk/README.md -->
<!-- version: 22 -->
<!-- version: 23 -->
# `ksp-app-config-desk`
@@ -124,7 +124,7 @@ main -> ksp-app-config-desk.frontend.main
splash -> ksp-app-config-desk.frontend.splash
```
Rust valide le niveau et le `targetId`, choisit un callsite statique puis émet exclusivement via les macros de `ksp-logging-lib`. Le package applicatif n'importe pas directement `tracing`. Le pont actuel garantit donc le trajet WebView -> Rust tout en conservant l'affichage local des appels `console.*` dans la console WebKit. Il ne réémet pas encore les événements Rust arbitraires vers la console WebKit : cette direction nécessitera une intégration contrôlée de `tauri_plugin_tracing::WebviewLayer` dans le subscriber possédé par `ksp-logging-lib`, sans second subscriber ni boucle avec le bridge KSP. Le panneau **Test Logging** complète désormais ce bridge : il peut émettre des événements backend via `ksp-logging-lib` avec target KSP statique et domain contrôlé, ou réutiliser le bridge frontend existant avec son target/domain fixes.
Rust valide le niveau et le `targetId`, choisit un callsite statique puis émet exclusivement via les macros de `ksp-logging-lib`. Le package applicatif n'importe pas directement `tracing`. Le pont actuel garantit donc le trajet WebView -> Rust tout en conservant l'affichage local des appels `console.*` dans la console WebKit. Le retour général Rust -> console WebKit est volontairement hors périmètre de `0.1.4` : une future intégration devra passer par une couche possédée par `ksp-logging-lib`, sans second subscriber, double émission ni boucle avec le bridge KSP. Le panneau **Test Logging** complète désormais ce bridge : il peut émettre des événements backend via `ksp-logging-lib` avec target KSP statique et domain contrôlé, ou réutiliser le bridge frontend existant avec son target/domain fixes.
## Panneau Test Logging
@@ -168,7 +168,11 @@ Le panneau expose `format_version`, `logs_directory`, `default_profile`, tous le
`pre.016` distingue en plus le **profil default persistant** du **profil runtime actif**. La section **Runtime actif** expose le profil actuellement appliqué, `selection_source` (`default_profile`, `explicit` ou `fallback`), la génération, l'état console, les compteurs de lignes abandonnées et les file sinks réellement actifs. Un profil déjà persisté peut être appliqué explicitement sans modifier `default_profile` ni écrire le document ; cette action est désactivée tant que le brouillon contient des changements non sauvegardés.
Chaque lancement de Config Desk crée aussi une `LoggingRuntimeIdentity` stable : `application_id` + timestamp UTC de démarrage + PID. `ksp-logging-lib` utilise cette identité pour préfixer les noms des fichiers actifs et la conserve pendant tous les hot reloads du même processus. Deux lancements distincts ne partagent donc plus le même fichier persistant, même avec une rotation `daily`. Exemple d'un prefix effectif : `ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-debug.log`. Le path Config reste inchangé ; l'identité appartient au runtime, pas au document source.
Chaque lancement de Config Desk crée aussi une `LoggingRuntimeIdentity` stable : `application_id` + timestamp UTC de démarrage + PID. `ksp-logging-lib` utilise cette identité pour préfixer les noms des fichiers actifs et la conserve pendant tous les hot reloads du même processus. Deux lancements distincts ne partagent donc plus le même fichier persistant, même avec une rotation `daily`. Avec la configuration de release `info/ksp-info.log`, un prefix effectif peut être `ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-info.log`. Le path Config reste inchangé ; l'identité appartient au runtime, pas au document source.
## Baseline Logging de release
La configuration canonique livrée avec `0.1.4` revient à une baseline opératoire `info` conformément à KSP-APP-031 : console `info`, sink général `info/ksp-info.log` au niveau `info`, et overrides `ksp-config-lib`, `ksp-logging-lib`, `ksp-app-config-desk` à `info`. Le `default_filter` reste `warn` pour les autres targets KSP. Les niveaux `debug`/`trace` restent disponibles et peuvent être remontés temporairement depuis Config Desk lors dun développement ou diagnostic, puis redescendus avant la release suivante.
## Traçabilité frontend

View File

@@ -1,11 +1,10 @@
<!-- file: crates/ksp-app-config-desk/TODO.md -->
<!-- version: 18 -->
<!-- version: 19 -->
# TODO `ksp-app-config-desk`
Le gabarit frontend, le bootstrap Config/Logging, `AppState`, le `LoggingGuard` durable, les premiers DTO TS-RS, le bridge frontend logging KSP, le lifecycle `splash -> main`, les panneaux Documents, Profils/provenance et Environnement avec management `.env`/reveal Secret privilégié, ainsi que l'édition typée/persistence atomique du document Logging, son hot reload transactionnel, la sélection explicite du profil runtime, les fichiers isolés par identité de lancement, le panneau Test Logging backend/frontend, le registre d'éditeurs spécialisés et les audits desktop de robustesse sont maintenant présents.
Aucun TODO bloquant ne reste ouvert pour la release `0.1.4`.
La clôture `pre.019` doit encore :
La première version fonctionnelle de Config Desk couvre le shell Tauri, le bootstrap Config/Logging, linventaire et la réparation des documents, linspection des profils/provenance, le management `.env`, le reveal Secret privilégié, léditeur Logging typé, la persistence atomique, le hot reload transactionnel, la sélection explicite du profil runtime, les fichiers de logs isolés par lancement, le panneau Test Logging backend/frontend, le registre déditeurs spécialisés et les audits desktop.
- ramener le target applicatif de `debug` à `info` ou `warn` avant clôture de la release ;
- étudier puis intégrer le retour Rust -> console WebKit via `tauri_plugin_tracing::WebviewLayer` dans le subscriber possédé par `ksp-logging-lib`, afin de pouvoir utiliser `attachConsole()` sans second subscriber, double émission ni boucle avec le bridge KSP.
Le retour général **Rust -> console WebKit** via une `WebviewLayer` du plugin tracing est volontairement reporté hors `0.1.4`. Le trajet **WebView -> Rust -> ksp-logging-lib** est déjà validé et le panneau Test Logging couvre le routing runtime. Une future intégration Rust -> WebKit devra être conçue dans `ksp-logging-lib` afin de préserver le subscriber unique, déviter les doubles émissions et de ne pas créer de boucle avec le bridge `console.*` existant. Le sujet est conservé dans `docs/IDEAS.md`.

View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-app-config-desk/USAGE.md -->
<!-- version: 22 -->
<!-- version: 23 -->
# Utilisation de `ksp-app-config-desk`
@@ -85,7 +85,7 @@ splash
Ils sont convertis côté Rust vers des targets KSP statiques `ksp-app-config-desk.frontend*` et émis uniquement via `ksp-logging-lib`. Un niveau différent de `trace`, `debug`, `info`, `warn` ou `error`, ou un `targetId` non whitelisté, est rejeté avec un `CommandErrorDto` sûr.
`main.ts` et `splash.ts` installent aussi le bridge `console.*`; l'échec éventuel d'un `invoke` est écrit uniquement sur la console WebView originale afin d'éviter une boucle de logging. Ce bridge conserve donc les messages JavaScript dans la console WebKit et les transmet vers Rust, mais il ne reflète pas encore les événements Rust généraux dans cette console. `attachConsole()` du package officiel nécessite que le subscriber Rust publie vers une `WebviewLayer`; cette couche devra être raccordée plus tard à l'ownership de `ksp-logging-lib` plutôt que d'installer un subscriber Tauri parallèle.
`main.ts` et `splash.ts` installent aussi le bridge `console.*`; l'échec éventuel d'un `invoke` est écrit uniquement sur la console WebView originale afin d'éviter une boucle de logging. Ce bridge conserve les messages JavaScript dans la console WebKit et les transmet vers Rust. Le retour général Rust -> console WebKit est reporté hors `0.1.4`; il devra être ajouté ultérieurement sous ownership de `ksp-logging-lib`, sans installer de subscriber Tauri parallèle ni créer de boucle avec ce bridge.
## Bindings TS-RS
@@ -257,10 +257,10 @@ Au démarrage de Config Desk, l'identité de lancement est construite une seule
20260816-182519.123Z-p4242
```
Pour un fichier source configuré comme `debug/ksp-debug.log`, le runtime peut donc exposer un prefix comme :
Avec la baseline de release configurée sur `info/ksp-info.log`, le runtime peut exposer un prefix comme :
```text
ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-debug.log
ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-info.log
```
Le même `launch_timestamp` doit rester affiché après chaque hot reload du processus courant. Après fermeture puis nouveau lancement de l'application, il doit changer. La rotation `daily` ou `hourly` peut ajouter sa composante de rotation, mais deux lancements ne doivent plus partager le même prefix applicatif.
@@ -283,6 +283,21 @@ Le bouton d'application explicite est désactivé lorsque le brouillon est sale
Si la résolution ou la préparation du profil explicite échoue, `ksp_logging_lib::reinitialize()` ne remplace pas les layers actifs et la génération ne doit pas avancer. Une sauvegarde de document qui échoue pendant l'application runtime conserve également l'ancien runtime et restaure la source précédente lorsqu'elle avait été modifiée.
## Baseline Logging de release
Après les tests `debug`/`trace`, la configuration canonique `0.1.4` revient à :
```text
default_filter = warn
console.filter.level = info
file.all.info = info/ksp-info.log @ info
ksp-config-lib = info
ksp-logging-lib = info
ksp-app-config-desk = info
```
Pour rouvrir un diagnostic, augmenter temporairement un niveau depuis léditeur Logging, utiliser **Sauvegarder et appliquer**, puis restaurer `info`/`warn` avant la prochaine clôture de release.
## Validation desktop de robustesse
La validation suit un ordre strict. Depuis la racine du workspace, valider dabord Rust :