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

v0.2.6-pre.014

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-22 00:21:14 +02:00
parent c07db925b1
commit 6907e4bbb8
39 changed files with 1544 additions and 370 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/IDEAS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/IDEAS.md -->
<!-- version: 19 -->
<!-- version: 20 -->
# Idées à explorer
@@ -202,6 +202,14 @@ Formats/cibles à inventorier et prioriser selon usage réel :
Chaque format doit être étudié côté sécurité, round-trip, secret/public, dépendances et compatibilité avant engagement.
### Conteneur binaire `.kspwallet` et formats logiques futurs
**Status :** Retenu pour audit en `0.2.7` / facteurs futurs à explorer
Le JSON V1 actuel est un format d’interop lisible. Base64 seul n’apporte aucune sécurité et resterait un texte trivialement décodable avec environ un tiers de surcharge. `0.2.7` doit donc étudier un **conteneur de persistence binaire versionné** séparé du `format_version` logique/cryptographique : magic/framing explicite, lecture rétrocompatible du JSON V1 historique, écriture binaire par défaut après validation, migration explicite et test vectors. Le choix du codec/framing exact est audité avant engagement ; il ne doit pas casser les transcripts/AAD, VIEW/OWNER, keypair ou import/export.
Un futur `format_version >= 2` pourra introduire d’autres modèles d’autorisation, notamment password + facteur supplémentaire. `ksp-wallet-lib` restera propriétaire du format, des challenges et de la vérification, mais toute interaction réelle (OTP, enrollment/recovery, hardware/WebAuthn, validation distante) exigera une évolution de Wallet Desk ou du client concerné. Un seed TOTP stocké uniquement dans le même fichier que le wallet ne doit pas être présenté automatiquement comme un second facteur indépendant contre un attaquant possédant ce fichier.
## Pipelines
### Pas de pipeline monolithique

17
docs/architecture/004-COMPONENT_INVENTORY.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Inventaire initial des composants KSP
@@ -26,13 +26,14 @@ Ce document maintient l'inventaire synthétique des composants retenus ou presse
| On-chain HTTP | `ksp-onchain-transport-lib` | lib | Stable | `0.2.1`–`0.2.4` | HTTP standard complet : 52/52 current + 14/14 historical |
| Wallet | `ksp-wallet-lib` | lib | Stable | `0.2.5` | `.kspwallet`, VIEW/OWNER, secrets, signature, import/export |
| Wallet Desk | `ksp-app-wallet-desk` | app | Retenu | `0.2.6` | Wallet + Config composite + HTTP/balance |
| Standard WS | `ksp-onchain-transport-lib` | lib | Retenu | `0.2.7` | WebSocket Solana complet, sessions/subscriptions |
| Helius WS | `ksp-onchain-transport-lib` | lib | Retenu | `0.2.8` | LaserStream WebSocket comme extension du moteur standard |
| Yellowstone | `ksp-onchain-transport-lib` | lib | Pressenti | `0.2.9` | client gRPC standard/provider-neutral |
| Off-chain price | `ksp-offchain-transport-lib` | lib | Retenu | `0.2.10` | première abstraction/provider de prix SOL/USD, SOL/EUR |
| Price Desk | nom à fixer | app | Retenu | `0.2.11` | visualisation/validation des prix + intégration Wallet Desk |
| Wire | `ksp-interface-lib` | lib | Retenu | `0.2.12` | façade wire officielle + API publique wire |
| Program API | `ksp-program-api` | API | Retenu | `0.2.13` | contrats extensibles Program |
| Wallet persistence | `ksp-wallet-lib` | lib | Retenu | `0.2.7` | conteneur binaire rétrocompatible autour du payload V1 |
| Standard WS | `ksp-onchain-transport-lib` | lib | Retenu | `0.2.8` | WebSocket Solana complet, sessions/subscriptions |
| Helius WS | `ksp-onchain-transport-lib` | lib | Retenu | `0.2.9` | LaserStream WebSocket comme extension du moteur standard |
| Yellowstone | `ksp-onchain-transport-lib` | lib | Pressenti | `0.2.10` | client gRPC standard/provider-neutral |
| Off-chain price | `ksp-offchain-transport-lib` | lib | Retenu | `0.2.11` | première abstraction/provider de prix SOL/USD, SOL/EUR |
| Price Desk | nom à fixer | app | Retenu | `0.2.12` | visualisation/validation des prix + intégration Wallet Desk |
| Wire | `ksp-interface-lib` | lib | Retenu | `0.2.13` | façade wire officielle + API publique wire |
| Program API | `ksp-program-api` | API | Retenu | `0.2.14` | contrats extensibles Program |
| Program impl. | `ksp-program-lib` | lib | Retenu | vertical slices ultérieurs | implementations Program officielles |
| Program extension | `ksp-program-<name>-lib` | lib externe | À la demande | dès besoin | implementation externe de `ksp-program-api` |
| Store API | `ksp-store-api` | API | Retenu | `0.3.1` | contrats persistence backend-agnostic, RAW d'abord |

