kb-app-demo-desktop
kb-app-demo-desktop est l’application Tauri de démonstration et de validation de khadhroony-bot3. Le package reste une seule crate mixte bibliothèque et binaire.
Fonctionnalités
- configuration et diagnostics de logging ;
- fenêtre Wallets dédiée : inventaire sûr des identités
.kswallet, création d’un conteneur persistant via un secret backend-only, sélection session-only du wallet d'exécution Devnet, inspection/import/export des formats keypair supportés sousdata/wallets/, extraction sûre de pubkey depuis un keypair legacy, inspection explicite d’un.kswalletexterne et exploration publique du solde SOL, des comptes SPL Token / Token-2022 et des transactions récentes sur un profil RPC explicitement sélectionnable ; - transport HTTP JSON-RPC et WebSocket ;
- diagnostics de stockage backend-agnostiques ;
- backfill, extraction Core et replay, avec enregistrement générique de Solana Program Metadata ;
- démonstrations Solana Core, SPL Memo, SPL Token, ATA et Token-2022 ;
- panneau Metadata avec parcours séparés Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata, préparation du profil et de la base, simulation RPC réelle, soumission explicitement confirmée et affichage des postconditions ;
- progression, annulation et restauration de l’état des fenêtres.
Frontière architecturale
Les commandes Tauri sont des adaptateurs minces. La logique réutilisable appartient à ks-pipeline, ks-pipeline-demo-scenarios, ks-lib, ks-store et ks-onchain-transport.
Depuis 0.5.3-pre.002, l'application conserve une façade ks_store::Store unique dans AppState. Les commandes ne construisent plus de backend concret et les payloads de configuration/diagnostic ne transportent plus de champs PostgreSQL/SQLite concrets. Depuis 0.5.3-pre.005, les listings de consultation Store utilisent des blocs fixes de 500 parcourus par curseurs : Replay Candidates, annotations de transactions et journaux SPL Token/ATA partagent le même principe. Chaque chargement recalcule le nombre total de blocs pour les filtres actifs. Lorsqu’une vue utilise DataTables, sa pagination/son tri/son filtre restent strictement locaux au bloc déjà chargé.
Les campagnes Devnet/Testnet réutilisables appartiennent à ks-pipeline-demo-scenarios. Le desktop conserve leurs adaptateurs UI/Tauri, la sélection opérateur, la progression, les payloads TS-RS et la présentation ; 0.5.4 doit retirer les orchestrations réutilisables qui subsistent encore localement.
Depuis 0.5.1-pre.008, TS-RS appartient à cette frontière applicative : ks-config et ks-lib ne génèrent plus de bindings TypeScript. Lorsqu'un type généraliste doit être présenté au frontend, le desktop construit un DTO/wrapper dédié.
La fenêtre Configuration ne reçoit plus ks_config::AppConfig ou ProfileConfig. Elle reçoit une projection publique typée et un diagnostic borné construits champ par champ. Les URLs, DSN et chemins sensibles ne traversent pas Tauri ; le diagnostic n'expose que leur état configured/missing.
Exécution Metaplex Token Metadata
Le panneau conserve les scénarios synthétiques pour inspecter les contrats, mais son parcours Devnet principal expose désormais 11 campagnes qualifiées de pre.013 et appelle directement leurs runners spécialisés de ks-pipeline-demo-scenarios. Les cinq variantes Create -> Mint, collection, Print/Burn, lifecycle pNFT et escrow soumettent uniquement les opérations autorisées ; Maintenance et Use conservent les opérations unavailable dans des probes simulation-only. Le desktop ne reconstruit pas les builders ; il conserve encore une partie du dispatch, des critères de complétion et de la projection de preuves, à centraliser en 0.5.4 lorsque cette logique est réutilisable.
Exécution Token-2022 Token Metadata
Le sous-panneau dédié appelle directement la campagne réutilisable de ks-pipeline-demo-scenarios; son parcours desktop complet a été confirmé sur Devnet pendant pre.014. Il crée un mint Token-2022 frais avec Metadata Pointer auto-référencé puis exécute, dans l’ordre, Initialize, UpdateField, Emit, RemoveKey et UpdateAuthority. Chaque étape passe par simulation, confirmation, replay canonique, matérialisation lorsque requise, lecture stateful et postcondition ; Emit conserve en plus sa return data validée.
Exécution Solana Program Metadata
Le même panneau expose séparément les deux parcours Buffer et Metadata de ProgM6…; sa campagne desktop complète a été confirmée sur Devnet pendant pre.014. La campagne complète crée deux PDA frais, confirme leurs préfinancements, exécute les neuf opérations stables, vérifie les lectures avant/après et affiche les snapshots matérialisés. La logique réseau reste entièrement dans ks-pipeline-demo-scenarios ; le desktop ne fait que sélectionner le profil, demander la confirmation et présenter les preuves.