From 169ed47feaf346b0ef0a8d4ad1a8e4a04a707ba7 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sun, 16 Aug 2026 09:10:38 +0200 Subject: [PATCH] v0.1.4-pre.001-fix.001 --- deltas/0.1.4/pre.001-fix.001.md | 221 +++++++++++++ docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md | 309 +++++++++++++------ 2 files changed, 432 insertions(+), 98 deletions(-) create mode 100644 deltas/0.1.4/pre.001-fix.001.md diff --git a/deltas/0.1.4/pre.001-fix.001.md b/deltas/0.1.4/pre.001-fix.001.md new file mode 100644 index 0000000..c2b757b --- /dev/null +++ b/deltas/0.1.4/pre.001-fix.001.md @@ -0,0 +1,221 @@ + + + +# Delta 0.1.4-pre.001-fix.001 — frontend tracing, panneau de test Logging et découpage des prereleases + +## Base requise + +```text +0.1.4-pre.001 +workspace.package.version = "0.1.4-pre.1" +``` + +Ce correctif est exclusivement documentaire. Il corrige le plan de `pre.001` avant son approbation et n'ouvre pas `pre.002`. + +Le delta historique `deltas/0.1.4/pre.001.md` reste inchangé. Les corrections sont portées par la révision du plan et par le présent fix, conformément à la règle KSP qui interdit de réécrire silencieusement une livraison déjà produite. + +## Objet + +Le correctif fige trois compléments demandés après lecture du plan initial : + +1. `@fltsci/tauri-plugin-tracing` est conservé comme package frontend compagnon de `tauri-plugin-tracing` au lieu d'être écarté comme dépendance inutilisée ; +2. le bridge `frontend_logging` éprouvé dans khadhroony-bot3 doit être repris/refondu afin de préserver des targets KSP explicites et de faire passer l'émission backend par `ksp-logging-lib` ; +3. le panneau Logging doit fournir un test manuel réel `message + niveau + target + domain + Log`, et la prévision des prereleases doit rester granulaire autour de tranches d'environ 15–20 minutes de travail effectif. + +Aucun code Tauri, Rust ou frontend n'est ajouté par ce fix. + +## Couple `tauri-plugin-tracing` + +L'audit du projet officiel confirme le couple d'installation : + +```text +Rust : tauri-plugin-tracing +TS : @fltsci/tauri-plugin-tracing +``` + +La version auditée reste `0.3.4` des deux côtés au moment de `pre.001`. + +KSP introduira donc les deux composants ensemble lorsque la tranche desktop correspondante sera implémentée. + +Les contraintes précédentes restent inchangées : + +- aucun `tauri-plugin-log` ; +- aucun subscriber global parallèle ; +- aucun `with_default_subscriber()` dans le plugin ; +- `ksp-logging-lib` reste propriétaire du runtime `tracing` ; +- aucune détente de la politique de targets `ksp-*` uniquement pour accepter le target vide actuellement produit par la commande JS standard du plugin. + +Les helpers officiels tels que `attachConsole`, `interceptConsole` ou `takeoverConsole` ne sont utilisés que si la tranche d'intégration confirme l'absence de boucle, double émission ou contournement du routing KSP. + +## Reprise/refonte de `frontend_logging` + +Le modèle bot3 audité utilise : + +```text +frontend_log.ts + -> FrontendLogPayload + -> invoke("emit_frontend_log") + -> wrapper central dans tauri.rs + -> service Rust +``` + +KSP reprend ce principe avec les adaptations suivantes : + +- helpers `frontendTrace` / `frontendDebug` / `frontendInfo` / `frontendWarn` / `frontendError` ; +- bridge console commun si retenu après test ; +- targets frontend normalisés/whitelistés côté Rust ; +- émission backend par la façade `ksp-logging-lib`, pas par une seconde ownership directe de `tracing` ; +- DTO applicatif TS-RS appartenant à `ksp-app-config-desk` ; +- aucune donnée issue d'un reveal Secret injectée automatiquement dans le bridge. + +Le package officiel `@fltsci/tauri-plugin-tracing` et l'adapter KSP sont donc complémentaires : le premier fournit l'intégration officielle Tauri, le second préserve les conventions/routings KSP que le bridge JS standard ne permet pas encore d'exprimer directement. + +## Panneau interactif de test Logging + +Le panneau Logging doit fournir au minimum : + +```text +Message : texte libre destiné explicitement au test +Niveau : trace | debug | info | warn | error | tous +Target : select de targets KSP contrôlés +Domain : aucun | domaine connu | personnalisé +Bouton : Log +``` + +Le mode `tous` émet la même intention aux cinq niveaux avec un identifiant commun afin de visualiser les seuils de routing. + +### Target + +Le frontend ne fournit pas une chaîne arbitraire utilisée directement comme target de callsite. Il transmet un `target_id` contrôlé. Le service Rust le mappe vers un ensemble fini de targets KSP, par exemple : + +```text +ksp-app-config-desk +ksp-app-config-desk.frontend +ksp-app-config-desk.test.logging +ksp-app-config-desk.test.config +ksp-app-config-desk.tauri +``` + +Cela permet de tester réellement les filtres `targets[]` sans créer un target dynamique arbitraire depuis la webview. + +### Domain + +Le `domain` reste un champ structuré distinct. L'UI peut proposer : + +- aucun domaine ; +- les domaines connus/utilisés par la configuration Logging active ; +- quelques domaines de test prédéfinis ; +- une valeur personnalisée. + +Le domain personnalisé ne remplace jamais le target propriétaire. + +### Commande Tauri + +Le bouton `Log` appelle une commande dédiée, conceptuellement `emit_logging_test`, dont le service : + +1. valide le niveau, le `target_id` et le domaine ; +2. sélectionne un callsite/target KSP contrôlé ; +3. émet via `ksp-logging-lib` ; +4. retourne un identifiant de test, le ou les niveaux émis, target/domain et la génération runtime active ; +5. ne recopie pas inutilement le message dans l'état backend ou le DTO de résultat. + +Le message n'est jamais prérempli depuis Config, diagnostics ou un reveal Secret. L'UI avertit explicitement que le texte sera journalisé et ne doit contenir aucune donnée sensible. + +## Validation fonctionnelle Logging renforcée + +La démonstration de clôture doit pouvoir prouver depuis l'UI : + +- filtrage par niveau ; +- filtrage par target ; +- filtrage par domain ; +- profil mono-fichier ; +- profil multi-fichiers + console ; +- sauvegarde sans apply ; +- apply/hot reload sans redémarrage ; +- changement observable du routing/format/sink avec le même message de test ; +- événement frontend identifiable passant par le bridge `frontend_log.ts` ; +- échec d'un reload invalide puis nouvel événement de test encore routé par l'ancien runtime valide. + +Le vieux probe fixe n'est donc plus l'unique preuve de fonctionnement : le panneau interactif devient un critère fonctionnel explicite. + +## Prévision souple des prereleases + +Le plan est redécoupé pour viser des tranches d'environ **15–20 minutes de travail effectif** : + +```text +pre.001 audit + plan +pre.002 Config : inventaire registre +pre.003 Config : réparation source candidate +pre.004 squelette Rust Tauri +pre.005 squelette frontend + couple plugin tracing +pre.006 bootstrap/AppState/LoggingGuard +pre.007 frontend_logging commun +pre.008 shell + splash +pre.009 Documents/diagnostics +pre.010 Profils/provenance +pre.011 Environnement +pre.012 Secrets/reveal +pre.013 Logging editor lecture/DTO +pre.014 Logging mutations/persistence +pre.015 Logging apply/hot reload +pre.016 panneau Test Logging + preuve routing +pre.017 robustesse/extensibilité/tests desktop +pre.018 clôture globale/docs/prompt/rel.001 +``` + +Ce découpage est **indicatif** : + +- une tranche trop grande est scindée ; +- une tranche triviale peut absorber le début logique de la suivante ; +- une dépendance découverte peut entraîner un réordonnancement ; +- `pre.018` n'est pas un numéro final contractuel. + +L'objectif est de conserver des deltas courts, validables et compréhensibles, pas de forcer artificiellement le développement dans un nombre fixé de prereleases. + +## Fichier modifié + +```text +docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md +``` + +Le header du plan passe de `version: 1` à `version: 2`. + +## Fichier ajouté + +```text +deltas/0.1.4/pre.001-fix.001.md +``` + +## Version Cargo + +Aucune modification de `Cargo.toml`. + +Le correctif ne touche ni code, build, runtime, Config, schema, migration ou variable d'environnement. `workspace.package.version` reste donc : + +```text +0.1.4-pre.1 +``` + +L'identifiant de livraison est : + +```text +0.1.4-pre.001-fix.001 +``` + +## Validations du correctif + +À contrôler avant livraison : + +- header `file:` / `version:` des deux fichiers ; +- absence de modification de `Cargo.toml` ; +- absence de modification de `pre.001.md` ; +- absence de nouvelle dépendance réellement ajoutée ; +- présence de `@fltsci/tauri-plugin-tracing` dans le plan de dépendances futures ; +- présence de `frontend_log.ts` dans le layout cible ; +- présence du panneau `message + niveau + target + domain + Log` ; +- présence des validations niveau/target/domain et bridge frontend ; +- prévision souple explicitement calibrée autour de 15–20 minutes par prerelease ; +- équilibre des fences Markdown ; +- archive de fix limitée au plan modifié et au nouveau delta. + +Aucune commande Cargo n'est requise spécifiquement pour ce fix documentaire. Les validations Cargo de `pre.001` restent celles déjà prévues sur le poste de développement avant validation définitive de la tranche. diff --git a/docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md b/docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md index 36955e7..90023c2 100644 --- a/docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md +++ b/docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md @@ -1,5 +1,5 @@ - + # Plan `0.1.4` — `ksp-app-config-desk` @@ -183,7 +183,9 @@ SPLASH_CLOSE_WAIT_MS = 12100 Ces timings codés en dur ne sont pas retenus. KSP introduira un réglage Config/.env résolu via `ksp-config-lib` au moment où le splash runtime sera implémenté. -Le frontend bot3 déclare aussi `@fltsci/tauri-plugin-tracing` sans l'importer. KSP ne reprend pas une dépendance frontend inutilisée par simple symétrie. +Le frontend bot3 déclare `@fltsci/tauri-plugin-tracing`, package frontend compagnon de `tauri-plugin-tracing`. L'audit du projet officiel confirme que l'installation recommandée du plugin associe bien la crate Rust et ce package NPM. KSP conserve donc ce couple lorsqu'il introduit le plugin. + +Bot3 n'utilise toutefois pas directement les helpers JS du package pour son routing applicatif : son `frontend_log.ts` appelle une commande Tauri dédiée avec un niveau, un target frontend explicite et le message. Ce principe est retenu et refondu dans KSP afin de conserver des targets KSP contrôlés et de faire passer l'émission finale par `ksp-logging-lib`. Le package officiel reste disponible pour les capacités réellement utiles du plugin, notamment l'intégration console lorsque celle-ci est compatible avec l'ownership Logging KSP. Les dépendances propres aux nombreuses démos bot3 ne sont pas retenues pour Config Desk : @@ -216,20 +218,21 @@ Le premier éditeur raw utilisera un contrôle texte natif correctement stylé ; Aucune dépendance n'est ajoutée par `pre.001`. Les versions suivantes ont été revérifiées depuis les registres/documentations officiels afin de fixer la génération candidate à réévaluer **au moment exact de l'ajout** : -| Dépendance | Version actuelle auditée | Usage envisagé | -|---------------------------------|-------------------------:|------------------------------------------| -| `tauri` | `2.11.5` | runtime desktop | -| `tauri-build` | `2.6.3` | build Tauri | -| `tauri-plugin-tracing` | `0.3.4` | intégration tracing à la frontière Tauri | -| `ts-rs` | `12.0.1` | bindings DTO applicatifs | -| `fs2` | `0.4.3` | verrou single-instance | -| `@tauri-apps/api` | `2.11.1` | frontend Tauri | -| `@tauri-apps/cli` | `2.11.4` | dev/build desktop | -| `vite` | `8.2.1` | build frontend | -| `typescript` | `7.0.2` | frontend TypeScript | -| `sass-embedded` | `1.102.0` | compilation SCSS | -| `bootstrap` | `5.3.8` | composants/layout | -| `@fortawesome/fontawesome-free` | `7.3.1` | iconographie | +| Dépendance | Version actuelle auditée | Usage envisagé | +|---------------------------------|-------------------------:|----------------------------------------------| +| `tauri` | `2.11.5` | runtime desktop | +| `tauri-build` | `2.6.3` | build Tauri | +| `tauri-plugin-tracing` | `0.3.4` | intégration tracing à la frontière Tauri | +| `ts-rs` | `12.0.1` | bindings DTO applicatifs | +| `fs2` | `0.4.3` | verrou single-instance | +| `@fltsci/tauri-plugin-tracing` | `0.3.4` | package frontend compagnon du plugin tracing | +| `@tauri-apps/api` | `2.11.1` | frontend Tauri | +| `@tauri-apps/cli` | `2.11.4` | dev/build desktop | +| `vite` | `8.2.1` | build frontend | +| `typescript` | `7.0.2` | frontend TypeScript | +| `sass-embedded` | `1.102.0` | compilation SCSS | +| `bootstrap` | `5.3.8` | composants/layout | +| `@fortawesome/fontawesome-free` | `7.3.1` | iconographie | Sources d'audit : @@ -238,6 +241,8 @@ Sources d'audit : - - - +- +- - - - @@ -273,12 +278,16 @@ Or `ksp-logging-lib` impose aux target filters configurables un prefix `ksp-` et Décision `0.1.4` : - intégrer le **plugin Rust** à la frontière Tauri sans subscriber propre ; +- intégrer son package frontend compagnon `@fltsci/tauri-plugin-tracing` dans le gabarit desktop au même moment ; - ne pas utiliser `with_default_subscriber()` ; - ne pas installer une seconde pile `tracing-subscriber` dans l'application ; -- ne pas détendre la politique `ksp-*` de `ksp-logging-lib` uniquement pour faire passer le target vide du plugin ; -- ne pas ajouter le package JS `@fltsci/tauri-plugin-tracing` tant qu'un adapter réellement fonctionnel et conforme aux targets KSP n'est pas défini ; -- pour les événements de test Logging de `0.1.4`, utiliser la façade/macros de `ksp-logging-lib` avec un target KSP contrôlé ; -- enregistrer cette incompatibilité comme point à revérifier si une nouvelle version du plugin permet un target frontend namespacé ou si KSP introduit plus tard une extension explicitement conçue de Logging. +- ne pas détendre la politique `ksp-*` de `ksp-logging-lib` uniquement pour faire passer le target vide de la commande JS standard du plugin ; +- reprendre/refondre le pont `frontend_logging` de bot3 : helpers TypeScript -> commande Tauri dédiée -> service Rust -> façade `ksp-logging-lib` ; +- normaliser/whitelister les targets frontend et de test côté Rust afin qu'un texte arbitraire reçu depuis la webview ne devienne jamais un target de callsite arbitraire ; +- utiliser le package officiel pour les fonctions réellement utiles du plugin (`attachConsole` ou autre) uniquement lorsque leur comportement reste compatible avec le runtime KSP ; +- ne pas utiliser directement `interceptConsole()` / `takeoverConsole()` comme unique pont JS -> Rust si cela produit des événements impossibles à router selon les targets KSP ; +- pour les événements de test Logging de `0.1.4`, utiliser la façade/macros de `ksp-logging-lib` avec un target KSP contrôlé et un `domain` structuré optionnel ; +- revérifier ce point lors de l'introduction réelle des dépendances, car une nouvelle version du plugin pourrait étendre son contrat frontend. `tauri-plugin-log` est **explicitement exclu**. @@ -311,6 +320,7 @@ crates/ksp-app-config-desk/ │ │ ├── main.ts │ │ ├── splash.ts │ │ ├── invoke.ts +│ │ ├── frontend_log.ts │ │ ├── state.ts │ │ └── bindings/ # généré, ignoré │ └── scss/ @@ -458,7 +468,7 @@ Affiche uniquement des informations sûres : - profil Logging runtime actif ; - génération/revision de reload ; - présence de shadowing environnement ; -- dernier résultat de probe Logging. +- dernier résultat de test Logging interactif. ### 7.2 Documents @@ -537,10 +547,54 @@ Elle ne prétend jamais modifier l'environnement du parent/process déjà hérit - sauvegarde ; - sélection d'un profil à appliquer ; - hot reload ; -- émission d'un probe contrôlé. +- émission d'événements de test contrôlés depuis l'UI. Les opérations frontend produisent des DTO applicatifs ; le service Rust reconstruit/utilise les types publics `LoggingConfigDocument` et sous-contrats de `ksp-config-lib`. Le frontend ne fabrique pas directement le JSON persistant comme source d'autorité. +### 7.6 Test Logging interactif + +Le panneau Logging comporte une zone de test manuelle destinée à prouver le routing réel du runtime actif après sauvegarde/reload. + +Contrôles minimums : + +```text +Message : texte libre explicitement destiné au log de test +Niveau : trace | debug | info | warn | error | tous +Target : select de targets KSP contrôlés +Domain : aucun | domaine connu | personnalisé +Bouton : Log +``` + +Le message n'est jamais prérempli depuis Config, un diagnostic, un reveal Secret ou un état contenant une valeur réelle. L'UI indique explicitement que le contenu sera journalisé et ne doit contenir aucune donnée sensible. + +Le mode `tous` émet le même message de test aux cinq niveaux avec un identifiant de test commun afin de visualiser immédiatement les seuils de filtrage. + +Le target n'est pas un texte Rust arbitraire. Le frontend transmet un `target_id` appartenant à une liste exposée par l'application, par exemple : + +```text +config_desk +frontend +logging_test +config_test +tauri +``` + +Le service Rust mappe ces identifiants vers des callsites/targets KSP fixes tels que : + +```text +ksp-app-config-desk +ksp-app-config-desk.frontend +ksp-app-config-desk.test.logging +ksp-app-config-desk.test.config +ksp-app-config-desk.tauri +``` + +Le `domain`, au contraire, reste un champ structuré distinct du target. Le select peut proposer les domaines utilisés par la configuration Logging chargée, des domaines de test prédéfinis et une option personnalisée. Une valeur personnalisée reste un champ d'événement et ne modifie pas le target propriétaire. + +Le bouton `Log` appelle une commande Tauri dédiée. L'émission backend utilise uniquement `ksp-logging-lib`; aucune commande applicative n'appelle directement `tracing` pour posséder le routing. Le résultat retourné à l'UI contient au minimum l'identifiant du test, les niveaux émis, le target sélectionné, le domaine sélectionné et la génération du runtime actif, mais ne recopie pas inutilement le message. + +En parallèle, le `frontend_log.ts` commun reprend/refond le mécanisme bot3 pour les logs techniques du frontend et le bridge console. Il passe par une commande `emit_frontend_log` séparée et des targets frontend whitelistés. Les deux chemins peuvent partager le même service d'émission Rust sans confondre leurs DTO et leurs responsabilités. + ## 8. Matrice commandes Tauri / services / APIs KSP Les noms ci-dessous sont les noms fonctionnels cibles ; ils pourront être normalisés avant implémentation, mais leurs responsabilités sont fixées. @@ -559,7 +613,8 @@ Les noms ci-dessous sont les noms fonctionnels cibles ; ils pourront être norma | `get_logging_editor` | `logging_service` | `load_logging_document` | non | | `save_logging_document` | `logging_service` | `save_logging_document` | non par design Logging | | `apply_logging_profile` | `logging_service` | `ConfigEnvironment::load` + `load_resolved_logging_config` + `reinitialize` | valeurs resolved possibles, jamais DTO/log | -| `run_logging_probe` | `logging_service` | macros/façade `ksp-logging-lib` | non, payload fixé | +| `emit_frontend_log` | `frontend_logging_service` | façade `ksp-logging-lib` | non, message technique frontend seulement | +| `emit_logging_test` | `logging_service` | façade/macros `ksp-logging-lib` | non, message explicitement saisi pour test | | `splash_frontend_ready` | `splash` | lifecycle Tauri + settings splash déjà résolus | non | Tous les wrappers dans `tauri.rs` : @@ -589,7 +644,10 @@ LoggingConsoleDto LoggingFileDto LoggingFilterDto LoggingRuntimeDto -LoggingProbeResultDto +FrontendLogPayloadDto +LoggingTargetOptionDto +LoggingTestRequestDto +LoggingTestResultDto ``` Règles : @@ -663,7 +721,7 @@ L'autorisation applicative retenue est donc : 4. le backend revérifie que le nom appartient bien aux namespaces KSP/KSPB et applique sa policy de reveal ; 5. seule la méthode `reveal_*` Config est appelée ; 6. la réponse n'est jamais conservée dans l'état backend ; -7. aucun log/probe ne reçoit la valeur. +7. aucun log, bridge frontend ou test Logging ne reçoit automatiquement la valeur. Cette barrière n'est pas présentée comme une ré-authentification forte contre une webview déjà compromise. Une auth OS forte éventuelle est hors scope de `0.1.4` et devra être conçue séparément si le threat model futur l'exige. @@ -687,24 +745,42 @@ Flux : La sauvegarde ne doit pas déclencher implicitement un reload. Cela permet d'éditer plusieurs profils sans changer le runtime et rend les erreurs/rollback compréhensibles. -### 11.2 Probe contrôlé +### 11.2 Événement de test interactif et séquence multi-niveaux -`run_logging_probe` ne reçoit pas un message de log libre contenant potentiellement un secret. Il émet une petite séquence contrôlée, avec un identifiant unique non sensible retourné à l'UI, par exemple : +`emit_logging_test` reçoit uniquement les valeurs explicitement saisies/sélectionnées dans le panneau de test : ```text -INFO target=ksp-app-config-desk.probe domain=config-desk -DEBUG target=ksp-app-config-desk.probe domain=config-desk -WARN target=ksp-app-config-desk.probe domain=config-desk +message +action level = trace | debug | info | warn | error | all +target_id +domain optionnel ``` -L'UI affiche l'identifiant du probe et rappelle les sinks attendus. La démonstration manuelle peut ainsi vérifier qu'après reload : +Le backend valide `target_id`, choisit un callsite KSP fixe, puis émet via `ksp-logging-lib`. Le `domain` est ajouté comme champ structuré lorsqu'il est présent. + +Chaque action reçoit un identifiant unique non sensible. En mode `all`, le backend émet la même intention de test aux cinq niveaux afin de tester le seuil de chacun des sinks. + +Exemple de campagne manuelle : + +```text +message = "routing-test-42" +target = ksp-app-config-desk.test.logging +domain = logging.hot-reload +level = all +``` + +La démonstration peut ainsi vérifier qu'après reload : - un sink apparaît/disparaît ; - un format change ; - un niveau/routing change ; +- un target est accepté/refusé par un output ; +- un domain est accepté/refusé par un output ; - la console reçoit ou non l'événement ; - un fichier distinct reçoit l'événement correspondant. +Le bridge technique `frontend_log.ts` est testé séparément avec au moins un événement frontend identifiable afin de prouver que les logs de la webview rejoignent le même runtime KSP sans seconde pile de logging. + ### 11.3 Profil invalide Test obligatoire : @@ -713,7 +789,7 @@ Test obligatoire : runtime A valide actif -> tentative apply B invalide -> erreur --> probe suivant toujours routé selon A +-> événement de test suivant toujours routé selon A ``` La réussite de ce scénario ferme le critère « une erreur de nouvelle configuration ne détruit pas le runtime Logging déjà valide ». @@ -722,18 +798,22 @@ La réussite de ce scénario ferme le critère « une erreur de nouvelle configu La release ne peut pas être clôturée sans preuve des cas suivants : -| Cas | Action UI | Résultat attendu | -|-----|-------------------------------|-----------------------------------------------------------------| -| L1 | créer un second profil | profil ajouté via types Config et sauvegardable | -| L2 | modifier le profil existant | mutation persistée via `save_logging_document()` | -| L3 | profil mono-fichier | console optionnelle + exactement un sink fichier valide | -| L4 | profil multi-fichiers | au moins deux sinks fichier distincts + sortie logiciel/console | -| L5 | sauvegarder sans appliquer | source change, runtime reste inchangé | -| L6 | sélectionner/appliquer profil | `load_resolved_logging_config` + `reinitialize` réussissent | -| L7 | probe avant/après | changement de routing/format/sink observable sans redémarrage | -| L8 | appliquer config invalide | erreur visible, runtime précédent reste fonctionnel | -| L9 | redémarrer l'app | profil/default persisté retrouvé selon le document sauvegardé | -| L10 | modifier default profile | nouveau `default_profile` validé/persisté par Config | +| Cas | Action UI | Résultat attendu | +|-----|-------------------------------|--------------------------------------------------------------------------------| +| L1 | créer un second profil | profil ajouté via types Config et sauvegardable | +| L2 | modifier le profil existant | mutation persistée via `save_logging_document()` | +| L3 | profil mono-fichier | console optionnelle + exactement un sink fichier valide | +| L4 | profil multi-fichiers | au moins deux sinks fichier distincts + sortie logiciel/console | +| L5 | sauvegarder sans appliquer | source change, runtime reste inchangé | +| L6 | sélectionner/appliquer profil | `load_resolved_logging_config` + `reinitialize` réussissent | +| L7 | message + niveau avant/après | changement de routing/format/sink observable sans redémarrage | +| L8 | changer target de test | routing target observable selon la configuration active | +| L9 | changer domain de test | routing domain observable selon la configuration active | +| L10 | mode `tous` | seuils trace/debug/info/warn/error vérifiables en une campagne | +| L11 | log frontend via bridge | événement frontend identifiable rejoint le runtime KSP | +| L12 | appliquer config invalide | erreur visible, runtime précédent reste fonctionnel et le bouton Log le prouve | +| L13 | redémarrer l'app | profil/default persisté retrouvé selon le document sauvegardé | +| L14 | modifier default profile | nouveau `default_profile` validé/persisté par Config | La démonstration de clôture conservera deux profils de test reproductibles, sans dépendre de données secrètes. @@ -854,7 +934,8 @@ Tests ciblés : - mapping DTO Logging -> contrats Config ; - AppState : metadata runtime ne change qu'après reload réussi ; - policy reveal ; -- probe : payload fixe ; +- test Logging : validation niveau/target_id/domain, mapping vers callsites KSP fixes et mode multi-niveaux ; +- frontend logging : normalisation des targets whitelistés et dispatch par niveau ; - splash settings : bornes et lifecycle ; - single-instance helper lorsque testable sans flakiness. @@ -936,95 +1017,121 @@ Côté frontend, les commandes de build/test retenues seront ajoutées au `packa ## 18. Prévision souple des prereleases -Chaque tranche vise environ 15–20 minutes de travail effectif. Cette prévision est un ordre de travail, pas un plafond contractuel. +Chaque prerelease vise **environ 15–20 minutes de travail effectif**. Cette prévision est volontairement souple : une tranche peut être scindée si elle dépasse nettement ce budget, fusionnée avec la suivante si elle se révèle triviale, ou réordonnée si une dépendance technique est découverte. Le numéro exact de la dernière prerelease n'est donc pas contractuel. + +Découpage candidat : ```text pre.001 audit + brainstorming + plan détaillé -pre.002 compléter ksp-config-lib pour Config Desk - - vue publique du registre - - réparation source validée/atomique par file_id - - tests + docs Config ciblés +pre.002 Config — inventaire public du registre + - API read-only des descripteurs + - ordre déterministe + - tests unitaires/publics + - README/USAGE/TODO Config si nécessaire -pre.003 créer ksp-app-config-desk +pre.003 Config — réparation source candidate + - API bornée par file_id + - parse/schema/sémantique avant persistence + - atomicité/no-write-on-error + - tests + docs ciblés + +pre.004 squelette Rust Tauri - membre workspace - Cargo lib+bin/build.rs - - package frontend/Vite/TS/SCSS minimal - - tauri.conf/capabilities/icône de base + - main.rs/lib.rs/tauri.rs minimaux + - tauri.conf/capabilities/icône - single-instance - - plugin tracing Rust sans subscriber propre -pre.004 bootstrap backend + AppState - - argv -> bootstrap/registry/engine/management +pre.005 squelette frontend/gabarit + - package.json + Vite/TypeScript + - SCSS/Bootstrap/Font Awesome + - @fltsci/tauri-plugin-tracing avec plugin Rust + - main/splash HTML+TS minimaux + - build frontend de base + +pre.006 bootstrap backend + AppState + - argv -> Config bootstrap/registry/management - initialisation Logging - - fallback sûr si Logging source invalide + - fallback sûr si std.logging invalide - LoggingGuard durable - erreurs/DTO communs -pre.005 shell main + splash de référence - - lifecycle splash - - timing via Config/.env - - .env.example dans le même delta - - navigation monofenêtre - - gabarit SCSS/Bootstrap/Font Awesome +pre.007 frontend logging commun + - frontend_log.ts repris/refondu depuis bot3 + - emit_frontend_log centralisé dans tauri.rs + - targets frontend whitelistés + - émission via ksp-logging-lib + - intégration console plugin compatible seulement -pre.006 Documents + diagnostics - - inventaire générique - - catégories d'erreurs +pre.008 shell main + splash de référence + - lifecycle splash configurable + - variable(s) Config/.env + .env.example même delta + - navigation monofenêtre + - helpers communs show/focus + +pre.009 Documents + diagnostics + - inventaire générique par registre + - catégories JSON/schema/sémantique/effective - source brut invalide - réparation via Config -pre.007 Profils + provenance +pre.010 Profils + provenance - default_profile - sélection explicite - - global/profile/effective/provenance sûre + - global/profile/effective + - provenance sûre -pre.008 Environnement - - rapports desired/effective/shadow +pre.011 Environnement + - desired/effective/source/shadow - set/remove .env - - messages process shadowing + - feedback process shadowing -pre.009 Secrets privilégiés +pre.012 Secrets privilégiés - DTO séparés - - UX confirmation/reveal transitoire + - confirmation explicite + - reveal transitoire - audits non-divulgation -pre.010 Logging editor — contrats - - DTO typés - - profils/console/files/filters - - mapping vers types management Config +pre.013 Logging editor — lecture/DTO + - document/profils/console/files/filters + - targets/domains + - mapping types Config -> DTO -pre.011 Logging editor — opérations/persistence +pre.014 Logging editor — mutations/persistence - create/clone/rename/delete profils - default_profile - mono-fichier/multi-fichiers - save_logging_document -pre.012 Logging runtime +pre.015 Logging runtime - sélection profil à appliquer - ConfigEnvironment frais - - reinitialize - - metadata runtime transactionnelle - - probe contrôlé + - load_resolved_logging_config + - reinitialize + metadata transactionnelle + - rollback runtime validé -pre.013 matrice fonctionnelle Logging - - cas mono-fichier - - cas multi-fichiers + console - - save sans apply - - hot reload observable - - reload invalide -> ancien runtime conservé +pre.016 panneau Test Logging + - champ message + - niveau trace/debug/info/warn/error/tous + - select target KSP contrôlé + - domain absent/connu/personnalisé + - bouton Log -> commande Tauri + - preuve routing avant/après hot reload + - preuve bridge frontend -pre.014 robustesse desktop/extensibilité - - diagnostics invalid source au démarrage +pre.017 robustesse/extensibilité/tests desktop + - invalid source au démarrage - audits secrets/Config ownership/tracing - tests frontend/Tauri/build - - vérification ajout futur file_id/editor + - ajout futur file_id/editor sans refonte shell -pre.015 clôture +pre.018 clôture - fmt/check/clippy - - tests package + cargo test --workspace + - tests ciblés + cargo test --workspace - cargo tree pertinents - build frontend/Tauri + - matrice fonctionnelle complète - README.md + USAGE.md finalisés - aucun PRESENTATION.md - TODO fermés/reportés @@ -1032,7 +1139,7 @@ pre.015 clôture - préparation rel.001 ``` -Une tranche qui dépasse clairement le budget sera scindée plutôt que comprimée. Un défaut livré est corrigé par un `fix` conformément au workflow KSP. +Ce découpage est une **prévision**, pas une obligation de produire exactement dix-huit prereleases. Lorsqu'une tranche atteint son objectif en moins de temps, elle peut absorber le début logique de la suivante ; lorsqu'elle dépasse 20 minutes de façon significative, elle doit préférentiellement être scindée plutôt que compressée. Un défaut déjà livré est corrigé par un `fix` conformément au workflow KSP. ## 19. Dépendances et ordre d'introduction @@ -1057,6 +1164,7 @@ ts-rs ### Frontend ```text +@fltsci/tauri-plugin-tracing @tauri-apps/api @tauri-apps/cli vite @@ -1085,6 +1193,8 @@ La politique KSP sans lockfile versionné reste inchangée. - aucun `tauri-plugin-log` ; - aucun subscriber tracing parallèle ; - plugin tracing intégré sans `with_default_subscriber()` ; +- package frontend compagnon `@fltsci/tauri-plugin-tracing` intégré avec le gabarit ; +- bridge `frontend_log.ts` KSP présent, targets frontend contrôlés, aucune seconde pile `log` ; - Logging runtime possédé par `ksp-logging-lib`. ### Documents/profils @@ -1112,8 +1222,10 @@ La politique KSP sans lockfile versionné reste inchangée. - sauvegarde fonctionnelle ; - profil sélectionnable/appliquable ; - hot reload observable sans redémarrage ; -- probe contrôlé ; -- échec reload laisse ancien runtime actif. +- panneau de test `message + niveau + target + domain + Log` fonctionnel ; +- mode multi-niveaux permettant de tester les seuils ; +- bridge frontend réellement observable dans le runtime KSP ; +- échec reload laisse ancien runtime actif et le panneau de test le démontre. ### Extensibilité @@ -1144,7 +1256,8 @@ crates/ksp-app-config-desk/USAGE.md - reveal secrets ; - panneau Logging ; - sauvegarde/application ; -- probe/hot reload ; +- test Logging interactif/hot reload ; +- bridge frontend Logging ; - diagnostics usuels. Il n'y aura pas de `PRESENTATION.md` dans `0.1.4` tant qu'aucune vue de présentation n'existe. @@ -1157,6 +1270,6 @@ Aucune question n'empêche d'ouvrir le développement après validation du prés 2. nom exact et nombre minimal de variables splash Config/.env ; 3. features Cargo minimales de Tauri/Tokio nécessaires au shell/splash ; 4. détails du fallback Logging minimal utilisé uniquement lorsque la Config Logging ne peut pas être résolue au démarrage ; -5. possibilité d'exploiter une évolution future de `tauri-plugin-tracing` permettant un target JS namespacé `ksp-*` sans affaiblir Logging. +5. usage exact des helpers console de `@fltsci/tauri-plugin-tracing` (`attachConsole`, `interceptConsole`, `takeoverConsole`) compatible avec le bridge KSP sans boucle/double émission ; si la version introduite permet un target JS namespacé `ksp-*`, l'adapter pourra être simplifié sans affaiblir Logging. Ces points doivent être résolus par code/tests dans les prereleases prévues, pas par contournement applicatif.