39
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 74 -->
<!-- version: 75 -->
# Séquence des releases fonctionnelles KSP
@@ -361,13 +361,14 @@ Par défaut :
0.2.4 HTTP Blocks + Economics + compliance complète
0.2.5 wallet foundation (.kspwallet)
0.2.6 Wallet Desk
0.2.7 standard Solana WebSocket
0.2.8 Helius LaserStream WebSocket
0.2.9 Yellowstone gRPC standard foundation
0.2.10 off-chain price transport
0.2.11 price visualization desk + intégration prix dans Wallet Desk
0.2.12 interface/wire foundation
0.2.13 program-api foundation
0.2.7 .kspwallet binary persistence container
0.2.8 standard Solana WebSocket
0.2.9 Helius LaserStream WebSocket
0.2.10 Yellowstone gRPC standard foundation
0.2.11 off-chain price transport
0.2.12 price visualization desk + intégration prix dans Wallet Desk
0.2.13 interface/wire foundation
0.2.14 program-api foundation
```
`0.2.1-pre.001` a appliqué le gate de sizing et refusé le scope HTTP monolithique initial : l'inventaire du 2026-08-17 contient 52 méthodes courantes et 14 méthodes Deprecated historiques. Ce premier delta avait réparti la couverture typée sur `0.2.1`–`0.2.6`. `0.2.1-pre.001-fix.001` recalibre ensuite les 48 méthodes restantes sur trois releases complémentaires `0.2.2`–`0.2.4`, soit trois sessions nominales au maximum si chaque release utilise sa session complète. Si une release se clôt plus vite que prévu, la même session peut enchaîner la suivante après clôture complète de la précédente et nouveau gate de sizing positif. Un Wallet Desk utile doit pouvoir lire le solde du wallet : `getBalance` fait donc partie des quatre canaris de la foundation `0.2.1`, avant Wallet. Les transports live arrivent ensuite ; Interface/Program restent préparés avant les couches de données décodées.
@@ -448,17 +449,23 @@ rel.001 publication stable 0.2.6
La tranche `pre.014` est réservée aux défauts visuels/templating observés en usage réel, notamment les scrollbars occasionnelles du splashscreen ; son contenu précis sera borné à partir du retour opérateur avant implémentation. `ROADMAP.md` reste synthétique et `CHANGELOG.md` n'est synchronisé qu'à la phase documentaire finale.
## `0.2.7` — WebSocket Solana standard
## `0.2.7` — `.kspwallet` binary persistence container
Mission : faire évoluer uniquement la couche de persistence de `ksp-wallet-lib` afin qu’un `.kspwallet` nouvellement écrit ne soit plus un document JSON directement lisible dans un éditeur texte ordinaire, sans prétendre ajouter de sécurité cryptographique par simple obfuscation.
Le gate `pre.001` doit comparer framing binaire custom, codecs binaires stables et éventuelle compression, puis fixer un conteneur explicitement versionné. Base64 seul est exclu comme solution : il reste textuel, trivialement réversible et augmente la taille. Le conteneur et le `format_version` logique/cryptographique sont séparés afin de conserver V1 pour les semantics VIEW/OWNER actuelles et de réserver les futurs formats logiques à de vraies évolutions d’autorisation. La lecture rétrocompatible des JSON V1 historiques et les migrations/test vectors sont obligatoires. Wallet Desk ne doit pas être modifié fonctionnellement ; ses tests/smokes sont rejoués comme preuve consommateur.
## `0.2.8` — WebSocket Solana standard
Mission : couvrir la surface WebSocket standard officielle ciblée.
Une URL peut avoir plusieurs sessions physiques ; une session peut avoir plusieurs subscriptions. Un pool automatique de sessions est reporté jusqu'à besoin concret.
## `0.2.8` — Helius LaserStream WebSocket
## `0.2.9` — Helius LaserStream WebSocket
Mission : étendre le moteur WebSocket standard avec les opérations/filtres/capabilities Helius ciblés sans copier le client.
## `0.2.9` — Yellowstone gRPC standard
## `0.2.10` — Yellowstone gRPC standard
Mission : introduire un backend Yellowstone standard/provider-neutral.
@@ -466,21 +473,21 @@ Le `pre.001` est un gate de sizing : inventorier toute la surface normative cibl
Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après les priorités fondatrices.
## `0.2.10` / `0.2.11` — Off-chain price + app
## `0.2.11` / `0.2.12` — Off-chain price + app
`0.2.10` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
`0.2.11` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
`0.2.11` ajoute une petite application desk de visualisation/validation. Après stabilisation de cette application spécialisée, la même release doit intégrer la capacité de prix offchain dans `ksp-app-wallet-desk` sans dupliquer la récupération/normalisation appartenant au composant spécialisé.
`0.2.12` ajoute une petite application desk de visualisation/validation. Après stabilisation de cette application spécialisée, la même release doit intégrer la capacité de prix offchain dans `ksp-app-wallet-desk` sans dupliquer la récupération/normalisation appartenant au composant spécialisé.
Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.
## `0.2.12` — Interface foundation
## `0.2.13` — Interface foundation
`ksp-interface-lib` devient la façade wire officielle et expose une API publique wire utilisable par les implementations officielles et externes.
Aucune `ksp-interface-api` séparée n'est retenue pour l'instant.
## `0.2.13` — Program API foundation
## `0.2.14` — Program API foundation
Introduire `ksp-program-api`, sans suffixe `-lib`, comme contrat d'extension Program.

28
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: 26 -->
<!-- version: 27 -->
# Plan `0.1.4` — `ksp-app-config-desk`
@@ -233,7 +233,7 @@ Les artefacts frontend construits doivent être séparés des sources. Pour `ksp
Cette valeur est utilisée par `build.frontendDist` dans `tauri.conf.json`. `vite.config.ts` utilise la même destination comme `build.outDir` depuis son introduction en `pre.005`. Elle remplace le `../dist`/`../../dist` historique du gabarit bot3.
La gestion npm distingue le runtime frontend du tooling. Les bibliothèques consommées par le bundle appartiennent à `dependencies`; les outils de compilation/développement (`@tauri-apps/cli`, Vite, TypeScript, Sass) et les paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Pour la première installation, l'opérateur se place dans `crates/ksp-app-config-desk`, exécute `npm i -D`, puis revient à la racine avec `cd ../../`. Le cycle normal de développement et de build passe ensuite par Tauri depuis la racine du workspace, avec configuration explicite de l'application : `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json` et `cargo tauri build -c crates/ksp-app-config-desk/tauri.conf.json`. Tauri déclenche lui-même `npm run dev` / `npm run build` au travers des hooks configurés. Aucun lockfile npm n'est versionné.
La gestion npm distingue le runtime frontend du tooling. Les bibliothèques consommées par le bundle appartiennent à `dependencies`; les outils de compilation/développement (`@tauri-apps/cli`, Vite, TypeScript, Sass) et les paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Pour la première installation, l'opérateur se place dans `crates/ksp-app-config-desk` et exécute `npm i -D`. Le cycle normal de développement et de build reste ensuite crate-local : `(cd crates/ksp-app-config-desk && cargo tauri dev)` et `(cd crates/ksp-app-config-desk && cargo tauri build)`. `-c/--config` n'est pas utilisé pour sélectionner l'application car Tauri le traite comme un overlay de configuration. Tauri déclenche lui-même `npm run dev` / `npm run build` au travers des hooks configurés. Aucun lockfile npm n'est versionné.
Chaque application Tauri desk KSP reçoit un couple de ports Vite/HMR propre. La première application réserve :
@@ -944,24 +944,25 @@ fade duration
close delay si techniquement distinct
```
`pre.008` fige les deux clés communes nécessaires au lifecycle de référence :
`0.2.6-pre.014` aligne les deux Desks sur trois clés communes, en reprenant la séparation fonctionnelle du splash kbot3 :
```text
KSP_DESK_SPLASH_FADE_IN_MS=300
KSP_DESK_SPLASH_MINIMUM_MS=1200
KSP_DESK_SPLASH_FADE_MS=300
KSP_DESK_SPLASH_FADE_OUT_MS=300
```
Elles sont résolues uniquement via `ConfigEnvironment` avec priorité process > `.env` > fallback. `KSP_DESK_SPLASH_MINIMUM_MS` est bornée à 60 000 ms et `KSP_DESK_SPLASH_FADE_MS` à 10 000 ms. Une valeur invalide ne doit pas rendre Config Desk inutilisable : l’application conserve les timings de fallback en mémoire, journalise seulement domaine/code de l’erreur et laisse la future surface `.env` permettre la réparation.
Elles sont résolues uniquement via `ConfigEnvironment` avec priorité process > `.env` > fallback. `KSP_DESK_SPLASH_MINIMUM_MS` est bornée à 60 000 ms et chaque fade à 10 000 ms. Une valeur invalide ne rend pas Config Desk inutilisable : l’application conserve les timings de fallback en mémoire et journalise seulement domaine/code de l’erreur.
Le frontend ne reçoit que la durée d’animation réellement nécessaire dans les ordres du splash; la durée minimale reste backend. La référence temporelle est la readiness frontend : Rust émet `fade_in`, attend `minimum`, émet `fade_out`, attend `fade`, puis affiche/focalise `main` et détruit `splash`. Aucun close delay distinct n’est nécessaire. Avec `minimum=12000` et `fade=3000`, le lifecycle backend attendu est donc proche de `15000 ms`, et non des trois délais indépendants historiques de bot3. `tw_splash` journalise en `debug` la provenance des valeurs, les attentes configurées et réellement observées ainsi que la durée totale. Les variables sont ajoutées à `.env.example` dans `pre.008`.
Le frontend reçoit uniquement les durées d’animation nécessaires dans les ordres du splash; la durée minimale reste backend. Après readiness frontend, Rust émet `fade_in`, attend `fade_in`, maintient la splash pleinement visible pendant `minimum`, émet `fade_out`, attend `fade_out`, puis affiche/focalise `main` et détruit `splash`. Avec `fade_in=3000`, `minimum=12000` et `fade_out=3000`, le lifecycle backend attendu est proche de `18000 ms`. Le splash possède en outre le flux de messages généraux en bas et le flux diagnostic debug en haut repris du comportement kbot3.
### 13.3 Racine runtime en développement
Avec le workflow workspace `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json`, Tauri peut lancer le binaire Rust avec la crate applicative comme current working directory. Les defaults Config `config/`, `config/schemas/` et `.env` sont cependant des chemins de projet enracinés à la racine du workspace. En build debug, le launcher replace donc le CWD sur `env!("CARGO_MANIFEST_DIR")/../..` **avant** le bootstrap Config. Il ne lit aucune ressource KSP lui-même ; `ksp-config-lib` continue à gérer paths, `.env`, precedence et validation. Un runtime distribué ne doit pas dépendre de cette racine source et sera cadré séparément.
Avec le workflow crate-local `(cd crates/ksp-app-config-desk && cargo tauri dev)`, Tauri lance le projet applicatif attendu et le binaire Rust démarre avec la crate applicative comme current working directory. Les defaults Config `config/`, `config/schemas/` et `.env` sont cependant des chemins de projet enracinés à la racine du workspace. En build debug, le launcher replace donc le CWD sur `env!("CARGO_MANIFEST_DIR")/../..` **avant** le bootstrap Config. Il ne lit aucune ressource KSP lui-même ; `ksp-config-lib` continue à gérer paths, `.env`, precedence et validation. Un runtime distribué ne doit pas dépendre de cette racine source et sera cadré séparément.
### 13.4 Header et navigation
Le logo de Config Desk porte déjà l’identité graphique KSP. Le header ne répète donc pas `KSP` en texte : il suit `Config Desk — <vue active>`. Les cinq commandes principales restent des tabs/pills alignées à droite tant que leur nombre reste compact ; les futures applications qui dépassent cette surface utiliseront un dropdown. Les clics/changements de tabs sont tracés (`trace` pour le clic/état technique, `debug` pour l’activation utilisateur significative).
Le logo de Config Desk porte déjà l’identité graphique KSP. Le header ne répète donc pas `KSP` en texte : il suit `Config Desk — <vue active>`. Les cinq commandes principales utilisent désormais des pills verticales dans une sidebar du contenu principal, alignées avec Wallet Desk ; le header conserve uniquement l'identité fonctionnelle et le titre de la vue active. Les clics/changements de tabs sont tracés (`trace` pour le clic/état technique, `debug` pour l’activation utilisateur significative).
## 14. Présentation et Markdown
@@ -1029,7 +1030,7 @@ Le shell applicatif matérialise désormais cette architecture dans `frontend/ts
Le bootstrap Logging sépare également la **résolution du plan de démarrage** de l'**installation du subscriber**. Une source invalide peut ainsi être testée comme plan fallback sans initialiser le subscriber global du binaire de tests.
La validation frontend de `pre.018` utilise `npm run check` pour **`tsc --noEmit` uniquement**. Le build Vite de production n'est pas lancé séparément : `cargo tauri build` déclenche déjà `npm run build` via `beforeBuildCommand`. Pour KSP, le build Tauri est réservé à la **dernière validation**, après `fmt/check/clippy`, les tests, le type-check frontend et le parcours fonctionnel `tauri dev`.
La convention desktop actuelle n’exécute plus de script npm de contrôle/dev/build directement côté opérateur. Tauri possède le cycle applicatif et déclenche `npm run dev` / `npm run build` via ses hooks crate-local. Le build Tauri reste réservé à la **dernière validation**, après `fmt/check/clippy`, les tests et le parcours fonctionnel `cargo tauri dev`.
## 16. Stratégie de tests
@@ -1200,7 +1201,7 @@ pre.007 frontend logging commun
pre.008 shell main + splash de référence
- tw_splash + tw_main
- lifecycle splash configurable
- KSP_DESK_SPLASH_MINIMUM_MS / KSP_DESK_SPLASH_FADE_MS + .env.example
- KSP_DESK_SPLASH_FADE_IN_MS / KSP_DESK_SPLASH_MINIMUM_MS / KSP_DESK_SPLASH_FADE_OUT_MS + .env.example
- normalisation du CWD debug vers la racine workspace avant bootstrap Config
- navigation monofenêtre + header `Config Desk — <vue>`
- helpers show/focus/destroy
@@ -1456,3 +1457,10 @@ Aucune question n'empêche d'ouvrir le développement après validation du prés
5. retour Rust -> console WebKit : étudié à la clôture `pre.019` puis **reporté hors `0.1.4`**. Le bridge WebView -> Rust -> KSP et le panneau Test Logging couvrent le besoin fonctionnel de cette release. Une future réflexion Rust -> WebKit devra rester sous ownership de `ksp-logging-lib`, sans second subscriber, double émission ni boucle avec le bridge `console.*`.
Ces points doivent être résolus par code/tests dans les prereleases prévues, pas par contournement applicatif.
### Harmonisation desktop `0.2.6-pre.014`
Le polish partagé avec Wallet Desk déplace les pills de navigation Config dans une sidebar verticale du contenu principal, tout en conservant la palette claire historique de Config Desk. Les quatre fichiers HTML des deux Desks utilisent les en-têtes normalisés `file/version`. Le splash reprend les flux kbot3 (messages généraux en bas, diagnostics debug en haut) avec trois timings Config-owned distincts `KSP_DESK_SPLASH_FADE_IN_MS`, `KSP_DESK_SPLASH_MINIMUM_MS` et `KSP_DESK_SPLASH_FADE_OUT_MS`.
Le même chantier corrige le lancement Tauri multi-app : chaque app est lancée depuis sa crate, car `-c/--config` est un overlay et non un sélecteur de backend.

