Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.1.4-pre.001-fix.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-16 09:10:38 +02:00
parent 6bd0b4e9b5
commit 169ed47fea
2 changed files with 432 additions and 98 deletions
Download Patch File Download Diff File Expand all files Collapse all files

221
deltas/0.1.4/pre.001-fix.001.md Normal file
View File

@@ -0,0 +1,221 @@
<!-- file: deltas/0.1.4/pre.001-fix.001.md -->
<!-- version: 1 -->
# 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.

309
docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# 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 :
- <https://crates.io/crates/tauri-plugin-tracing>
- <https://crates.io/crates/ts-rs>
- <https://crates.io/crates/fs2>
- <https://github.com/fltsci/tauri-plugin-tracing>
- <https://github.com/fltsci/tauri-plugin-tracing/blob/main/package.json>
- <https://www.npmjs.com/package/@tauri-apps/api>
- <https://www.npmjs.com/package/@tauri-apps/cli>
- <https://www.npmjs.com/package/vite>
@@ -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.