v0.4.8-pre.014
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-app-demo-desktop/README.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# kb-app-demo-desktop
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
- diagnostics PostgreSQL ;
|
||||
- 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 et Solana Program Metadata, préparation du profil et de la base, simulation RPC réelle, soumission explicitement confirmée et affichage des postconditions ;
|
||||
- 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
|
||||
@@ -23,11 +23,15 @@ Les scénarios UI Devnet/Testnet restent dans le desktop. Des tests automatisés
|
||||
|
||||
## Exécution Metaplex Token Metadata
|
||||
|
||||
Le panneau conserve les scénarios synthétiques et appelle directement le runner réutilisable de `kb-pipeline-demo-scenarios` pour les opérations Metaplex courantes. La simulation RPC est réelle ; la soumission exige deux autorisations distinctes dans la requête desktop. Après une confirmation, l’adaptateur réutilise PostgreSQL pour conserver l’hydratation canonique, l’extraction Core, le replay, les matérialisations et la preuve d’idempotence produites par le runner.
|
||||
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 `kb-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 ni les builders ni les postconditions et présente la fixture, les exécutions/probes et les preuves produites par les runners.
|
||||
|
||||
## Exécution Token-2022 Token Metadata
|
||||
|
||||
Le sous-panneau dédié appelle directement la campagne réutilisable de `kb-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…`. 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 `kb-pipeline-demo-scenarios` ; le desktop ne fait que sélectionner le profil, demander la confirmation et présenter les preuves.
|
||||
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 `kb-pipeline-demo-scenarios` ; le desktop ne fait que sélectionner le profil, demander la confirmation et présenter les preuves.
|
||||
|
||||
## Documentation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user