49
docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md -->
<!-- version: 30 -->
<!-- version: 31 -->
# Plan `0.2.6` — Wallet Desk
@@ -1137,7 +1137,7 @@ cd ../..
Le cycle normal de développement/validation frontend passe par Tauri depuis la racine du workspace :
```bash
cargo tauri dev -c crates/ksp-app-wallet-desk/tauri.conf.json
(cd crates/ksp-app-wallet-desk && cargo tauri dev)
```
Tauri déclenche alors automatiquement le script configuré dans `beforeDevCommand`. Les contrôles fonctionnels frontend à forte valeur portent notamment sur :
@@ -1754,7 +1754,7 @@ cd ../..
Le parcours normal de développement et de validation fonctionnelle frontend passe par :
```bash
cargo tauri dev -c crates/ksp-app-wallet-desk/tauri.conf.json
(cd crates/ksp-app-wallet-desk && cargo tauri dev)
```
Tauri exécute automatiquement le `beforeDevCommand` configuré. Aucun script npm applicatif de contrôle, développement ou build n'est lancé directement par l'opérateur.
@@ -1768,11 +1768,11 @@ cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-wallet-desk
cargo test --workspace
cargo tauri dev -c crates/ksp-app-wallet-desk/tauri.conf.json
cargo tauri build -c crates/ksp-app-wallet-desk/tauri.conf.json
(cd crates/ksp-app-wallet-desk && cargo tauri dev)
(cd crates/ksp-app-wallet-desk && cargo tauri build)
```
`cargo tauri build -c crates/ksp-app-wallet-desk/tauri.conf.json` reste **la toute dernière opération** de validation. Il déclenche lui-même le build frontend via `beforeBuildCommand`. Le smoke Devnet opt-in est exécuté séparément avant cette dernière opération lorsqu'il appartient au checkpoint final.
`(cd crates/ksp-app-wallet-desk && cargo tauri build)` reste **la toute dernière opération** de validation. Il déclenche lui-même le build frontend via `beforeBuildCommand`. Le smoke Devnet opt-in est exécuté séparément avant cette dernière opération lorsqu'il appartient au checkpoint final.
## 26. Hors périmètre confirmé
@@ -1793,11 +1793,11 @@ RPC direct depuis frontend
prix offchain pendant 0.2.6
```
## 27. TODO `0.2.11` — intégration prix offchain
## 27. TODO `0.2.12` — intégration prix offchain
La visualisation de prix reste hors `0.2.6`.
Une application spécialisée doit d'abord valider les sources offchain, normalisation, cache, rafraîchissement et UX. Ensuite `0.2.11` intégrera cette capacité dans Wallet Desk via le composant partagé retenu, sans dupliquer la logique de récupération de prix.
Une application spécialisée doit d'abord valider les sources offchain, normalisation, cache, rafraîchissement et UX. Ensuite `0.2.12` intégrera cette capacité dans Wallet Desk via le composant partagé retenu, sans dupliquer la logique de récupération de prix.
Aucune API fictive de prix n'est introduite dans Wallet Desk en `0.2.6`.
@@ -1839,3 +1839,36 @@ v0.2.6-pre.001-fix.002
```
Après application/commit du fix documentaire, `pre.002` démarre la crate Tauri et le shell complet du gabarit, avec Bootstrap, Font Awesome, DataTables/Select, SimpleBar, resize-observer-polyfill, splash/main et logging bridge.
## `pre.014` — polish desktop partagé et lancement Tauri multi-app
La tranche harmonise Config Desk et Wallet Desk sans modifier les contrats Wallet métier :
```text
HTML : en-têtes Khadhroony file/version sur main + splash
Splash : fade-in / minimum / fade-out distincts via Config
Splash : messages généraux défilants en bas
Splash debug : diagnostics défilants en haut uniquement en debug
Splash : aucune scrollbar fenêtre, titre central non sélectionnable
Main : pills/tabs dans une sidebar du contenu, pas dans le header
Palette : Wallet Desk revient sur la palette claire de référence Config Desk
Tauri : lancement crate-local obligatoire dans le workspace multi-app
```
La cause du mélange observé Config-Vite / Wallet-backend est explicitement corrigée : `-c/--config` fusionne une configuration avec le projet Tauri déjà découvert ; il ne choisit pas la crate. Les commandes de validation visuelle sont donc :
```bash
KSP_DESK_SPLASH_FADE_IN_MS=1500 \
KSP_DESK_SPLASH_MINIMUM_MS=6000 \
KSP_DESK_SPLASH_FADE_OUT_MS=1500 \
bash -lc 'cd crates/ksp-app-config-desk && cargo tauri dev'
KSP_DESK_SPLASH_FADE_IN_MS=1500 \
KSP_DESK_SPLASH_MINIMUM_MS=6000 \
KSP_DESK_SPLASH_FADE_OUT_MS=1500 \
KSP_WALLETS_DIRECTORY=var/wallet-desk-pre014 \
bash -lc 'cd crates/ksp-app-wallet-desk && cargo tauri dev'
```
Le build Tauri de production reste reporté à `pre.015` et doit demeurer l’absolue dernière opération.

8
docs/rules/RULES_KSP.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_KSP.md -->
<!-- version: 36 -->
<!-- version: 37 -->
# Règles spécifiques à KSP
@@ -224,15 +224,15 @@
- **KSP-APP-023** — Le gabarit Tauri KSP place les sources web sous `frontend/`, les modules TypeScript sous `frontend/ts/`, les styles SCSS sous `frontend/sass/` et les bindings TS-RS générés sous `frontend/ts/bindings/`. Les bindings et artefacts générés ne sont pas versionnés ; les DTO Rust applicatifs restent la source des contrats TS-RS.
- **KSP-APP-024** — Chaque application desk Tauri KSP possède un couple de ports Vite/HMR exclusif. L'allocation commence à `1430/1431` pour `ksp-app-config-desk` puis progresse par paires (`1432/1433`, `1434/1435`, etc.). Le port Vite est strict afin qu'une collision échoue explicitement au lieu de sélectionner silencieusement un autre port.
- **KSP-APP-025** — Dans `package.json`, les bibliothèques consommées par le bundle applicatif appartiennent à `dependencies`; les outils de build/développement et paquets `@types/*` appartiennent à `devDependencies`. npm est utilisé directement uniquement pour installer ou mettre à jour ces dépendances. Le cycle normal de développement/build passe par Tauri, qui déclenche les scripts npm configurés via `beforeDevCommand`/`beforeBuildCommand`; les lockfiles frontend restent non versionnés.
- **KSP-APP-026** — KSP étant un workspace Rust multi-app, les commandes Tauri lancées depuis la racine sélectionnent explicitement la configuration de l'application avec `-c crates/<app>/tauri.conf.json` (par exemple `cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json`). Après une installation npm effectuée depuis `crates/<app>`, l'opérateur revient à la racine du workspace avant le cycle Cargo/Tauri.
- **KSP-APP-026** — Dans un workspace Rust multi-app, `-c/--config` de Tauri est un overlay de configuration et ne sélectionne pas la crate applicative. Les commandes Tauri sont donc exécutées depuis le répertoire de la crate ciblée : `(cd crates/<app> && cargo tauri dev)` ou `(cd crates/<app> && cargo tauri build)`. Le lancement depuis la racine avec `-c crates/<app>/tauri.conf.json` est interdit comme sélecteur d’application.
- **KSP-APP-027** — Les applications Tauri KSP instrumentent systématiquement le comportement frontend via le bridge Logging commun : actions utilisateur et transitions d’état significatives en `debug`, événements techniques fins, rendu/remplacement de sections et étapes fréquentes en `trace`. Les chargements/rafraîchissements de données sont tracés au début et à la fin sans journaliser les payloads sensibles. Cette instrumentation doit permettre de reconstruire le déroulement frontend sans dépendre uniquement de l’état visuel.
- **KSP-APP-028** — Le header d’une application desk ne répète pas inutilement l’identité déjà portée par son logo : il affiche le nom ou l’abréviation fonctionnelle de l’application, puis un tiret cadratin `—` et le titre de la vue active. Les commandes principales peu nombreuses peuvent utiliser des tabs/pills alignées à droite ; lorsque leur nombre nuit à la lisibilité ou à l’espace disponible, un dropdown est préféré.
- **KSP-APP-029** — En développement workspace, une application desk Tauri normalise le current working directory du processus Rust vers la racine du workspace avant le bootstrap Config lorsque `cargo tauri ... -c crates/<app>/tauri.conf.json` lance le binaire depuis la crate. Cette adaptation ne lit ni ne parse directement `config/`, `.env` ou les variables `KSP_*`/`KSPB_*` : `ksp-config-lib` reste seul propriétaire de ces ressources. Le comportement de distribution/release reste défini séparément et ne doit pas dépendre d’un checkout source.
- **KSP-APP-029** — En développement workspace, Tauri est lancé depuis `crates/<app>` conformément à `KSP-APP-026`. Le processus Rust peut ensuite normaliser son current working directory vers la racine du workspace avant le bootstrap Config lorsque les chemins de développement KSP y sont enracinés. Cette adaptation ne lit ni ne parse directement `config/`, `.env` ou les variables `KSP_*`/`KSPB_*` : `ksp-config-lib` reste seul propriétaire de ces ressources. Le runtime distribué ne doit pas dépendre d’un checkout source.
- **KSP-APP-030** — Lorsqu’une application KSP persiste des logs applicatifs, chaque lancement doit disposer d’un fichier propre et non partagé avec un lancement précédent. Le nom encode au minimum l’identité applicative et un horodatage de démarrage, par exemple `app-name.YYYYMMDD-HHMMSS.log` / `.json` / `.jsonl` selon le format du sink ; une rotation quotidienne ne doit pas fusionner plusieurs exécutions applicatives dans le même fichier.
- **KSP-APP-031** — Le niveau de logging spécifique à une application/crate peut être élevé temporairement à `debug` ou `trace` pendant une phase de développement ou correction. Avant la clôture/release de cette application/crate, son niveau de référence est ramené à `info` ou `warn` selon le besoin opératoire ; il n’est remonté que lorsqu’un développement/correctif est explicitement rouvert.
- **KSP-APP-032** — Les interfaces desk KSP n’utilisent pas les dialogues bloquants natifs du navigateur (`window.alert`, `window.confirm`, `window.prompt`) pour les interactions applicatives normales. Les confirmations destructives ou privilégiées utilisent un modal Bootstrap intégré à l’UI, instrumenté par le bridge Logging ; toute exception doit être explicitement justifiée et documentée.
- **KSP-APP-033** — Un test d’une application ou d’un manager qui peut modifier un document Config du workspace ne traite jamais les valeurs courantes de ce document comme une fixture immuable. Les tests de valeurs exactes utilisent une fixture isolée ; les tests qui lisent la Config workspace vérifient uniquement des invariants, la validité et la cohérence source → résolution → runtime afin de rester valides après une édition légitime par Config Desk.
- **KSP-APP-034** — Pour une application Tauri KSP, npm n'est jamais invoqué directement pour lancer les scripts applicatifs de développement, contrôle ou build. Conformément à `KSP-APP-025`, les seules commandes npm directes sont celles nécessaires à l'installation ou à la mise à jour des dépendances déclarées dans `package.json` (`npm i -D` lors de l'installation initiale retenue par le gabarit, ou `npm update` lors d'une mise à jour). Le cycle applicatif passe par `cargo tauri dev -c crates/<app>/tauri.conf.json` et `cargo tauri build -c crates/<app>/tauri.conf.json`; Tauri déclenche lui-même les scripts configurés via `beforeDevCommand` et `beforeBuildCommand`. Dans une séquence de validation finale, `cargo tauri build -c crates/<app>/tauri.conf.json` est exécuté **en toute dernière opération**, après `fmt/check/clippy`, les tests et le parcours fonctionnel `cargo tauri dev`.
- **KSP-APP-034** — Pour une application Tauri KSP, npm n’est jamais invoqué directement pour lancer les scripts applicatifs de développement, contrôle ou build. Les seules commandes npm directes servent à installer ou mettre à jour les dépendances déclarées. Le cycle applicatif est crate-local : `(cd crates/<app> && cargo tauri dev)` et `(cd crates/<app> && cargo tauri build)` ; Tauri déclenche lui-même les hooks `beforeDevCommand` / `beforeBuildCommand`, dont le `cwd` reste explicitement la crate. Dans une validation finale, le `cargo tauri build` crate-local est exécuté **en toute dernière opération**, après fmt/audit/check/clippy, tests et parcours fonctionnel.
## Data plane / control plane