48 lines
5.1 KiB
Markdown
48 lines
5.1 KiB
Markdown
<!-- file: kb-app-demo-desktop/README.md -->
|
||
<!-- version: 24 -->
|
||
|
||
# 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 sous `data/wallets/`, extraction sûre de pubkey depuis un keypair legacy, inspection explicite d’un `.kswallet` externe 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.
|
||
|
||
## Documentation
|
||
|
||
- [Guide d’utilisation](USAGE.md)
|
||
- [Travaux restant à réaliser](TODO.md)
|
||
- [Historique des changements](CHANGELOG.md)
|