v0.1.4-pre.016

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

@@ -1,11 +1,11 @@
 <!-- file: crates/ksp-app-config-desk/USAGE.md -->
-<!-- version: 18 -->
+<!-- version: 19 -->
 
 # Utilisation de `ksp-app-config-desk`
 
 ## État actuel
 
-Le gabarit Rust/Tauri et le frontend Vite/TypeScript/SCSS sont présents. Le backend initialise Config, le runtime Logging et `AppState`. Les panneaux Documents, Profils et Environnement/`.env` sont fonctionnels, y compris les mutations `.env` create/update/remove et les reveals Secrets privilégiés. Logging expose maintenant un brouillon typé éditable, une persistence atomique et un hot reload runtime sans redémarrage.
+Le gabarit Rust/Tauri et le frontend Vite/TypeScript/SCSS sont présents. Le backend initialise Config, le runtime Logging et `AppState`. Les panneaux Documents, Profils et Environnement/`.env` sont fonctionnels, y compris les mutations `.env` create/update/remove et les reveals Secrets privilégiés. Logging expose maintenant un brouillon typé éditable, une persistence atomique, un hot reload sans redémarrage, un profil runtime sélectionnable indépendamment du `default_profile` et une identité de lancement observable pour isoler les fichiers persistants.
 
 La fenêtre `splash` est visible au démarrage. Après readiness du frontend et temporisation résolue par Config, l'application effectue le fade-out, affiche/focalise `main` puis détruit `splash`. La fenêtre principale expose immédiatement la navigation monofenêtre de référence.
 
@@ -212,3 +212,51 @@ La vue **Logging** appelle `get_logging_document`. Le backend charge le document
 
 Le sélecteur **Profil édité** travaille sur un brouillon local. `logs_directory`, `default_profile`, profils, console, file sinks, filtres et target overrides sont modifiables. **Créer**, **Cloner**, **Renommer** et **Supprimer** agissent d'abord sur le brouillon ; la suppression de profil est confirmée par modal Bootstrap. **Sauvegarder et appliquer** envoie un candidat typé à `save_logging_document`, qui reconstruit les contrats Config, persiste atomiquement après validation, recharge un `ConfigEnvironment` frais, résout le `default_profile` et hot-reload le `LoggingGuard`. Si le runtime ne peut pas être préparé/rechargé, l'ancien runtime reste actif et la source précédente est restaurée. **Recharger le document** resynchronise uniquement le brouillon depuis la source persistée et demande confirmation si des changements non sauvegardés existent. Les messages Cargo/Tauri/Vite affichés par `cargo tauri dev` sont externes au runtime Logging KSP et ne dépendent pas de `console.enabled`.
 
+
+
+## Runtime Logging — profil actif, génération et fichiers par lancement
+
+La section **Runtime actif** du panneau Logging ne décrit pas le brouillon : elle interroge l'état réellement installé dans `ksp-logging-lib`.
+
+Elle expose :
+
+- `active_profile` ;
+- `selection_source` : `default_profile`, `explicit` ou `fallback` ;
+- `generation` ;
+- console active/inactive ;
+- compteurs cumulés de lignes abandonnées ;
+- `application_id` ;
+- `launch_timestamp` ;
+- chaque file sink actif avec son directory, son prefix effectif et sa rotation.
+
+Au démarrage de Config Desk, l'identité de lancement est construite une seule fois avec un token de la forme :
+
+```text
+20260816-182519.123Z-p4242
+```
+
+Pour un fichier source configuré comme `debug/ksp-debug.log`, le runtime peut donc exposer un prefix comme :
+
+```text
+ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-debug.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.
+
+### Sélection explicite du profil runtime
+
+`default_profile` reste une propriété persistée de `std.logging.json`. Le sélecteur **Profil runtime à appliquer** travaille uniquement avec les profils déjà persistés et ne modifie pas ce champ.
+
+Scénario attendu avec deux profils persistés `local_dev` et `local_test` :
+
+1. garder `default_profile=local_dev` ;
+2. sélectionner `local_test` dans **Profil runtime à appliquer** ;
+3. cliquer **Appliquer le profil** ;
+4. vérifier `active_profile=local_test`, `selection_source=explicit` et `generation + 1` ;
+5. cliquer **Recharger le document** : `default_profile` doit toujours être `local_dev` ;
+6. sélectionner/appliquer `local_dev` explicitement si souhaité ;
+7. **Sauvegarder et appliquer** un document valide : le runtime revient au `default_profile` du document et `selection_source=default_profile`.
+
+Le bouton d'application explicite est désactivé lorsque le brouillon est sale afin qu'un profil affiché mais non persisté ne soit jamais confondu avec un profil réellement chargeable par Config.
+
+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.