v0.5.2-pre.006

kb-app-demo-desktop/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-app-demo-desktop/USAGE.md -->
-<!-- version: 15 -->
+<!-- version: 19 -->
 
 # Utilisation de kb-app-demo-desktop
 
@@ -7,6 +7,43 @@
 
 L’application expose une interface opérateur pour diagnostiquer, simuler et valider les couches de bot3.
 
+## Surface wallet sûre
+
+Le backend desktop peut lister les `.kswallet` du répertoire configuré, créer un wallet natif protégé, inspecter un fichier sélectionné explicitement ailleurs et explorer l’état on-chain d’une adresse publique. Les DTO frontend ne contiennent jamais de matériau secret. Aucun password, chemin interne du store, sel, nonce, ciphertext ou byte privé n’est renvoyé par Tauri.
+
+La fenêtre `Wallets`, accessible depuis le menu `Démos` de `main`, fournit quatre surfaces :
+
+- inventaire des wallets natifs du profil actif ;
+- création d’un nouveau `.kswallet` dans le store du profil actif ;
+- explorateur public on-chain ;
+- inspection structurale d’un `.kswallet` explicite situé hors du store.
+
+### Créer un wallet natif depuis la démo
+
+Le mot de passe de création ne doit pas traverser le frontend ou Tauri IPC. La démo lit uniquement côté backend le secret applicatif :
+
+```bash
+export KB_SECRET_DEMO_WALLET_PASSWORD='mot-de-passe-de-demo'
+cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
+```
+
+Le secret peut aussi être placé dans le fichier `.env` local chargé par `ks-config`. Le vrai `.env` reste non versionné et ne doit jamais être archivé. L’UI ne reçoit qu’un booléen indiquant si ce secret backend est configuré.
+
+La création demande uniquement l’alias. Elle crée `<alias>.kswallet` dans le répertoire wallet résolu du profil actif et ne modifie pas automatiquement `wallet_alias` dans la configuration. Un changement de valeur de `KB_SECRET_DEMO_WALLET_PASSWORD` avant une autre session permet d’utiliser un autre mot de passe pour de nouveaux wallets ; ce secret de démonstration n’est pas un mot de passe global du format `.kswallet`.
+
+### Explorer une adresse sur un profil RPC sélectionné
+
+L’explorateur on-chain ne déverrouille aucun wallet : seule la pubkey publique est nécessaire. Le bouton `Explorer` d’un wallet inventorié remplit l’adresse automatiquement ; toute autre pubkey Solana peut également être saisie.
+
+Les lectures utilisent le transport HTTP du profil choisi dans le sélecteur `Profil RPC` de la fenêtre Wallets. Le profil actif est sélectionné par défaut, mais `local_devnet`, `mainnet_research` ou tout autre profil HTTP résolu peut être choisi sans redémarrer l’application :
+
+- `getBalance` pour le solde SOL exact en lamports ;
+- `getTokenAccountsByOwner` pour les comptes SPL Token classique et Token-2022 ;
+- `getSignaturesForAddress` pour les signatures récentes des transactions qui référencent l’adresse ;
+- `getTransaction` à la demande pour afficher le détail JSON d’une signature.
+
+La liste est donc intitulée **transactions impliquant l’adresse** : elle ne prétend pas que le wallet a initié ou signé chaque transaction retournée. Le profil `local_devnet` interroge Devnet ; `mainnet_research` ou `mainnet` interrogent Mainnet Beta. La sélection utilisée par l’explorateur est locale à cette fenêtre : elle ne modifie pas `active_profile`, la configuration du workspace ni le profil utilisé par les autres démos.
+
 ## Lancer le desktop
 
 Depuis la racine du workspace :
@@ -54,6 +91,7 @@ Les autres fenêtres sont ouvertes par les commandes Tauri dédiées :
 - diagnostics SQL ;
 - candidats replay ;
 - configuration ;
+- wallets ;
 - extraction Core ;
 - decode replay ;
 - exécution Solana Core ;
@@ -68,6 +106,7 @@ Les commandes Tauri constituent l’interface applicative frontend/backend. Elle
 ```typescript
 import { invoke } from "@tauri-apps/api/core";
 
+await invoke("open_demo_wallet_window");
 await invoke("open_demo_http_window");
 await invoke("open_demo_ws_window");
 await invoke("open_demo_decode_replay_window");