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

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.