v0.4.8-pre.014
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-app-demo-desktop/USAGE.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Utilisation de kb-app-demo-desktop
|
||||
|
||||
@@ -207,35 +207,32 @@ La simulation et l’envoi doivent rester explicitement distingués dans les req
|
||||
|
||||
### Exécution Metadata Devnet
|
||||
|
||||
Le backend distingue le module commun Metadata, Metaplex Token Metadata et Solana Program Metadata.
|
||||
Le backend distingue le module commun Metadata, Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata. Metaplex est porté par un seul module Rust desktop, comme les deux autres domaines : ce module contient à la fois les contrats génériques conservés pour les tests/outils avancés et les campagnes Devnet qualifiées. Les commandes génériques Metaplex (`current_operations`, `operation_template`, `prepare_step`, `execute`) restent disponibles, mais le panneau Devnet n’utilise plus ce chemin comme workflow opérateur principal.
|
||||
|
||||
Le panneau Metadata charge les opérations courantes depuis `demo_execution_metadata_metaplex_token_metadata_current_operations` et peut demander un modèle avec `demo_execution_metadata_metaplex_token_metadata_operation_template`.
|
||||
Le panneau charge désormais l’inventaire borné avec `demo_execution_metadata_metaplex_campaigns`, puis exécute une campagne complète avec `demo_execution_metadata_metaplex_execute_campaign`.
|
||||
|
||||
```typescript
|
||||
const operationJson = await invoke(
|
||||
"demo_execution_metadata_metaplex_token_metadata_operation_template",
|
||||
{ operation: "verify" }
|
||||
const campaigns = await invoke(
|
||||
"demo_execution_metadata_metaplex_campaigns"
|
||||
);
|
||||
|
||||
const summary = await invoke(
|
||||
"demo_execution_metadata_metaplex_token_metadata_execute",
|
||||
"demo_execution_metadata_metaplex_execute_campaign",
|
||||
{
|
||||
request: {
|
||||
profileName: "devnet",
|
||||
intentId: `desktop-metaplex-${Date.now()}`,
|
||||
operationJson,
|
||||
preflightReadsJson: "[]",
|
||||
postconditionReadsJson: "[]",
|
||||
submit: false,
|
||||
operatorConfirmed: false
|
||||
campaignId: "create_mint_nft",
|
||||
operatorConfirmed: true
|
||||
}
|
||||
}
|
||||
);
|
||||
|
||||
console.log(summary);
|
||||
console.log(campaigns, summary);
|
||||
```
|
||||
|
||||
Les valeurs `<...>` d’un modèle doivent être remplacées par des comptes réels avant exécution. `submit: true` exige simultanément `operatorConfirmed: true`. Le résultat distingue le plan, le préflight stateful, la simulation RPC, la signature éventuelle, la confirmation et les états avant/après. Après soumission confirmée, `evidenceJson` contient également l’hydratation canonique, l’extraction Core, le replay, la seconde passe d’idempotence, les matérialisations instructionnelles et le diagnostic post-exécution.
|
||||
L’inventaire contient cinq variantes `Create -> Mint`, puis collection `Verify -> Unverify`, `Print -> Burn`, lifecycle pNFT, Token Owned Escrow, Maintenance et le probe Use. Maintenance et Use sont les seules campagnes mixtes/probe : `Use`, `Resize`, `Migrate`, `Collect` et `CloseAccounts` y restent simulation-only lorsqu’elles rencontrent leur indisponibilité qualifiée et ne sont jamais exposées comme boutons de soumission isolés.
|
||||
|
||||
Dans la colonne de résultats, `Préflight et opérations`, `Simulation et confirmation` et `Postconditions et preuves` sont présentés dans un accordéon commun. La carte `Exigences` reste sous cet accordéon et le journal d’exécution reste sous la grille, sur toute la largeur.
|
||||
|
||||
### Diagnostics PostgreSQL
|
||||
|
||||
@@ -290,7 +287,7 @@ Le nombre de tests évolue avec les surfaces raccordées ; la référence de val
|
||||
|
||||
## Panneau Exécution Metadata
|
||||
|
||||
Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metadata**. Le panneau permet actuellement :
|
||||
Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metadata**. Le panneau sépare Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata. Il permet actuellement :
|
||||
|
||||
- de choisir un scénario synthétique ou un contrat de campagne Devnet ;
|
||||
- de sélectionner le profil Devnet ;
|
||||
@@ -300,11 +297,30 @@ Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metada
|
||||
|
||||
Un contrat marqué Devnet n’est pas, à lui seul, une exécution réseau. Les champs `networkExecutionPerformed` et `networkEvidenceCollected` doivent rester faux tant qu’aucun appel RPC réel et aucune preuve correspondante n’ont été produits.
|
||||
|
||||
Le panneau distingue préparation de l’étape, simulation exacte et soumission explicitement confirmée. Les lectures de postcondition et la matérialisation sont dérivées du scénario préparé.
|
||||
Les scénarios synthétiques restent disponibles pour inspecter les contrats sans réseau. Le parcours Devnet Metaplex sélectionne au contraire une campagne qualifiée complète ; fixture, simulation, soumission autorisée, replay, matérialisation, idempotence et postconditions restent la responsabilité du runner spécialisé.
|
||||
|
||||
### Préparation de la fixture Metaplex `Create`
|
||||
### Campagnes Metaplex qualifiées
|
||||
|
||||
Le panneau desktop peut créer ou réutiliser un mint SPL classique Devnet à zéro décimale. Le préparateur dérive ensuite automatiquement les PDA `metadata` et `master edition` et génère un intent `Create` typé. Les valeurs entre chevrons des modèles génériques restent des placeholders non exécutables.
|
||||
Ouvrir **Metaplex Token Metadata -> Campagnes Devnet qualifiées**, sélectionner un profil persistant et préparer PostgreSQL. Le sélecteur présente 11 campagnes : cinq familles `Create -> Mint`, collection, Print/Burn, lifecycle pNFT, escrow, maintenance et Use. Après confirmation opérateur, le desktop appelle le runner correspondant et affiche :
|
||||
|
||||
- la fixture et son setup ;
|
||||
- les exécutions confirmées et les probes indisponibles dans leur ordre réel ;
|
||||
- les postconditions de campagne ;
|
||||
- les compteurs `confirmed` et `unavailable`.
|
||||
|
||||
La surface générique par opération reste une API avancée et ne doit pas être utilisée pour reconstruire manuellement ces campagnes dans l’UI.
|
||||
|
||||
### Campagne Token-2022 Token Metadata
|
||||
|
||||
Ouvrir l’accordéon **Token-2022 Token Metadata**, sélectionner un profil Devnet persistant et préparer sa base PostgreSQL. Le panneau affiche le contrat fixe de cinq opérations :
|
||||
|
||||
```text
|
||||
Initialize -> UpdateField -> Emit -> RemoveKey -> UpdateAuthority
|
||||
```
|
||||
|
||||
Après confirmation explicite, **Exécuter la campagne Token-2022 Metadata** crée un mint frais avec Metadata Pointer vers lui-même, puis appelle le runner réutilisable pour les cinq opérations. La campagne conserve les simulations, signatures, confirmations, snapshots stateful, postconditions et matérialisations ; `Emit` expose également la return data validée. La fixture et les preuves sont affichées avec le JsonViewer commun.
|
||||
|
||||
La carte **Exigences** est placée en bas de la colonne droite, après les postconditions. Le journal d’exécution est placé sous les deux colonnes principales et occupe toute la largeur disponible de la page.
|
||||
|
||||
### Campagne Solana Program Metadata
|
||||
|
||||
|
||||
Reference in New Issue
Block a user