v0.4.7-pre.011
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
# file: Cargo.toml
|
||||
# version: 17
|
||||
# version: 18
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
@@ -18,7 +18,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.4.7-pre.10"
|
||||
version = "0.4.7-pre.11"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3"
|
||||
|
||||
42
README.md
42
README.md
@@ -1,37 +1,35 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 15 -->
|
||||
<!-- version: 16 -->
|
||||
|
||||
# Khadhroony Bot3
|
||||
|
||||
`khadhroony-bot3` est le workspace Rust consolidé succédant à `khadhroony-bot2` pour l’acquisition, le stockage, le décodage, la matérialisation, la validation et l’exécution contrôlée d’opérations Solana.
|
||||
`khadhroony-bot3` est un workspace Rust 2024 dédié à l’acquisition, au décodage, à la matérialisation et à l’exécution contrôlée de transactions Solana.
|
||||
|
||||
## Version fonctionnelle
|
||||
## Version en développement
|
||||
|
||||
Le workspace est aligné sur le périmètre fonctionnel de `khadhroony-bot2 0.4.6` dans la nouvelle architecture bot3. Les différences de structure sont intentionnelles : les modèles, décodeurs, exécuteurs et matérialisateurs sont consolidés dans `kb-lib`, le stockage dans `kb-store` et les transports RPC dans `kb-onchain-transport`.
|
||||
La version active est `0.4.7`, consacrée à l’achèvement de Metaplex Token Metadata.
|
||||
|
||||
Exceptions documentées :
|
||||
Les contrats de décodage, les comptes, les matérialisations, les 35 opérations officiellement constructibles, l’orchestration généraliste, les scénarios synthétiques et le panneau desktop sont présents. La clôture est repoussée jusqu’à la réalisation des campagnes Devnet des 20 opérations courantes non dépréciées.
|
||||
|
||||
- le registre ElGamal est implémenté avec validations synthétiques et garde-fous fail-closed, mais n’est pas déclaré validé réellement sur Devnet ou Mainnet ;
|
||||
- Metaplex Token Metadata possède déjà ses décodeurs d’instructions et de comptes ainsi qu’une matérialisation substantielle, mais son exécuteur, son orchestration complète et ses démonstrations appartiennent à `0.4.7` ;
|
||||
- les améliorations structurelles de `kb-config`, `kb-logging` et `kb-store` sont reportées à `0.5.x`.
|
||||
Le registre ElGamal reste une exception indépendante : il est implémenté et validé synthétiquement, mais n’est pas déclaré validé réellement sur Devnet ou Mainnet.
|
||||
|
||||
## Architecture
|
||||
|
||||
Le workspace contient 11 crates :
|
||||
Le workspace contient onze crates :
|
||||
|
||||
- `kb-core` : erreurs et primitives transversales ;
|
||||
- `kb-config` : chargement et validation de la configuration ;
|
||||
- `kb-lib` : modèles, décodeurs, exécuteurs et matérialisateurs ;
|
||||
- `kb-logging` : logging et tracing ;
|
||||
- `kb-program-ids` : registre des programmes et comptes Solana connus ;
|
||||
- `kb-pipeline` : backfill, extraction Core, replay et orchestration ;
|
||||
- `kb-pipeline-demo-scenarios` : bibliothèque de scénarios et CLI ;
|
||||
- `kb-program-ids` : registre canonique des programmes et comptes Solana ;
|
||||
- `kb-pipeline` : pipeline généraliste de backfill, extraction, replay et orchestration ;
|
||||
- `kb-pipeline-demo-scenarios` : scénarios synthétiques et campagnes Devnet/Testnet automatisables ;
|
||||
- `kb-onchain-transport` : transports RPC HTTP et WebSocket ;
|
||||
- `kb-store` : contrats de stockage et adaptateur PostgreSQL ;
|
||||
- `kb-wallet` : frontière de wallet et signataires, encore incomplète ;
|
||||
- `kb-app-demo-desktop` : bibliothèque et application Tauri de démonstration.
|
||||
- `kb-wallet` : frontière de wallet et signataires ;
|
||||
- `kb-app-demo-desktop` : application Tauri de démonstration, avec scénarios UI conservés dans le desktop.
|
||||
|
||||
La vue détaillée est disponible dans :
|
||||
Références :
|
||||
|
||||
- [`docs/architecture/ARCHITECTURE.md`](docs/architecture/ARCHITECTURE.md) ;
|
||||
- [`docs/architecture/CRATE_MAP.md`](docs/architecture/CRATE_MAP.md) ;
|
||||
@@ -41,14 +39,16 @@ La vue détaillée est disponible dans :
|
||||
|
||||
## Documentation
|
||||
|
||||
L’index actif se trouve dans [`docs/README.md`](docs/README.md).
|
||||
|
||||
Les règles normatives commencent dans [`RULES.md`](RULES.md). Les règles spécialisées sont placées sous [`docs/rules/`](docs/rules/).
|
||||
|
||||
Les documents historiques de bot2, bobobot et de la migration bot3 sont conservés sous `olddocs/`. Ils servent de sources historiques et ne sont pas normatifs.
|
||||
- [`RULES.md`](RULES.md) : index des règles ;
|
||||
- [`ROADMAP.md`](ROADMAP.md) : objectifs par version fonctionnelle ;
|
||||
- [`CHANGELOG.md`](CHANGELOG.md) : historique des versions fonctionnelles clôturées ;
|
||||
- [`docs/README.md`](docs/README.md) : index documentaire ;
|
||||
- [`prompts/027_v0_4_7_metaplex_token_metadata_completion.md`](prompts/027_v0_4_7_metaplex_token_metadata_completion.md) : prompt actif de `0.4.7`.
|
||||
|
||||
## Validation générale
|
||||
|
||||
La validation finale d’une version utilise :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
@@ -57,7 +57,7 @@ python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
La validation frontend desktop s’effectue uniquement avec :
|
||||
Lorsque le desktop est concerné :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
|
||||
13
ROADMAP.md
13
ROADMAP.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 25 -->
|
||||
<!-- version: 26 -->
|
||||
|
||||
# ROADMAP — khadhroony-bot3
|
||||
|
||||
@@ -43,11 +43,14 @@ Version clôturée.
|
||||
### Critères de sortie
|
||||
|
||||
- exécution simulation-first avec signers, coûts et confirmations exacts ;
|
||||
- intégration pipeline et démonstrations complètes ;
|
||||
- tests contractuels, unitaires et stateful ;
|
||||
- limites réseau documentées ;
|
||||
- scénarios synthétiques déterministes et campagnes Devnet réelles dans `kb-pipeline-demo-scenarios` ;
|
||||
- scénario Devnet pour chacune des 20 opérations courantes non dépréciées, avec simulation RPC réelle et, lorsque l'opération est réalisable, soumission confirmée et postcondition observée ;
|
||||
- démonstrations UI Devnet conservées dans `kb-app-demo-desktop` et raccordées aux mêmes contrats réutilisables ;
|
||||
- tests contractuels, unitaires, stateful et replay PostgreSQL idempotent ;
|
||||
- statut réseau exact par opération, sans substitution d'une preuve synthétique à une preuve RPC ;
|
||||
- opérations remplacées redirigées vers leur remplacement canonique final ;
|
||||
- opérations obsolètes encore constructibles exposées comme exécutables dépréciées et soumises à une approbation explicite.
|
||||
- opérations obsolètes encore constructibles exposées comme exécutables dépréciées et soumises à une approbation explicite ;
|
||||
- clôture repoussée jusqu'à l'achèvement des campagnes Devnet des opérations courantes.
|
||||
|
||||
## 0.4.8 — SPL Token Metadata et décision off-chain metadata
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Plan `0.4.7` — achèvement de Metaplex Token Metadata
|
||||
|
||||
@@ -304,7 +304,7 @@ Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipelin
|
||||
- envoi et postcondition uniquement avec fixture contrôlée ;
|
||||
- statut réseau exact consigné par opération.
|
||||
|
||||
**Recommandation : Option B.** La version peut clôturer avec certaines opérations validées synthétiquement seulement, à condition que ce statut soit explicite et que leur exécution publique soit limitée en conséquence.
|
||||
**Décision révisée : validation Devnet obligatoire pour la surface courante.** Les niveaux de preuve restent distincts, mais `0.4.7` ne peut plus être clôturée tant que les opérations `executable_current` n'ont pas été exercées sur Devnet par des scénarios réels. Les opérations `executable_deprecated` restent hors campagne réseau obligatoire et ne sont exécutées que dans une campagne séparée, volontaire et explicitement approuvée. Une impossibilité réseau démontrée doit être documentée opération par opération et ne peut pas être remplacée par une preuve synthétique.
|
||||
|
||||
## 7. Ordonnancement proposé par prerelease
|
||||
|
||||
@@ -484,7 +484,65 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
|
||||
- matrice, tests, rapports et runtime alignés ;
|
||||
- écarts résiduels fermés ou reportés explicitement.
|
||||
|
||||
### `0.4.7-pre.011` — clôture
|
||||
### `0.4.7-pre.011` — infrastructure et premières campagnes Devnet réelles
|
||||
|
||||
**Dépendance** : exécuteur, pipeline, fixtures synthétiques et desktop stabilisés.
|
||||
|
||||
**Travaux**
|
||||
|
||||
- rouvrir la version après le rejet de la clôture prématurée ;
|
||||
- produire une liste machine-readable fermée des 20 opérations `executable_current` ;
|
||||
- définir pour chacune la fixture, les autorités, les fonds, les comptes préexistants, les effets attendus et la stratégie de nettoyage ;
|
||||
- ajouter les primitives réutilisables de préparation de fixtures Devnet dans `kb-pipeline-demo-scenarios` ;
|
||||
- exécuter réellement sur Devnet un premier lot cohérent couvrant au minimum création, mise à jour, vérification et révocation de vérification ;
|
||||
- enregistrer endpoint/cluster, signature, slot, logs de simulation, résultat de soumission, états avant/après et postconditions ;
|
||||
- interdire qu'un résultat synthétique puisse satisfaire un contrat de preuve réseau.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- le profil et la base Devnet sont chargés et vérifiés ;
|
||||
- chaque scénario du premier lot effectue au minimum une simulation RPC réelle ;
|
||||
- les scénarios mutateurs retenus effectuent une soumission réelle après garde-fou explicite ;
|
||||
- les preuves sont persistées dans des résultats structurés et réutilisables ;
|
||||
- aucune opération dépréciée n'est exécutée automatiquement.
|
||||
|
||||
### `0.4.7-pre.012` — couverture Devnet des opérations courantes restantes
|
||||
|
||||
**Travaux**
|
||||
|
||||
- compléter les campagnes automatisées pour toutes les opérations `executable_current` restantes ;
|
||||
- couvrir les familles metadata, collections/créateurs, délégations, programmable NFT, éditions, uses, escrow et maintenance de comptes lorsque leurs préconditions sont disponibles ;
|
||||
- créer ou réutiliser des fixtures NFT, SFT, fungible, collection et pNFT ;
|
||||
- tester les échecs attendus : mauvaise autorité, mauvais PDA, owner invalide, rule set incohérent, comptes manquants et plafond de dépense ;
|
||||
- conserver simulation-only par défaut, avec soumission activée uniquement par une option explicite de campagne ;
|
||||
- consigner toute impossibilité Devnet démontrée avec cause externe précise, tentative reproductible et preuve associée.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- les 20 opérations `executable_current` ont chacune un scénario Devnet réel ;
|
||||
- chaque opération possède une simulation RPC observée ou une impossibilité réseau démontrée et documentée ;
|
||||
- chaque opération mutatrice réalisable possède au moins une soumission confirmée et une postcondition stateful observée ;
|
||||
- les résultats ne dépendent pas du desktop et utilisent exclusivement les APIs généralistes de `kb-pipeline`.
|
||||
|
||||
### `0.4.7-pre.013` — démonstrations desktop Devnet et validation croisée finale
|
||||
|
||||
**Travaux**
|
||||
|
||||
- raccorder le panneau Metadata aux scénarios réseau réutilisables, sans déplacer leur logique métier dans Tauri ;
|
||||
- conserver les scénarios UI dans `kb-app-demo-desktop` et les tests automatisés parallèles dans `kb-pipeline-demo-scenarios` ;
|
||||
- afficher profil, cluster, base, wallet, fixture, mode simulation/soumission, signature, slot, logs et postconditions ;
|
||||
- permettre l'exécution manuelle des opérations courantes retenues depuis le desktop avec confirmation opérateur ;
|
||||
- comparer les résultats automatisés et desktop sur les mêmes contrats de preuve ;
|
||||
- exécuter les validations croisées outer/CPI, succès/échec et replay PostgreSQL idempotent.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- le mode Devnet déclenche réellement les appels RPC et ne se limite jamais à changer un JSON frontend ;
|
||||
- les scénarios desktop et automatisés produisent des preuves compatibles ;
|
||||
- les 20 opérations courantes ont un statut réseau final exact ;
|
||||
- les opérations dépréciées restent clairement séparées et désactivées par défaut.
|
||||
|
||||
### `0.4.7-pre.014` — clôture
|
||||
|
||||
**Travaux**
|
||||
|
||||
@@ -493,13 +551,14 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
|
||||
- documentation générale et des crates ;
|
||||
- nettoyage des TODO, outils temporaires et références obsolètes ;
|
||||
- archivage du présent plan et des rapports devenus historiques ;
|
||||
- prompt `0.4.8` avec prerelease initiale de planification et prerelease finale de clôture ;
|
||||
- préparation seulement à ce stade du prompt `0.4.8`, avec prerelease initiale de planification et prerelease finale de clôture ;
|
||||
- livraison finale.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- commandes de validation finales réussies ;
|
||||
- code, matrices, registres, bindings et documentation alignés ;
|
||||
- preuves Devnet des opérations courantes alignées avec code, matrices, registres, bindings et documentation ;
|
||||
- aucun cas `executable_current` laissé avec un statut réseau ambigu ;
|
||||
- archive finale conforme aux règles du workspace.
|
||||
|
||||
## 8. Dépendances et ordre critique
|
||||
@@ -513,8 +572,9 @@ L’ordre critique est :
|
||||
5. pipeline stateful ;
|
||||
6. fixtures et validations automatisées Devnet/Testnet ;
|
||||
7. scénarios UI desktop ;
|
||||
8. validation croisée ;
|
||||
9. clôture.
|
||||
8. campagnes Devnet réelles automatisées ;
|
||||
9. démonstrations desktop Devnet et validation croisée finale ;
|
||||
10. clôture.
|
||||
|
||||
Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou l’envoi d’une opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce qu’un builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
|
||||
|
||||
@@ -573,7 +633,7 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
|
||||
3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
|
||||
4. rule sets programmables fail-closed ;
|
||||
5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
|
||||
6. séquence de prereleases `pre.002` à `pre.011` décrite ci-dessus.
|
||||
6. séquence de prereleases `pre.002` à `pre.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
|
||||
|
||||
|
||||
## État de `0.4.7-pre.007`
|
||||
@@ -601,3 +661,12 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
|
||||
- affichage des exigences de préflight, simulation-first et postconditions ;
|
||||
- scénario sélectionné restauré à la réouverture ;
|
||||
- aucune logique métier dupliquée et aucune soumission automatique.
|
||||
|
||||
|
||||
## État de `0.4.7-pre.011`
|
||||
|
||||
- matrice fermée des 20 opérations courantes ;
|
||||
- runner Devnet réel générique avec simulation RPC, soumission contrôlée, confirmation et lectures stateful avant/après ;
|
||||
- premier lot attribué à `Create`, `Update`, `Verify` et `Unverify` ;
|
||||
- preuves réseau encore `not_run` jusqu’aux exécutions locales et à la validation des postconditions métier ;
|
||||
- opérations dépréciées refusées dans les campagnes automatiques.
|
||||
|
||||
25
docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md
Normal file
25
docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md
Normal file
@@ -0,0 +1,25 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# `0.4.7-pre.011` — réouverture pour validation Devnet
|
||||
|
||||
## Décision
|
||||
|
||||
La clôture préparée dans le delta initial `pre.011` est rejetée. La présence d'un profil Devnet et l'affichage de résultats structurés ne constituent pas une exécution réseau.
|
||||
|
||||
## Exigence de sortie
|
||||
|
||||
Les 20 opérations classées `executable_current` dans la matrice Metaplex doivent disposer d'un scénario Devnet réel dans `kb-pipeline-demo-scenarios`. Chaque scénario doit produire des preuves RPC vérifiables. Les opérations réalisables avec une fixture contrôlée doivent également produire une soumission confirmée et une postcondition stateful.
|
||||
|
||||
Les opérations `executable_deprecated` ne font pas partie de la campagne obligatoire. Elles restent désactivées par défaut et nécessitent une approbation explicite.
|
||||
|
||||
## Nouvelle séquence
|
||||
|
||||
- `pre.011` : infrastructure et premier lot Devnet ;
|
||||
- `pre.012` : couverture des opérations courantes restantes ;
|
||||
- `pre.013` : démonstrations desktop Devnet et validation croisée finale ;
|
||||
- `pre.014` : clôture.
|
||||
|
||||
## Documents réactivés
|
||||
|
||||
Le plan `0.4.7`, le prompt de session et les rapports de prerelease redeviennent actifs. Le rapport de clôture et le prompt `0.4.8` préparés prématurément doivent être supprimés jusqu'à la vraie clôture.
|
||||
@@ -0,0 +1,31 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_011_DOCUMENTATION_REORGANIZATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# `0.4.7-pre.011` — réorganisation documentaire
|
||||
|
||||
## Objet
|
||||
|
||||
Corriger les documents désordonnés après la réouverture de `0.4.7` et replacer chaque information dans le document qui en est propriétaire.
|
||||
|
||||
## Règles appliquées
|
||||
|
||||
- `README.md` décrit le périmètre, les responsabilités, la surface et les limites durables ;
|
||||
- `USAGE.md` documente les APIs et parcours réellement utilisables ;
|
||||
- `TODO.md` ne contient que des tâches ouvertes, vérifiables et supprimables ;
|
||||
- `CHANGELOG.md` retrace les changements effectivement intégrés ;
|
||||
- `ROADMAP.md` reste limité aux versions fonctionnelles, sans journal de prerelease.
|
||||
|
||||
## Corrections
|
||||
|
||||
- retrait des entrées fonctionnelles `0.4.7` prématurées des changelogs de crates ;
|
||||
- regroupement des correctifs `pre.009` dans l’entrée de prerelease correspondante ;
|
||||
- suppression des tâches terminées des TODO ;
|
||||
- suppression de la tâche erronée demandant de déplacer les scénarios UI hors du desktop ;
|
||||
- déplacement des campagnes réseau vers les TODO de `kb-pipeline-demo-scenarios` et du desktop ;
|
||||
- ajout d’une section d’utilisation Metaplex dans `kb-lib/USAGE.md` ;
|
||||
- remplacement des sections Metadata incomplètes du guide desktop par le comportement réellement disponible ;
|
||||
- mise à jour des README pour refléter la clôture repoussée à `pre.014`.
|
||||
|
||||
## Statut
|
||||
|
||||
Ce correctif est documentaire. Il ne déclare aucune simulation, soumission ou postcondition Metaplex Devnet supplémentaire.
|
||||
@@ -0,0 +1,43 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_011_METAPLEX_DEVNET_INFRASTRUCTURE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.011` — infrastructure Devnet Metaplex
|
||||
|
||||
## Périmètre livré
|
||||
|
||||
- exécuteur Devnet réel pour un intent Metaplex courant ;
|
||||
- refus systématique des opérations dépréciées dans les campagnes automatiques ;
|
||||
- contrôle du cluster par genesis hash ;
|
||||
- chargement du wallet persistant du profil ;
|
||||
- lectures stateful bornées avant simulation et après confirmation ;
|
||||
- préflight lié au plan exact ;
|
||||
- compilation de la transaction, estimation des frais et simulation RPC exacte ;
|
||||
- soumission uniquement après option et confirmation opérateur explicites ;
|
||||
- confirmation de transaction et collecte des états après exécution ;
|
||||
- matrice fermée des 20 opérations courantes.
|
||||
|
||||
## Premier lot
|
||||
|
||||
Les opérations suivantes sont attribuées à `pre.011` :
|
||||
|
||||
- `create` ;
|
||||
- `update` ;
|
||||
- `verify` ;
|
||||
- `unverify`.
|
||||
|
||||
L’infrastructure est implémentée, mais aucune preuve réseau n’est déclarée dans ce livrable. Les quatre opérations restent `not_run` jusqu’à l’exécution locale avec des fixtures Devnet valides.
|
||||
|
||||
## Limites connues
|
||||
|
||||
Le runner utilise uniquement le wallet du profil. Un scénario exigeant un autre signer doit préparer sa fixture afin que toutes les autorités requises correspondent à ce wallet, ou introduire ultérieurement un contrat borné de signers supplémentaires.
|
||||
|
||||
La présence d’états avant/après ne constitue pas à elle seule une postcondition réussie. Chaque scénario doit encore comparer les champs métier attendus et reporter le résultat dans sa preuve.
|
||||
|
||||
## Validations de préparation
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
```
|
||||
|
||||
L’audit Khadhroony ne peut pas vérifier la résolution épinglée de `wincode`, car la copie archivée ne contient pas `Cargo.lock`. Les commandes Cargo et les appels Devnet doivent être exécutés dans le workspace local avant validation de la prerelease.
|
||||
@@ -1,31 +1,23 @@
|
||||
<!-- file: kb-app-demo-desktop/CHANGELOG.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# CHANGELOG — kb-app-demo-desktop
|
||||
|
||||
## 0.4.7-pre.009-fix-002
|
||||
## 0.4.7-pre.011 — réouverture des démonstrations Devnet
|
||||
|
||||
- correction du panneau qui présentait des contrats Devnet sans exécuter de commande réseau ;
|
||||
- chargement explicite du profil Devnet et préparation réelle de sa base PostgreSQL ;
|
||||
- affichage du contexte de profil et du rapport de readiness dans le JSON viewer commun ;
|
||||
- marquage explicite de l'absence de simulation et de preuves réseau ;
|
||||
- consolidation du rapport de validation `pre.009` et suppression du rapport de correctif dupliqué.
|
||||
### Documentation
|
||||
|
||||
## 0.4.7-pre.009-fix-001
|
||||
- réorganisation des quatre documents de crate ;
|
||||
- ajout du lot `pre.013` au TODO pour raccorder les campagnes réseau Metaplex réutilisables ;
|
||||
- clarification que les scénarios UI restent dans le desktop et sont couverts en parallèle par des tests automatisés.
|
||||
|
||||
- renommage de la fenêtre en `demo_execution_metadata` ;
|
||||
- ajout des accordéons extensibles par famille et mode ;
|
||||
- réutilisation du JSON viewer partagé ;
|
||||
- ajout des inventaires Devnet Metaplex en parallèle des scénarios synthétiques ;
|
||||
- alignement des versions Tauri et npm sur `0.4.7`.
|
||||
## 0.4.7-pre.009 — panneau Exécution Metadata
|
||||
|
||||
## 0.4.7-pre.009 — panneau Exécution Metadata Devnet
|
||||
|
||||
- ajout d'une fenêtre dédiée aux scénarios Exécution Metadata ;
|
||||
- adaptateurs Tauri minces vers `kb-pipeline-demo-scenarios` ;
|
||||
- affichage des opérations, exigences de préflight et preuves attendues ;
|
||||
- restauration du scénario sélectionné lors de la réouverture de la fenêtre ;
|
||||
- aucune logique métier ni soumission automatique dans le desktop.
|
||||
- ajout de la fenêtre dédiée et des adaptateurs Tauri minces ;
|
||||
- ajout des accordéons, du JSON viewer commun et des scénarios synthétiques ;
|
||||
- ajout de l’inventaire Devnet, du choix de profil et de la préparation réelle de la base PostgreSQL ;
|
||||
- distinction explicite entre contrat Devnet et exécution réseau réellement effectuée ;
|
||||
- consolidation du rapport de validation et correction des documents dupliqués.
|
||||
|
||||
## 0.4.6
|
||||
|
||||
|
||||
@@ -1,35 +1,32 @@
|
||||
<!-- file: kb-app-demo-desktop/README.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# kb-app-demo-desktop
|
||||
|
||||
`kb-app-demo-desktop` est l’application Tauri de démonstration, de diagnostic et de validation opérateur de `khadhroony-bot3`.
|
||||
|
||||
La crate reste un package mixte bibliothèque et binaire. Elle fournit les fenêtres et adaptateurs nécessaires pour utiliser les capacités réutilisables du workspace sans déplacer leur logique métier dans l’interface.
|
||||
`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 ;
|
||||
- transport HTTP JSON-RPC et WebSocket ;
|
||||
- diagnostics PostgreSQL, requêtes et replay candidates ;
|
||||
- backfill, extraction Core et replay de décodage ;
|
||||
- démonstrations SPL Token, Token-2022 et ATA ;
|
||||
- exécution Devnet Solana Core, SPL et metadata ;
|
||||
- affichage des plans, simulations, confirmations, postconditions et matérialisations ;
|
||||
- diagnostics PostgreSQL ;
|
||||
- backfill, extraction Core et replay ;
|
||||
- démonstrations Solana Core, SPL Memo, SPL Token, ATA et Token-2022 ;
|
||||
- panneau Metadata avec scénarios synthétiques, sélection du profil Devnet, préparation de la base et affichage structuré par le JSON viewer commun ;
|
||||
- progression, annulation et restauration de l’état des fenêtres.
|
||||
|
||||
## Frontière architecturale
|
||||
|
||||
La logique générique reste dans `kb-lib`, `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-onchain-transport`, `kb-store` et `kb-wallet`. Le desktop conserve uniquement les commandes Tauri minces, les modèles TS-RS et la présentation opérateur.
|
||||
Les commandes Tauri sont des adaptateurs minces. La logique réutilisable appartient à `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-lib`, `kb-store` et `kb-onchain-transport`.
|
||||
|
||||
## Validation
|
||||
Les scénarios UI Devnet/Testnet restent dans le desktop. Des tests automatisés parallèles peuvent reproduire les mêmes parcours dans `kb-pipeline-demo-scenarios`, sans migration ou suppression des scénarios UI.
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
## Statut Metaplex `0.4.7`
|
||||
|
||||
Le panneau distingue correctement les contrats synthétiques et le contexte Devnet. Les exécutions RPC réelles des 20 opérations courantes seront raccordées pendant `pre.013`, après achèvement des campagnes réutilisables de `pre.011` et `pre.012`.
|
||||
|
||||
## Documentation
|
||||
|
||||
- [USAGE.md](USAGE.md)
|
||||
- [TODO.md](TODO.md)
|
||||
- [CHANGELOG.md](CHANGELOG.md)
|
||||
- [Guide d’utilisation](USAGE.md)
|
||||
- [Travaux restant à réaliser](TODO.md)
|
||||
- [Historique des changements](CHANGELOG.md)
|
||||
|
||||
@@ -1,21 +1,22 @@
|
||||
<!-- file: kb-app-demo-desktop/TODO.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# TODO — kb-app-demo-desktop
|
||||
|
||||
## `0.4.7`
|
||||
## `0.4.7-pre.013` — démonstrations Metadata Devnet
|
||||
|
||||
- [ ] Exécution Metadata Devnet - ajouter les panneaux nécessaires aux scénarios complétés.
|
||||
- [ ] Commandes Tauri - raccorder les campagnes Metaplex Devnet réutilisables sans dupliquer leur logique.
|
||||
- [ ] Interface - permettre simulation et soumission explicitement confirmée pour les opérations courantes disponibles.
|
||||
- [ ] Contexte - afficher profil, cluster, base, wallet, mode, signature, slot et preuves de postcondition.
|
||||
- [ ] Cohérence - conserver en parallèle les scénarios synthétiques et empêcher qu’ils soient présentés comme preuves réseau.
|
||||
- [ ] Validation manuelle - exécuter les parcours disponibles et confirmer la cohérence préflight, simulation, confirmation, soumission et postconditions.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
- [ ] Architecture - poursuivre l’extraction des scénarios réutilisables vers `kb-pipeline-demo-scenarios`.
|
||||
- [ ] Documentation - produire un guide opérateur des fenêtres et effets réseau.
|
||||
- [ ] Sécurité - réévaluer les capabilities Tauri lors de l’ajout d’une nouvelle fenêtre ou commande.
|
||||
- [ ] Documentation - produire un guide opérateur complet des fenêtres et effets réseau.
|
||||
- [ ] Sécurité - réévaluer les capabilities Tauri lors de l’ajout d’une nouvelle fenêtre ou commande sensible.
|
||||
|
||||
## Report conditionnel — registre ElGamal
|
||||
|
||||
- [ ] Registre ElGamal - confirmer le déploiement réseau et la disponibilité des preuves avant de rendre le panneau exécutable.
|
||||
- [ ] Registre ElGamal - raccorder un handler uniquement après validation d’un scénario réutilisable hors desktop.
|
||||
|
||||
- Validation manuelle Metaplex — exécuter les parcours réseau disponibles et confirmer la cohérence préflight/simulation/postconditions pendant `0.4.7-pre.010`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-app-demo-desktop/USAGE.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Utilisation de kb-app-demo-desktop
|
||||
|
||||
@@ -245,18 +245,16 @@ La base validée de `pre.062` contient 117 tests pour cette crate.
|
||||
- les payloads Tauri sont une API applicative spécifique au frontend ;
|
||||
- l’application nécessite un environnement graphique pour sa validation complète.
|
||||
|
||||
## Ouvrir le panneau Exécution Metadata Devnet
|
||||
## Panneau Exécution Metadata
|
||||
|
||||
Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metadata Devnet**. Le panneau charge l’inventaire canonique par la commande Tauri `demo_execution_metadata_scenarios`, puis affiche pour chaque scénario :
|
||||
Depuis la fenêtre principale, choisir **Exécution Devnet → Exécution Metadata**. Le panneau permet actuellement :
|
||||
|
||||
- les codes d’opération ;
|
||||
- les exigences de collection et de rule set ;
|
||||
- les contrôles de préflight ;
|
||||
- la politique simulation-first ;
|
||||
- les preuves de postcondition requises.
|
||||
- de choisir un scénario synthétique ou un contrat de campagne Devnet ;
|
||||
- de sélectionner le profil Devnet ;
|
||||
- de préparer et vérifier la base PostgreSQL du profil ;
|
||||
- d’afficher les contrats, contrôles de préflight et preuves attendues dans le JSON viewer commun ;
|
||||
- de restaurer le scénario sélectionné lors de la réouverture.
|
||||
|
||||
Le scénario sélectionné est conservé dans le stockage local de la WebView et restauré à la réouverture.
|
||||
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.
|
||||
|
||||
## Exécution metadata Devnet
|
||||
|
||||
Depuis **Exécution Devnet → Metadata**, ouvrir la fenêtre `demo_execution_metadata`. L’accordéon Metaplex sépare les scénarios synthétiques des scénarios Devnet et conserve une structure extensible pour SPL Token Metadata. Les résultats JSON sont rendus avec le composant `json_viewer` partagé.
|
||||
Les commandes de simulation et de soumission Metaplex seront documentées ici après leur raccordement effectif pendant `0.4.7-pre.013`.
|
||||
|
||||
@@ -1,61 +1,45 @@
|
||||
<!-- file: kb-lib/CHANGELOG.md -->
|
||||
<!-- version: 13 -->
|
||||
<!-- version: 15 -->
|
||||
|
||||
# CHANGELOG — kb-lib
|
||||
|
||||
## 0.4.7-pre.011 — réouverture des validations réseau
|
||||
|
||||
### Documentation
|
||||
|
||||
- réorganisation de `README.md`, `USAGE.md`, `TODO.md` et du changelog selon leur rôle documentaire ;
|
||||
- suppression des tâches Metaplex terminées du TODO ;
|
||||
- maintien des campagnes réseau hors du TODO de `kb-lib`, la surface de builders étant achevée.
|
||||
|
||||
## 0.4.7-pre.006 — fermeture de l’exécuteur Metaplex
|
||||
|
||||
- fermeture des 35 opérations officiellement constructibles : 20 courantes et 15 dépréciées ;
|
||||
- ajout des éditions historiques constructibles, use authority, escrow, mint, migrate, use, collect, print et resize ;
|
||||
- ajout des éditions, use authority, escrow, mint, migrate, use, collect, print et resize ;
|
||||
- conservation des 22 instructions remplacées en decode-only et de Bubblegum comme frontière externe ;
|
||||
- construction des instructions restantes depuis le contrat IDL exact, avec comptes, signers, mutabilité et arguments Borsh officiels ;
|
||||
- extension des tests unitaires d’intent, builder et capability ;
|
||||
- fermeture de la matrice des 58 discriminants avant l’intégration pipeline.
|
||||
- extension des tests unitaires d’intent, builder, capability, PDA et signers.
|
||||
|
||||
## 0.4.7-pre.005 — programmable NFTs et délégations
|
||||
|
||||
- ajout des wrappers officiels `Burn`, `Delegate`, `Revoke`, `Lock`, `Unlock`, `Transfer` et `CloseAccounts` ;
|
||||
- validation du couplage des comptes Token Authorization Rules et maintien de la simulation obligatoire ;
|
||||
- exposition des codes d’opération, bindings TS-RS et capacités exactes correspondantes ;
|
||||
- ajout de tests unitaires dans `intent.rs`, `builder.rs` et `executor.rs` ;
|
||||
- maintien des versions remplacées en decode-only avec renvoi vers leur wrapper canonique.
|
||||
- validation des comptes Token Authorization Rules et maintien de la simulation obligatoire.
|
||||
|
||||
## 0.4.7-pre.004 — collections, créateurs et autorités
|
||||
|
||||
- ajout des wrappers courants `Verify` et `Unverify` pour les créateurs et collections ;
|
||||
- ajout de `SetCollectionSize` comme opération officiellement constructible mais dépréciée, soumise à approbation opérateur explicite ;
|
||||
- validation des combinaisons de comptes creator/collection et des PDA collection metadata/master edition ;
|
||||
- ajout des codes d’opération, exports publics, bindings et tests unitaires correspondants ;
|
||||
- maintien des anciennes instructions de vérification remplacées en decode-only.
|
||||
- ajout des wrappers courants `Verify` et `Unverify` ;
|
||||
- ajout de `SetCollectionSize` comme opération dépréciée soumise à approbation explicite.
|
||||
|
||||
## 0.4.7-pre.003 — fondations de l’exécuteur Metaplex
|
||||
|
||||
### Correctif `0.4.7-pre.003-delta-fix-003`
|
||||
|
||||
- ajout de tests unitaires dans `intent.rs`, `builder.rs` et `executor.rs` pour la surface Metaplex introduite en `pre.003` ;
|
||||
- vérification des codes d’opération, de la partition des opérations dépréciées, des politiques fail-closed, des PDA metadata/edition, du builder `PuffMetadata`, des capacités exactes et de la parité entre dispatch typé et générique.
|
||||
|
||||
### Correctif `0.4.7-pre.003-delta-fix-002`
|
||||
|
||||
- suppression de la dépendance directe inutile à `solana-program` dans le workspace et `kb-lib` ;
|
||||
- utilisation des types modulaires `solana_instruction::Instruction` et `solana_pubkey::Pubkey` pour le contrat interne ;
|
||||
- conversion locale des types de compatibilité retournés par `mpl-token-metadata 5.1.1`, sans exposer ni dépendre directement de `solana-program` ;
|
||||
- suppression de tous les opérateurs `?` introduits par la surface Metaplex `pre.003` ;
|
||||
- ajout des TODO de réaudit des exécuteurs Solana Core/SPL et de leur orchestration pipeline selon la nouvelle règle des opérations remplacées et obsolètes.
|
||||
|
||||
- remplacement de l’exécuteur réservé par une surface typée initiale ;
|
||||
- builders courants `Create` et `UpdateAsUpdateAuthorityV2` fondés sur `mpl-token-metadata` ;
|
||||
- validation des PDA metadata/edition, des signers autorisés, des comptes de rule set et des plafonds de coût ;
|
||||
- simulation et dry-run obligatoires pour cette première tranche ;
|
||||
- correction de la classification des instructions remplacées et obsolètes.
|
||||
- remplacement de l’exécuteur réservé par une surface typée ;
|
||||
- ajout des builders `Create`, `Update`, `PuffMetadata` et `SetTokenStandard` ;
|
||||
- correction des dépendances Solana modulaires, suppression des opérateurs `?` introduits et ajout des tests de parité ;
|
||||
- classification des opérations courantes, remplacées et obsolètes constructibles.
|
||||
|
||||
## 0.4.7-pre.002 — contrat Metaplex fermé
|
||||
|
||||
- classification exhaustive des 58 discriminants Metaplex Token Metadata ;
|
||||
- comptes positionnels et signers importés de l’IDL archivée `V1_14_0` ;
|
||||
- classification exhaustive des 58 discriminants ;
|
||||
- propriété unique des faits metadata, admin, lifecycle et risk/compliance ;
|
||||
- exposition directe des créateurs, collection, uses, token standard et programmable config dans le snapshot metadata autoritatif ;
|
||||
- tests contractuels d’exhaustivité, d’unicité et de séparation avec Token-2022.
|
||||
- séparation contractuelle avec Token-2022.
|
||||
|
||||
## 0.4.6
|
||||
|
||||
|
||||
@@ -1,70 +1,64 @@
|
||||
<!-- file: kb-lib/README.md -->
|
||||
<!-- version: 17 -->
|
||||
<!-- version: 19 -->
|
||||
|
||||
# kb-lib
|
||||
|
||||
`kb-lib` est la bibliothèque fonctionnelle consolidée de `khadhroony-bot3`. Elle expose les modèles partagés, les contrats et implémentations de décodage, de matérialisation, d’exécution et de sécurité nécessaires au pipeline Solana.
|
||||
|
||||
- Metaplex Token Metadata expose les wrappers canoniques courants et conserve les opérations obsolètes encore constructibles sous une API Rust `#[deprecated]` avec approbation opérateur explicite ; les versions remplacées ne reçoivent qu’un renvoi vers leur remplacement canonique final.
|
||||
`kb-lib` est la bibliothèque fonctionnelle consolidée de `khadhroony-bot3`. Elle fournit les modèles, décodeurs, matérialisateurs, exécuteurs et contrats de sécurité indépendants du transport, du stockage et de l’interface utilisateur.
|
||||
|
||||
## Périmètre
|
||||
|
||||
La crate regroupe quatre familles internes, exposées par la façade `kb_lib` :
|
||||
La crate couvre actuellement Solana Core, SPL Memo, SPL Token classique, SPL Associated Token Account, Token-2022, le registre SPL ElGamal et Metaplex Token Metadata.
|
||||
|
||||
- décodeurs et contrats de décodage contextualisé ;
|
||||
- exécuteurs, plans préparés et politiques de sécurité ;
|
||||
- matérialisateurs et projections structurées ;
|
||||
- modèles canoniques utilisés par les autres crates.
|
||||
Pour Metaplex Token Metadata, elle fournit :
|
||||
|
||||
Elle couvre actuellement Solana Core, SPL Memo, SPL Token classique, SPL Associated Token Account, Token-2022, le registre SPL ElGamal et le décodeur Metaplex Token Metadata. De nombreux décodeurs et exécuteurs réservés exposent seulement une identité et une compatibilité conservatrice ; ils ne constituent pas une implémentation fonctionnelle.
|
||||
- le décodage des 58 discriminants et des principales familles de comptes ;
|
||||
- la propriété unique des faits metadata, admin, lifecycle et risk/compliance ;
|
||||
- 20 opérations courantes exécutables ;
|
||||
- 15 opérations obsolètes encore constructibles, exposées comme dépréciées et soumises à une approbation explicite ;
|
||||
- 22 versions remplacées conservées en décodage uniquement et redirigées vers leur remplacement canonique final ;
|
||||
- une frontière explicite avec Bubblegum et avec les metadata incorporées de Token-2022.
|
||||
|
||||
## Responsabilités
|
||||
|
||||
- reconnaître et décoder une instruction à partir d’un contexte canonique ;
|
||||
- publier des déclarations de couverture déterministes ;
|
||||
- reconnaître et décoder des instructions contextualisées ;
|
||||
- décoder les comptes on-chain pris en charge ;
|
||||
- produire des observations et diagnostics typés ;
|
||||
- construire des plans d’exécution bornés et vérifiables ;
|
||||
- appliquer les politiques de sécurité avant simulation, signature ou envoi ;
|
||||
- matérialiser les observations commitées selon des contrats explicites ;
|
||||
- conserver des modèles indépendants du stockage, du transport et de l’interface desktop.
|
||||
- matérialiser les faits stables et prouvés ;
|
||||
- construire des plans d’exécution bornés ;
|
||||
- déclarer les comptes, signers, coûts et confirmations nécessaires ;
|
||||
- appliquer les garde-fous fail-closed avant simulation, signature ou envoi ;
|
||||
- exposer des modèles indépendants du RPC, de PostgreSQL et de Tauri.
|
||||
|
||||
## Hors périmètre
|
||||
|
||||
`kb-lib` ne persiste aucune donnée, ne dialogue pas directement avec un RPC, ne sélectionne pas un endpoint et ne gère pas les secrets de wallet. Ces responsabilités appartiennent respectivement à `kb-store`, `kb-onchain-transport`, `kb-pipeline` et `kb-wallet`.
|
||||
`kb-lib` ne sélectionne aucun endpoint, ne lit pas directement un RPC, ne persiste aucune donnée, ne gère pas les secrets de wallet et ne soumet aucune transaction.
|
||||
|
||||
## Surface publique principale
|
||||
|
||||
La façade publique est organisée autour de :
|
||||
- contrats `DcApi*` et décodeurs concrets `Dc*Decoder` ;
|
||||
- parseurs de comptes et d’états bornés ;
|
||||
- contrats `MtApi*` et matérialisateurs concrets ;
|
||||
- contrats `ExApi*`, politiques de sécurité et exécuteurs `Ex*Executor` ;
|
||||
- `ExMetadataMetaplexTokenMetadataExecutor`, `ExMetaplexTokenMetadataExecutionIntent` et `ExMetaplexTokenMetadataOperation` ;
|
||||
- modèles canoniques `Md*` réexportés par la façade.
|
||||
|
||||
- `DcApiInstructionDecoder`, `DcApiProtocolDecoder` et les types `DcApi*` ;
|
||||
- les décodeurs concrets `DcSolanaCoreDecoder`, `DcSplMemoDecoder`, `DcSplTokenDecoder`, `DcSplAssociatedTokenAccountDecoder`, `DcSplToken2022Decoder`, `DcSplElgamalRegistryDecoder` et `DcMetadataMetaplexTokenMetadataDecoder` ;
|
||||
- `ExApiTypedInstructionExecutor`, `ExApiInstructionExecutor`, les politiques `ExApi*` et les exécuteurs concrets `Ex*Executor` ;
|
||||
- `ExSafetyChecker` et les décisions de sécurité associées ;
|
||||
- `MtApiEventMaterializer`, les types `MtApi*` et les matérialisateurs concrets ;
|
||||
- `MdCoreInstructionReplayInput` et les modèles canoniques réexportés.
|
||||
Les exemples d’appel et invariants sont documentés dans [USAGE.md](USAGE.md).
|
||||
|
||||
Le catalogue détaillé et les exemples se trouvent dans [USAGE.md](USAGE.md).
|
||||
## Relations avec le workspace
|
||||
|
||||
## Matrices contractuelles
|
||||
|
||||
Les matrices actives sont maintenues sous [`../test-fixtures/contract-matrices/`](../test-fixtures/contract-matrices/). Elles servent à la fois de références documentaires et de fixtures exécutées par des tests. Elles ne sont pas dupliquées dans la documentation de la crate.
|
||||
|
||||
## Relations
|
||||
|
||||
- dépend de `kb-core` pour le contrat d’erreur commun ;
|
||||
- dépend de `kb-program-ids` pour le registre canonique des programmes ;
|
||||
- dépend de `kb-core` et `kb-program-ids` ;
|
||||
- est consommée par `kb-pipeline`, `kb-store`, `kb-onchain-transport`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
|
||||
- ne dépend jamais de `kb-store` ni d’une application.
|
||||
- ne dépend jamais de `kb-store`, `kb-pipeline` ni d’une application.
|
||||
|
||||
## Statut et limites
|
||||
|
||||
La migration des surfaces historiques jusqu’à un périmètre proche de bot2 `0.4.6` est largement réalisée. Le décodeur Metaplex Token Metadata couvre les 58 discriminants et les matérialisations possèdent désormais un contrat fermé de propriété des faits. L’exécuteur Metaplex ferme désormais les 35 opérations officiellement constructibles : 20 opérations courantes et 15 opérations obsolètes conservées sous `#[deprecated]` avec approbation opérateur explicite. Les 22 versions remplacées restent decode-only et Bubblegum demeure une frontière externe. La fermeture inclut les éditions, uses, escrow, mint, print, collect, migrate et resize. Le registre ElGamal n’est pas déclaré validé sur Devnet ou Mainnet.
|
||||
La surface fonctionnelle Metaplex de la crate est achevée. Les campagnes Devnet restantes relèvent de `kb-pipeline-demo-scenarios` et de `kb-app-demo-desktop`, non d’un manque de builder dans `kb-lib`.
|
||||
|
||||
## Documents
|
||||
Le registre ElGamal n’est pas déclaré validé réellement sur réseau.
|
||||
|
||||
- [Utilisation](USAGE.md)
|
||||
- [Travaux restants](TODO.md)
|
||||
- [Historique de la crate](CHANGELOG.md)
|
||||
- [Architecture générale](../docs/architecture/ARCHITECTURE.md)
|
||||
- [Pipeline](../docs/architecture/PIPELINE_ARCHITECTURE.md)
|
||||
- [Matrice des surfaces](../docs/architecture/SURFACE_CRATE_MATRIX.md)
|
||||
## Documentation
|
||||
|
||||
- [Guide d’utilisation](USAGE.md)
|
||||
- [Travaux restant à réaliser](TODO.md)
|
||||
- [Historique des changements](CHANGELOG.md)
|
||||
- [Matrice contractuelle Metaplex](../test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_MATRIX.json)
|
||||
|
||||
@@ -1,39 +1,22 @@
|
||||
<!-- file: kb-lib/TODO.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# TODO — kb-lib
|
||||
|
||||
## `0.4.7` — Metaplex Token Metadata
|
||||
## Réaudit ultérieur des exécuteurs déjà livrés
|
||||
|
||||
- [x] établir le contrat fermé de couverture et de propriété des faits ;
|
||||
- [x] introduire les intents et builders courants `Create`/`Update` ;
|
||||
- [x] achever les wrappers courants Verify/Unverify et l’opération dépréciée SetCollectionSize ;
|
||||
- [x] achever délégations et opérations pNFT `Burn`/`Lock`/`Unlock`/`Transfer`/`CloseAccounts` ;
|
||||
- [x] achever éditions, use, escrow et opérations courantes restantes en `pre.006` ;
|
||||
|
||||
## Entre `0.4.6` et `0.4.7` — Metaplex Token Metadata
|
||||
|
||||
- [x] Matérialisation - vérifier la couverture exacte migrée depuis bot2.
|
||||
- [x] Matérialisation - compléter uniquement les projections réellement manquantes et fermer leur propriété unique.
|
||||
- [x] Exécution - implémenter l’exécuteur à partir des contrats officiels vérifiés.
|
||||
- [x] Tests - ajouter les tests unitaires et contractuels de l’exécuteur.
|
||||
- [ ] Intégration - préparer les contrats nécessaires au pipeline et aux démonstrations.
|
||||
- [ ] Validation - valider le parcours complet sur un réseau approprié lorsque les prérequis sont réunis.
|
||||
- [ ] Version à déterminer - réauditer les exécuteurs Solana Core et SPL selon la règle distinguant les opérations courantes, remplacées et obsolètes encore constructibles.
|
||||
- [ ] Solana Core - vérifier chaque génération historique ou obsolète officiellement constructible et ajouter les opérations dépréciées manquantes sans réexposer les versions remplacées intermédiaires.
|
||||
- [ ] SPL Memo - réexaminer Memo v1 et Memo v3 et documenter leur statut exact de remplacement ou d’obsolescence constructible.
|
||||
- [ ] SPL Token, ATA, Token-2022 et registre ElGamal - appliquer la même classification opération par opération.
|
||||
- [ ] Matrices - aligner statuts, annotations `#[deprecated]`, approbations opérateur et tests de parité des surfaces réauditées.
|
||||
|
||||
## Report conditionnel — registre SPL ElGamal
|
||||
|
||||
- [ ] Réseau - confirmer si le registre est déployé et utilisable sur Devnet ou Mainnet.
|
||||
- [ ] Fixture - préparer une preuve `PubkeyValidity` et un compte `Proof Context State` valide si un réseau exploitable est confirmé.
|
||||
- [ ] Fixture - préparer une preuve `PubkeyValidity` et un compte `Proof Context State` valides si un réseau exploitable est confirmé.
|
||||
- [ ] Validation - exécuter une validation réseau réelle avant de déclarer la surface validée.
|
||||
|
||||
## Réaudit ultérieur des exécuteurs déjà livrés
|
||||
|
||||
- [ ] Version à déterminer - réauditer les exécuteurs Solana Core et SPL déjà implémentés selon la règle distinguant les opérations courantes, remplacées et obsolètes constructibles.
|
||||
- [ ] Solana Core - vérifier chaque génération historique ou obsolète officiellement constructible et ajouter les opérations dépréciées manquantes sans réexposer les versions remplacées intermédiaires.
|
||||
- [ ] SPL Memo - réexaminer notamment Memo v1 et Memo v3 : conserver uniquement le remplacement canonique pour les versions remplacées et implémenter comme dépréciée toute génération obsolète encore légitimement constructible.
|
||||
- [ ] SPL Token, ATA, Token-2022 et registre ElGamal - vérifier la même règle opération par opération, documenter les remplacements canoniques et compléter les builders dépréciés manquants.
|
||||
- [ ] Matrices - aligner les statuts, annotations `#[deprecated]`, approbations opérateur et tests de parité de toutes les surfaces concernées.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
- [ ] Surfaces - remplacer les décodeurs et exécuteurs réservés selon le ROADMAP.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-lib/USAGE.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Utilisation de kb-lib
|
||||
|
||||
@@ -117,7 +117,6 @@ println!("edition parent={:?}", edition.parent);
|
||||
|
||||
Les signatures exactes doivent être vérifiées lors de l’utilisation : certaines familles exigent un contexte ou une identité canonique supplémentaire.
|
||||
|
||||
|
||||
## Exécution typée
|
||||
|
||||
`ExApiTypedInstructionExecutor` produit un `ExApiPreparedExecutionPlan` à partir d’une intention et d’une politique explicites. Les exécuteurs concrets incluent notamment :
|
||||
@@ -157,6 +156,22 @@ println!("required_signers={}", plan.required_signers.len());
|
||||
|
||||
Memo v1 et v3 restent non exécutables. Memo v4 est la seule génération exécutable.
|
||||
|
||||
## Exécution Metaplex Token Metadata
|
||||
|
||||
La surface publique repose sur :
|
||||
|
||||
- `ExMetadataMetaplexTokenMetadataExecutor` ;
|
||||
- `ExMetaplexTokenMetadataExecutionIntent` ;
|
||||
- `ExMetaplexTokenMetadataOperation` ;
|
||||
- les constantes `EX_METAPLEX_TOKEN_METADATA_*_OPERATION` ;
|
||||
- `EX_METAPLEX_TOKEN_METADATA_SUPPORTED_OPERATION_CODES` et `EX_METAPLEX_TOKEN_METADATA_DEPRECATED_OPERATION_CODES`.
|
||||
|
||||
Le consommateur construit un intent typé, puis appelle `ExApiTypedInstructionExecutor::build_prepared_plan`. Le plan retourné contient les instructions, comptes et signers requis, mais n’effectue ni simulation ni envoi.
|
||||
|
||||
Les opérations courantes utilisent leur wrapper canonique final. Les versions remplacées ne possèdent pas de builder public distinct. Les opérations obsolètes encore constructibles exigent que l’intent autorise explicitement l’exécution dépréciée ; leurs variantes Rust sont marquées `#[deprecated]`.
|
||||
|
||||
Avant utilisation du plan, le consommateur doit transmettre celui-ci au préflight et à l’orchestration de `kb-pipeline`.
|
||||
|
||||
## Sécurité
|
||||
|
||||
Les types `ExSafetyChecker`, `ExSafetyDecision`, `ExSafetyEvaluation` et `ExSafetyViolation` permettent d’évaluer un plan avant son utilisation. Une décision conservatrice doit être respectée par le consommateur ; elle ne doit pas être contournée par l’application.
|
||||
|
||||
@@ -1,23 +1,39 @@
|
||||
<!-- file: kb-pipeline-demo-scenarios/CHANGELOG.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 14 -->
|
||||
|
||||
# CHANGELOG — kb-pipeline-demo-scenarios
|
||||
|
||||
## 0.4.7-pre.010
|
||||
## 0.4.7-pre.011 — réouverture des campagnes Devnet Metaplex
|
||||
|
||||
- ajout d’un corpus fermé de validation croisée Metaplex couvrant outer/CPI, succès/échec, cinq familles d’actifs et neuf classes d’erreur ;
|
||||
- ajout de trois contrats de preuve réseau distincts pour simulation, soumission et postcondition ;
|
||||
- refus machine-readable de toute promotion réseau fondée uniquement sur des preuves synthétiques.
|
||||
### Exécution Devnet
|
||||
|
||||
## 0.4.7-pre.009-fix-001
|
||||
- ajout d’un exécuteur Metaplex Devnet réel, simulation-first et limité aux opérations non dépréciées ;
|
||||
- contrôle du genesis hash Devnet, du wallet de profil, des signers et des plafonds de coût ;
|
||||
- ajout des lectures stateful avant/après, du préflight, de la simulation RPC exacte, de la soumission contrôlée et de la confirmation ;
|
||||
- ajout d’une matrice fermée des 20 opérations courantes, avec `Create`, `Update`, `Verify` et `Unverify` attribuées au premier lot `pre.011` ;
|
||||
- conservation de tous les statuts réseau à `not_run` tant qu’aucune preuve locale n’a été observée.
|
||||
|
||||
### Documentation
|
||||
|
||||
- réorganisation des quatre documents de crate ;
|
||||
- ajout des lots `pre.011` et `pre.012` au TODO pour couvrir les 20 opérations courantes sur Devnet ;
|
||||
- clarification du rôle ciblé du CLI et du maintien des scénarios UI dans le desktop.
|
||||
|
||||
## 0.4.7-pre.010 — corpus de validation croisée
|
||||
|
||||
- ajout d’un corpus fermé couvrant outer/CPI, succès/échec, cinq familles d’actifs et neuf classes d’erreur ;
|
||||
- ajout de contrats distincts de preuve réseau pour simulation, soumission et postcondition ;
|
||||
- refus de toute promotion réseau fondée uniquement sur des preuves synthétiques.
|
||||
|
||||
## 0.4.7-pre.009
|
||||
|
||||
- ajout de l’inventaire Metaplex Devnet simulation et de son test de couverture.
|
||||
|
||||
## 0.4.7-pre.008
|
||||
|
||||
- ajout de l’inventaire synthétique Metaplex NFT, SFT, fungible, collection et pNFT ;
|
||||
- ajout de la matrice de validation automatisée Devnet/Testnet et de ses preuves bornées ;
|
||||
- conservation du CLI sans nouvelle commande, aucune fixture Metaplex réseau dédiée n’étant encore nécessaire.
|
||||
- ajout des scénarios synthétiques NFT, SFT, token fongible, collection et pNFT ;
|
||||
- ajout de la matrice de validation Devnet/Testnet ;
|
||||
- conservation du CLI sans commande Metaplex non justifiée.
|
||||
|
||||
## 0.4.6
|
||||
|
||||
|
||||
@@ -1,31 +1,37 @@
|
||||
<!-- file: kb-pipeline-demo-scenarios/README.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# kb-pipeline-demo-scenarios
|
||||
|
||||
`kb-pipeline-demo-scenarios` fournit des scénarios opérateur et Devnet réutilisables au-dessus de `kb-pipeline`.
|
||||
`kb-pipeline-demo-scenarios` fournit des scénarios synthétiques et des campagnes Devnet/Testnet automatisables au-dessus de `kb-pipeline`.
|
||||
|
||||
La crate est mixte :
|
||||
La crate contient :
|
||||
|
||||
- bibliothèque Rust `kb_pipeline_demo_scenarios` ;
|
||||
- binaire `kb-pipeline-demo-scenarios-cli`.
|
||||
- la bibliothèque Rust `kb_pipeline_demo_scenarios` ;
|
||||
- le binaire ciblé `kb-pipeline-demo-scenarios-cli`.
|
||||
|
||||
## Responsabilités
|
||||
|
||||
- préparation de l’environnement et du profil Devnet ;
|
||||
- scénarios System Program, Memo v4, ATA, SPL Token et Token-2022 ;
|
||||
- simulation ou soumission explicitement autorisée ;
|
||||
- préparation de fixtures publiques ;
|
||||
- validation des matrices et rapports Token-2022 ;
|
||||
- scénarios synthétiques et matrice de validation Metaplex Token Metadata ;
|
||||
- corpus fermé de validation croisée outer/CPI, cas positifs/négatifs et preuves réseau exactes ;
|
||||
- progression observable et annulation coopérative.
|
||||
- préparer les profils, comptes et fixtures nécessaires aux campagnes de test ;
|
||||
- exécuter des scénarios synthétiques déterministes ;
|
||||
- exécuter des campagnes réseau explicites avec simulation ou soumission contrôlée ;
|
||||
- produire des résultats structurés et des preuves vérifiables ;
|
||||
- fournir des tests automatisés parallèles aux démonstrations UI, sans déplacer les scénarios UI hors du desktop ;
|
||||
- conserver la séparation entre preuve synthétique, simulation RPC, soumission confirmée et postcondition stateful.
|
||||
|
||||
Elle ne remplace ni le pipeline générique ni l’application desktop.
|
||||
La crate couvre déjà les scénarios Solana Core et SPL historiques ainsi que le corpus synthétique Metaplex pour NFT, SFT, token fongible, collection et pNFT. Un exécuteur Devnet réel et réutilisable est disponible pour les opérations Metaplex courantes pilotées par un seul wallet de profil. Il réalise le contrôle du genesis hash, les lectures stateful bornées, le préflight, la simulation RPC exacte et, après confirmation explicite, la soumission, la confirmation et les lectures avant/après. La préparation complète des fixtures et la couverture des 20 opérations restent réparties entre `0.4.7-pre.011` et `pre.012`.
|
||||
|
||||
## Binaire CLI
|
||||
|
||||
Le CLI a été introduit pour les préparations de fixtures qui nécessitent une commande autonome, notamment Token-2022. Il n’est pas l’interface générale obligatoire de tous les scénarios. Une commande Metaplex ne doit être ajoutée que si une préparation de fixture ne peut pas être réalisée proprement par les tests ou APIs existantes.
|
||||
|
||||
## Relations avec le workspace
|
||||
|
||||
La crate dépend du pipeline généraliste. `kb-pipeline` ne dépend jamais d’elle. Le desktop peut réutiliser ses contrats, mais conserve ses propres scénarios UI Devnet/Testnet.
|
||||
|
||||
## Documentation
|
||||
|
||||
- [USAGE.md](USAGE.md)
|
||||
- [TODO.md](TODO.md)
|
||||
- [CHANGELOG.md](CHANGELOG.md)
|
||||
- [Guide d’utilisation](USAGE.md)
|
||||
- [Travaux restant à réaliser](TODO.md)
|
||||
- [Historique des changements](CHANGELOG.md)
|
||||
- [Architecture du pipeline](../docs/architecture/PIPELINE_ARCHITECTURE.md)
|
||||
|
||||
@@ -1,20 +1,28 @@
|
||||
<!-- file: kb-pipeline-demo-scenarios/TODO.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# TODO — kb-pipeline-demo-scenarios
|
||||
|
||||
## `0.4.7`
|
||||
## `0.4.7-pre.011` — infrastructure et premier lot Devnet Metaplex
|
||||
|
||||
- [x] Corpus croisé Metaplex - fermer les chemins outer/CPI, cinq familles d’actifs, échecs transactionnels et entrées invalides.
|
||||
- [ ] Tests réseau Metaplex - exécuter les validations Devnet/Testnet lorsque les fixtures, comptes et fonds nécessaires sont disponibles.
|
||||
- [ ] Preuves Metaplex - renseigner les signatures, simulations et postconditions observées sans déclarer de validation réseau non exécutée.
|
||||
- [ ] Infrastructure - préparer des fixtures Devnet réutilisables pour les familles d’actifs nécessaires.
|
||||
- [x] Exécution réseau - raccorder les intents Metaplex courants au transport RPC réel et au pipeline généraliste.
|
||||
- [x] Contrat de preuves - exposer cluster, genesis hash, simulation exacte, signature, confirmation et états stateful avant/après dans le résultat structuré.
|
||||
- [ ] Preuves observées - exécuter les campagnes locales et reporter les valeurs RPC effectivement observées dans la matrice.
|
||||
- [ ] Premier lot - préparer puis valider sur Devnet `Create`, `Update`, `Verify` et `Unverify` avec le wallet de profil et les fixtures requises.
|
||||
|
||||
## Série `0.5.x`
|
||||
## `0.4.7-pre.012` — couverture Devnet restante
|
||||
|
||||
- [ ] CLI - rendre chaque scénario public exécutable hors `kb-app-demo-desktop`.
|
||||
- [ ] CLI - compléter les arguments, sorties structurées et diagnostics.
|
||||
- [ ] Fixtures - améliorer la création, la réutilisation et la validation des fixtures publiques.
|
||||
- [ ] Documentation - ajouter un guide opérateur des scénarios et de leurs effets réseau.
|
||||
- [ ] Couverture - fournir un scénario réel pour chacune des 20 opérations `executable_current`.
|
||||
- [ ] Soumission - soumettre et confirmer les opérations réalisables avec les fixtures disponibles.
|
||||
- [ ] Non-exécutabilité - documenter par opération toute impossibilité Devnet avec une cause technique et des préconditions vérifiées.
|
||||
- [ ] Tests - empêcher toute promotion d’un résultat synthétique en preuve réseau.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
- [ ] CLI - ajouter uniquement les commandes de préparation de fixtures explicitement justifiées.
|
||||
- [ ] Fixtures - améliorer la réutilisation, le nettoyage et la validation des fixtures publiques.
|
||||
- [ ] Documentation - maintenir un guide opérateur des campagnes et de leurs effets réseau.
|
||||
|
||||
## Report conditionnel — registre ElGamal
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-pipeline-demo-scenarios/USAGE.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Utilisation de kb-pipeline-demo-scenarios
|
||||
|
||||
@@ -234,3 +234,47 @@ fn load_metaplex_cross_validation() -> kb_core::Result<usize> {
|
||||
```
|
||||
|
||||
Les cas marqués `requiresNetworkEvidence` ne peuvent pas être déclarés validés à partir de preuves synthétiques. Une simulation, une soumission ou une confirmation exige les preuves RPC déclarées par le cas.
|
||||
|
||||
|
||||
## Simuler une opération Metaplex réelle sur Devnet
|
||||
|
||||
L’API réseau prend un intent Metaplex typé déjà lié aux comptes et autorités de la fixture. Le wallet persistant du profil doit être l’unique signer requis.
|
||||
|
||||
```rust
|
||||
async fn simulate_metaplex_operation<O>(
|
||||
pool: &kb_onchain_transport::HttpEndpointPool,
|
||||
profile: &kb_config::ProfileConfig,
|
||||
workspace_root: &std::path::Path,
|
||||
operation: kb_lib::ExMetaplexTokenMetadataOperation,
|
||||
observer: &O,
|
||||
) -> kb_core::Result<kb_pipeline_demo_scenarios::DevnetMetaplexTokenMetadataExecutionSummary>
|
||||
where
|
||||
O: kb_pipeline_demo_scenarios::SolanaExecutionObserver,
|
||||
{
|
||||
let request = kb_pipeline_demo_scenarios::DevnetMetaplexTokenMetadataExecutionRequest::new(
|
||||
"metaplex-devnet-simulation",
|
||||
operation,
|
||||
);
|
||||
return kb_pipeline_demo_scenarios::simulate_devnet_metaplex_token_metadata(
|
||||
pool,
|
||||
profile,
|
||||
workspace_root,
|
||||
&request,
|
||||
observer,
|
||||
)
|
||||
.await;
|
||||
}
|
||||
```
|
||||
|
||||
Pour une soumission, l’appelant doit définir `submit = true` et `operator_confirmed = true`. Les opérations dépréciées sont refusées par cette API automatique. Les lectures `preflight_reads` et `postcondition_reads` doivent décrire les comptes Metadata, Edition, Token Record ou Collection nécessaires au scénario.
|
||||
|
||||
## Charger la matrice des 20 opérations courantes
|
||||
|
||||
```rust
|
||||
fn load_metaplex_devnet_contract(
|
||||
) -> kb_core::Result<kb_pipeline_demo_scenarios::MetaplexTokenMetadataDevnetExecutionMatrix> {
|
||||
return kb_pipeline_demo_scenarios::load_metaplex_token_metadata_devnet_execution_matrix();
|
||||
}
|
||||
```
|
||||
|
||||
La matrice ne transforme jamais une implémentation disponible en validation réseau. Les valeurs restent `not_run` jusqu’à l’observation d’une simulation ou d’une confirmation réelle.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-pipeline-demo-scenarios/src/lib.rs
|
||||
// version: 8
|
||||
// version: 9
|
||||
|
||||
#![forbid(unsafe_code)]
|
||||
#![deny(unreachable_pub)]
|
||||
@@ -12,6 +12,7 @@ mod environment;
|
||||
mod solana_ata_execution;
|
||||
mod solana_execution;
|
||||
mod solana_memo_execution;
|
||||
mod solana_metaplex_token_metadata_devnet_execution;
|
||||
mod solana_metaplex_token_metadata_scenarios;
|
||||
mod solana_metaplex_token_metadata_validation;
|
||||
mod solana_token_2022_devnet_execution;
|
||||
@@ -67,6 +68,14 @@ pub use self::solana_memo_execution::DevnetMemoExecutionRequest;
|
||||
pub use self::solana_memo_execution::DevnetMemoExecutionSummary;
|
||||
/// Executes one SPL Memo v4 Devnet simulation or explicitly authorized submission.
|
||||
pub use self::solana_memo_execution::execute_devnet_memo;
|
||||
/// Complete request for one real Devnet Metaplex Token Metadata execution.
|
||||
pub use self::solana_metaplex_token_metadata_devnet_execution::DevnetMetaplexTokenMetadataExecutionRequest;
|
||||
/// Complete evidence produced by one real Devnet Metaplex Token Metadata execution.
|
||||
pub use self::solana_metaplex_token_metadata_devnet_execution::DevnetMetaplexTokenMetadataExecutionSummary;
|
||||
/// Executes one real Devnet Metaplex simulation or explicitly authorized submission.
|
||||
pub use self::solana_metaplex_token_metadata_devnet_execution::execute_devnet_metaplex_token_metadata;
|
||||
/// Simulates one current Metaplex operation against a real Devnet endpoint.
|
||||
pub use self::solana_metaplex_token_metadata_devnet_execution::simulate_devnet_metaplex_token_metadata;
|
||||
/// Stable asset family covered by one Metaplex scenario.
|
||||
pub use self::solana_metaplex_token_metadata_scenarios::MetaplexTokenMetadataAssetFamily;
|
||||
/// One stable Metaplex scenario reusable by automated tests and demo adapters.
|
||||
@@ -83,6 +92,10 @@ pub use self::solana_metaplex_token_metadata_validation::MAX_METAPLEX_TOKEN_META
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataCrossValidationCase;
|
||||
/// Closed Metaplex cross-validation corpus for `0.4.7-pre.010`.
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataCrossValidationMatrix;
|
||||
/// Closed inventory of every current Metaplex operation requiring Devnet coverage.
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataDevnetExecutionMatrix;
|
||||
/// One current Metaplex operation in the closed Devnet execution matrix.
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataDevnetExecutionOperation;
|
||||
/// Stable failure category exercised by one negative case.
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataFailureClass;
|
||||
/// Expected transaction outcome for one cross-validation case.
|
||||
@@ -99,10 +112,14 @@ pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataVa
|
||||
pub use self::solana_metaplex_token_metadata_validation::MetaplexTokenMetadataValidationStatus;
|
||||
/// Loads and validates the closed Metaplex cross-validation corpus.
|
||||
pub use self::solana_metaplex_token_metadata_validation::load_metaplex_token_metadata_cross_validation_matrix;
|
||||
/// Loads and validates the closed Devnet execution matrix.
|
||||
pub use self::solana_metaplex_token_metadata_validation::load_metaplex_token_metadata_devnet_execution_matrix;
|
||||
/// Loads and validates the canonical Metaplex validation matrix.
|
||||
pub use self::solana_metaplex_token_metadata_validation::load_metaplex_token_metadata_validation_matrix;
|
||||
/// Validates the closed Metaplex cross-validation corpus and evidence claims.
|
||||
pub use self::solana_metaplex_token_metadata_validation::validate_metaplex_token_metadata_cross_validation_matrix;
|
||||
/// Validates exact current-operation coverage and conservative network statuses.
|
||||
pub use self::solana_metaplex_token_metadata_validation::validate_metaplex_token_metadata_devnet_execution_matrix;
|
||||
/// Validates the canonical Metaplex validation matrix.
|
||||
pub use self::solana_metaplex_token_metadata_validation::validate_metaplex_token_metadata_validation_matrix;
|
||||
/// Complete request for one Devnet Token-2022 execution.
|
||||
|
||||
@@ -0,0 +1,608 @@
|
||||
// file: kb-pipeline-demo-scenarios/src/solana_metaplex_token_metadata_devnet_execution.rs
|
||||
// version: 1
|
||||
|
||||
//! Real Devnet simulation and submission for current Metaplex Token Metadata operations.
|
||||
|
||||
/// Complete request for one real Devnet Metaplex Token Metadata execution.
|
||||
#[derive(Clone, Debug, PartialEq)]
|
||||
pub struct DevnetMetaplexTokenMetadataExecutionRequest {
|
||||
/// Stable caller-provided execution identifier.
|
||||
pub intent_id: std::string::String,
|
||||
/// Endpoint role used for reads, balance, blockhash and fee queries.
|
||||
pub query_role: std::string::String,
|
||||
/// Endpoint role used for simulation, submission and confirmation.
|
||||
pub transaction_role: std::string::String,
|
||||
/// Exact current Metaplex operation.
|
||||
pub operation: kb_lib::ExMetaplexTokenMetadataOperation,
|
||||
/// Bounded state reads required before execution.
|
||||
pub preflight_reads: std::vec::Vec<kb_pipeline::MetaplexTokenMetadataStatefulReadRequest>,
|
||||
/// Bounded state reads repeated after confirmed submission.
|
||||
pub postcondition_reads: std::vec::Vec<kb_pipeline::MetaplexTokenMetadataStatefulReadRequest>,
|
||||
/// Explicitly authorizes signing and submission after successful simulation.
|
||||
pub submit: bool,
|
||||
/// Explicit operator confirmation required for submission.
|
||||
pub operator_confirmed: bool,
|
||||
}
|
||||
|
||||
impl crate::DevnetMetaplexTokenMetadataExecutionRequest {
|
||||
/// Creates a conservative simulation-only request.
|
||||
pub fn new(
|
||||
intent_id: impl std::convert::Into<std::string::String>,
|
||||
operation: kb_lib::ExMetaplexTokenMetadataOperation,
|
||||
) -> Self {
|
||||
return Self {
|
||||
intent_id: intent_id.into(),
|
||||
query_role: "http_queries".to_string(),
|
||||
transaction_role: "http_transactions".to_string(),
|
||||
operation,
|
||||
preflight_reads: std::vec::Vec::new(),
|
||||
postcondition_reads: std::vec::Vec::new(),
|
||||
submit: false,
|
||||
operator_confirmed: false,
|
||||
};
|
||||
}
|
||||
|
||||
/// Validates request-local bounds and rejects deprecated operations.
|
||||
pub fn validate(&self) -> kb_core::Result<()> {
|
||||
if self.intent_id.trim().is_empty() {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Devnet Metaplex execution intent id must not be empty",
|
||||
));
|
||||
}
|
||||
if self.query_role.trim().is_empty() || self.transaction_role.trim().is_empty() {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Devnet Metaplex execution endpoint roles must not be empty",
|
||||
));
|
||||
}
|
||||
if self.preflight_reads.len() > kb_pipeline::MAX_METAPLEX_TOKEN_METADATA_PREFLIGHT_ACCOUNTS
|
||||
|| self.postcondition_reads.len()
|
||||
> kb_pipeline::MAX_METAPLEX_TOKEN_METADATA_PREFLIGHT_ACCOUNTS
|
||||
{
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Devnet Metaplex execution stateful read limit exceeded",
|
||||
));
|
||||
}
|
||||
let operation_code = self.operation.operation_code();
|
||||
if kb_lib::EX_METAPLEX_TOKEN_METADATA_DEPRECATED_OPERATION_CODES.contains(&operation_code) {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_metaplex_devnet_deprecated_operation_forbidden",
|
||||
"automatic Devnet campaigns do not execute deprecated Metaplex operations",
|
||||
));
|
||||
}
|
||||
return std::result::Result::Ok(());
|
||||
}
|
||||
}
|
||||
|
||||
/// Complete evidence produced by one real Devnet Metaplex execution.
|
||||
#[derive(Clone, Debug, PartialEq)]
|
||||
pub struct DevnetMetaplexTokenMetadataExecutionSummary {
|
||||
/// Profile used by the orchestration.
|
||||
pub profile_name: std::string::String,
|
||||
/// Exact classified cluster.
|
||||
pub cluster: kb_lib::ExApiExecutionCluster,
|
||||
/// Genesis hash returned by the selected endpoint.
|
||||
pub genesis_hash: std::string::String,
|
||||
/// Non-secret persistent wallet description.
|
||||
pub wallet: kb_wallet::WalletSummary,
|
||||
/// Wallet balance observed before planning.
|
||||
pub balance_lamports: u64,
|
||||
/// Stateful snapshots observed before simulation.
|
||||
pub before: std::vec::Vec<kb_pipeline::MetaplexTokenMetadataStatefulReadResult>,
|
||||
/// Stateful preflight report bound to the exact plan.
|
||||
pub stateful_preflight: kb_pipeline::MetaplexTokenMetadataPreflightReport,
|
||||
/// Exact prepared Metaplex plan.
|
||||
pub plan: kb_lib::ExApiPreparedExecutionPlan,
|
||||
/// Recent blockhash used by the exact transaction.
|
||||
pub latest_blockhash: kb_onchain_transport::LatestBlockhashResult,
|
||||
/// Fee estimate for the exact compiled message.
|
||||
pub fee: kb_onchain_transport::FeeForMessageResult,
|
||||
/// Exact real RPC simulation result.
|
||||
pub simulation: kb_lib::ExApiExecutionSimulationResult,
|
||||
/// Readiness report proving exact-message simulation and signer resolution.
|
||||
pub readiness: kb_pipeline::MetaplexTokenMetadataExecutionReadinessReport,
|
||||
/// Submission result when explicitly authorized.
|
||||
pub send_result: std::option::Option<kb_lib::ExApiExecutionSendResult>,
|
||||
/// Confirmation result when submitted.
|
||||
pub confirmation: std::option::Option<kb_lib::ExApiExecutionConfirmationResult>,
|
||||
/// Stateful snapshots observed after confirmed submission.
|
||||
pub after: std::vec::Vec<kb_pipeline::MetaplexTokenMetadataStatefulReadResult>,
|
||||
}
|
||||
|
||||
struct PreparedMetaplexExecution {
|
||||
wallet: kb_wallet::TemporaryWallet,
|
||||
unsigned: kb_lib::ExSolanaUnsignedTransaction,
|
||||
evidence: kb_lib::ExSolanaSimulationEvidence,
|
||||
summary: crate::DevnetMetaplexTokenMetadataExecutionSummary,
|
||||
}
|
||||
|
||||
/// Simulates one current Metaplex operation against a real Devnet endpoint.
|
||||
pub async fn simulate_devnet_metaplex_token_metadata<O>(
|
||||
http_pool: &kb_onchain_transport::HttpEndpointPool,
|
||||
profile: &kb_config::ProfileConfig,
|
||||
workspace_root: &std::path::Path,
|
||||
request: &crate::DevnetMetaplexTokenMetadataExecutionRequest,
|
||||
observer: &O,
|
||||
) -> kb_core::Result<crate::DevnetMetaplexTokenMetadataExecutionSummary>
|
||||
where
|
||||
O: crate::SolanaExecutionObserver,
|
||||
{
|
||||
if request.submit {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"simulate_devnet_metaplex_token_metadata requires submit=false",
|
||||
));
|
||||
}
|
||||
let prepared =
|
||||
match prepare_execution(http_pool, profile, workspace_root, request, observer).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
return std::result::Result::Ok(prepared.summary);
|
||||
}
|
||||
|
||||
/// Executes one real Devnet Metaplex simulation or explicitly authorized submission.
|
||||
pub async fn execute_devnet_metaplex_token_metadata<O>(
|
||||
http_pool: &kb_onchain_transport::HttpEndpointPool,
|
||||
profile: &kb_config::ProfileConfig,
|
||||
workspace_root: &std::path::Path,
|
||||
request: &crate::DevnetMetaplexTokenMetadataExecutionRequest,
|
||||
observer: &O,
|
||||
) -> kb_core::Result<crate::DevnetMetaplexTokenMetadataExecutionSummary>
|
||||
where
|
||||
O: crate::SolanaExecutionObserver,
|
||||
{
|
||||
let prepared =
|
||||
match prepare_execution(http_pool, profile, workspace_root, request, observer).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if !request.submit {
|
||||
return std::result::Result::Ok(prepared.summary);
|
||||
}
|
||||
if !prepared.summary.simulation.success {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_simulation_failed",
|
||||
crate::simulation_failure_message(&prepared.summary.simulation),
|
||||
));
|
||||
}
|
||||
if let std::result::Result::Err(error) = validate_profile_wallet_signers(
|
||||
prepared.unsigned.required_signer_pubkeys(),
|
||||
prepared.summary.wallet.public_key.as_str(),
|
||||
) {
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
let send_evaluation = match kb_lib::ExSafetyChecker
|
||||
.evaluate_send(&prepared.summary.plan, &prepared.summary.simulation)
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if send_evaluation.decision == kb_lib::ExSafetyDecision::Deny {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_send_denied",
|
||||
crate::violation_message(send_evaluation.violations.as_slice()),
|
||||
));
|
||||
}
|
||||
let signed = match prepared
|
||||
.unsigned
|
||||
.sign_after_simulation(&prepared.evidence, &[prepared.wallet.as_signer()])
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if let std::result::Result::Err(error) = signed.verify_signatures() {
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
let signature = signed.primary_signature().clone();
|
||||
let mut summary = prepared.summary;
|
||||
let send_config = match kb_onchain_transport::SendTransactionConfig::from_execution_config(
|
||||
&profile.execution,
|
||||
std::option::Option::Some(summary.latest_blockhash.context.slot),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let sent = match http_pool
|
||||
.send_transaction_for_role(
|
||||
request.transaction_role.as_str(),
|
||||
signed.transaction_base64().as_str(),
|
||||
&signature,
|
||||
&send_config,
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
summary.send_result =
|
||||
std::option::Option::Some(sent.to_execution_result(kb_lib::ExApiExecutionCluster::Devnet));
|
||||
let confirmation_config =
|
||||
match kb_onchain_transport::ConfirmTransactionConfig::from_execution_config(
|
||||
&profile.execution,
|
||||
std::option::Option::Some(summary.latest_blockhash.last_valid_block_height),
|
||||
std::option::Option::Some(summary.latest_blockhash.context.slot),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let confirmation = match http_pool
|
||||
.confirm_transaction_for_roles(
|
||||
request.transaction_role.as_str(),
|
||||
request.query_role.as_str(),
|
||||
kb_lib::ExApiExecutionCluster::Devnet,
|
||||
&signature,
|
||||
&confirmation_config,
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let confirmed = matches!(
|
||||
confirmation.status,
|
||||
kb_lib::ExApiExecutionConfirmationStatus::Confirmed
|
||||
| kb_lib::ExApiExecutionConfirmationStatus::Finalized
|
||||
);
|
||||
summary.confirmation = std::option::Option::Some(confirmation);
|
||||
if confirmed {
|
||||
summary.after = match read_snapshots(http_pool, &request.postcondition_reads).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
}
|
||||
return std::result::Result::Ok(summary);
|
||||
}
|
||||
|
||||
async fn prepare_execution<O>(
|
||||
http_pool: &kb_onchain_transport::HttpEndpointPool,
|
||||
profile: &kb_config::ProfileConfig,
|
||||
workspace_root: &std::path::Path,
|
||||
request: &crate::DevnetMetaplexTokenMetadataExecutionRequest,
|
||||
observer: &O,
|
||||
) -> kb_core::Result<PreparedMetaplexExecution>
|
||||
where
|
||||
O: crate::SolanaExecutionObserver,
|
||||
{
|
||||
if let std::result::Result::Err(error) = request.validate() {
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
if let std::result::Result::Err(error) = validate_profile(profile, request) {
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
if let std::result::Result::Err(error) =
|
||||
crate::ensure_not_cancelled(observer, "metaplex_validate")
|
||||
{
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
let genesis = match http_pool.get_genesis_hash_for_role(request.query_role.as_str()).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if genesis.classified_cluster
|
||||
!= std::option::Option::Some(kb_lib::ExApiExecutionCluster::Devnet)
|
||||
{
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_cluster_mismatch",
|
||||
format!(
|
||||
"expected Devnet genesis hash but endpoint returned {} classified as {:?}",
|
||||
genesis.genesis_hash, genesis.classified_cluster
|
||||
),
|
||||
));
|
||||
}
|
||||
let wallet = match crate::load_profile_wallet(profile, workspace_root).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let wallet_summary = wallet.summary();
|
||||
let fee_payer = kb_lib::MdPubkey(wallet_summary.public_key.clone());
|
||||
let balance = match http_pool
|
||||
.get_balance_for_role(
|
||||
request.query_role.as_str(),
|
||||
&fee_payer,
|
||||
&kb_onchain_transport::GetBalanceConfig::confirmed(),
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if balance.lamports < profile.execution.max_fee_lamports {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_balance_insufficient",
|
||||
"Devnet wallet balance is below the configured fee ceiling",
|
||||
));
|
||||
}
|
||||
let plan = match build_plan(profile, request, fee_payer.clone()) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let before = match read_snapshots(http_pool, &request.preflight_reads).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let stateful_preflight = match kb_pipeline::inspect_metaplex_token_metadata_preflight(
|
||||
&kb_pipeline::MetaplexTokenMetadataPreflightRequest {
|
||||
plan: plan.clone(),
|
||||
snapshots: before.clone(),
|
||||
allow_deprecated_operation: false,
|
||||
},
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let plan_evaluation = match kb_lib::ExSafetyChecker.evaluate_prepared_plan(&plan) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if plan_evaluation.decision == kb_lib::ExSafetyDecision::Deny {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_plan_denied",
|
||||
crate::violation_message(plan_evaluation.violations.as_slice()),
|
||||
));
|
||||
}
|
||||
let latest_blockhash = match http_pool
|
||||
.get_latest_blockhash_for_role(
|
||||
request.query_role.as_str(),
|
||||
&kb_onchain_transport::GetLatestBlockhashConfig::confirmed(),
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let unsigned = match kb_lib::executor_solana_build_legacy_transaction(
|
||||
&plan,
|
||||
latest_blockhash.blockhash.as_str(),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
if let std::result::Result::Err(error) = validate_profile_wallet_signers(
|
||||
unsigned.required_signer_pubkeys(),
|
||||
wallet_summary.public_key.as_str(),
|
||||
) {
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
let fee = match http_pool
|
||||
.get_fee_for_message_for_role(
|
||||
request.query_role.as_str(),
|
||||
unsigned.message_base64().as_str(),
|
||||
&kb_onchain_transport::GetFeeForMessageConfig::new(
|
||||
kb_onchain_transport::RpcCommitmentLevel::Confirmed,
|
||||
std::option::Option::Some(latest_blockhash.context.slot),
|
||||
),
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let unsigned_base64 = match unsigned.transaction_base64() {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let simulation_config = match kb_onchain_transport::SimulateTransactionConfig::new(
|
||||
kb_onchain_transport::RpcCommitmentLevel::Confirmed,
|
||||
false,
|
||||
false,
|
||||
std::option::Option::Some(latest_blockhash.context.slot),
|
||||
true,
|
||||
std::option::Option::None,
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
crate::emit(
|
||||
observer,
|
||||
crate::SolanaExecutionProgressLevel::Info,
|
||||
"metaplex_token_metadata_simulation",
|
||||
format!("simulating exact Metaplex message {}", unsigned.message_hash()),
|
||||
std::option::Option::None,
|
||||
);
|
||||
let simulation_rpc = match http_pool
|
||||
.simulate_transaction_for_role(
|
||||
request.transaction_role.as_str(),
|
||||
unsigned_base64.as_str(),
|
||||
&simulation_config,
|
||||
)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let simulation = simulation_rpc.to_execution_result(
|
||||
kb_lib::ExApiExecutionCluster::Devnet,
|
||||
kb_lib::ExApiExecutionBlockhashKind::Latest,
|
||||
std::option::Option::Some(
|
||||
simulation_rpc.context.slot.saturating_sub(latest_blockhash.context.slot),
|
||||
),
|
||||
std::option::Option::None,
|
||||
std::option::Option::None,
|
||||
std::option::Option::Some(&fee),
|
||||
);
|
||||
let readiness = match kb_pipeline::validate_metaplex_token_metadata_execution_readiness(
|
||||
&kb_pipeline::MetaplexTokenMetadataExecutionReadinessRequest {
|
||||
plan: plan.clone(),
|
||||
preflight: stateful_preflight.clone(),
|
||||
message_hash: unsigned.message_hash().to_string(),
|
||||
simulated_message_hash: unsigned.message_hash().to_string(),
|
||||
simulated: true,
|
||||
simulation_succeeded: simulation.success,
|
||||
resolved_signers: vec![fee_payer],
|
||||
submit: request.submit,
|
||||
operator_confirmed: request.operator_confirmed,
|
||||
},
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
let evidence = unsigned.bind_simulation(simulation.clone());
|
||||
return std::result::Result::Ok(PreparedMetaplexExecution {
|
||||
wallet,
|
||||
unsigned,
|
||||
evidence,
|
||||
summary: crate::DevnetMetaplexTokenMetadataExecutionSummary {
|
||||
profile_name: profile.name.clone(),
|
||||
cluster: kb_lib::ExApiExecutionCluster::Devnet,
|
||||
genesis_hash: genesis.genesis_hash,
|
||||
wallet: wallet_summary,
|
||||
balance_lamports: balance.lamports,
|
||||
before,
|
||||
stateful_preflight,
|
||||
plan,
|
||||
latest_blockhash,
|
||||
fee,
|
||||
simulation,
|
||||
readiness,
|
||||
send_result: std::option::Option::None,
|
||||
confirmation: std::option::Option::None,
|
||||
after: std::vec::Vec::new(),
|
||||
},
|
||||
});
|
||||
}
|
||||
|
||||
async fn read_snapshots(
|
||||
http_pool: &kb_onchain_transport::HttpEndpointPool,
|
||||
requests: &[kb_pipeline::MetaplexTokenMetadataStatefulReadRequest],
|
||||
) -> kb_core::Result<std::vec::Vec<kb_pipeline::MetaplexTokenMetadataStatefulReadResult>> {
|
||||
let mut results = std::vec::Vec::with_capacity(requests.len());
|
||||
for request in requests {
|
||||
let value =
|
||||
match kb_pipeline::read_metaplex_token_metadata_stateful_snapshot(http_pool, request)
|
||||
.await
|
||||
{
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
results.push(value);
|
||||
}
|
||||
return std::result::Result::Ok(results);
|
||||
}
|
||||
|
||||
fn build_plan(
|
||||
profile: &kb_config::ProfileConfig,
|
||||
request: &crate::DevnetMetaplexTokenMetadataExecutionRequest,
|
||||
fee_payer: kb_lib::MdPubkey,
|
||||
) -> kb_core::Result<kb_lib::ExApiPreparedExecutionPlan> {
|
||||
let intent = kb_lib::ExMetaplexTokenMetadataExecutionIntent {
|
||||
intent_id: request.intent_id.clone(),
|
||||
fee_payer: fee_payer.clone(),
|
||||
max_rent_lamports: profile.execution.devnet_max_spend_lamports,
|
||||
policy: kb_lib::ExApiExecutionPolicy {
|
||||
cluster: kb_lib::ExApiExecutionClusterPolicy {
|
||||
expected_cluster: kb_lib::ExApiExecutionCluster::Devnet,
|
||||
allow_mainnet: false,
|
||||
mainnet_confirmation: false,
|
||||
},
|
||||
simulation: kb_lib::ExApiExecutionSimulationPolicy::Required,
|
||||
blockhash: kb_lib::ExApiExecutionBlockhashPolicy {
|
||||
kind: kb_lib::ExApiExecutionBlockhashKind::Latest,
|
||||
max_age_slots: std::option::Option::Some(
|
||||
profile.execution.recent_blockhash_max_age_slots,
|
||||
),
|
||||
nonce_account: std::option::Option::None,
|
||||
nonce_authority: std::option::Option::None,
|
||||
},
|
||||
cost_limit: kb_lib::ExApiExecutionCostLimit {
|
||||
max_spend_lamports: std::option::Option::Some(
|
||||
profile.execution.devnet_max_spend_lamports,
|
||||
),
|
||||
max_fee_lamports: std::option::Option::Some(profile.execution.max_fee_lamports),
|
||||
max_compute_unit_price_micro_lamports: std::option::Option::Some(
|
||||
profile.execution.max_compute_unit_price_micro_lamports,
|
||||
),
|
||||
},
|
||||
authorized_signers: vec![fee_payer],
|
||||
dry_run: !request.submit,
|
||||
post_execution_validation: kb_lib::ExApiPostExecutionValidationPolicy {
|
||||
canonical_insert_required: request.submit,
|
||||
core_extraction_required: request.submit,
|
||||
decode_replay_required: request.submit,
|
||||
materialization_required: request.submit,
|
||||
},
|
||||
},
|
||||
allow_deprecated_operation: false,
|
||||
operation: request.operation.clone(),
|
||||
};
|
||||
return kb_lib::ExApiTypedInstructionExecutor::build_prepared_plan(
|
||||
&kb_lib::ExMetadataMetaplexTokenMetadataExecutor,
|
||||
&intent,
|
||||
);
|
||||
}
|
||||
|
||||
fn validate_profile(
|
||||
profile: &kb_config::ProfileConfig,
|
||||
request: &crate::DevnetMetaplexTokenMetadataExecutionRequest,
|
||||
) -> kb_core::Result<()> {
|
||||
if profile.wallet.cluster != "devnet" {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Metaplex Devnet orchestration requires a Devnet wallet profile",
|
||||
));
|
||||
}
|
||||
if !profile.wallet.temporary_wallet_enabled || !profile.wallet.temporary_wallet_persist {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Metaplex Devnet orchestration requires an enabled persistent temporary wallet",
|
||||
));
|
||||
}
|
||||
if !profile.execution.require_simulation {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Metaplex Devnet orchestration requires simulation",
|
||||
));
|
||||
}
|
||||
if request.submit && !profile.wallet.devnet_send_enabled {
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Devnet transaction submission is disabled by the wallet profile",
|
||||
));
|
||||
}
|
||||
if request.submit
|
||||
&& profile.execution.require_operator_confirmation
|
||||
&& !request.operator_confirmed
|
||||
{
|
||||
return std::result::Result::Err(kb_core::Error::config(
|
||||
"Metaplex Devnet submission requires explicit operator confirmation",
|
||||
));
|
||||
}
|
||||
return std::result::Result::Ok(());
|
||||
}
|
||||
|
||||
fn validate_profile_wallet_signers(
|
||||
required_signers: &[std::string::String],
|
||||
wallet_pubkey: &str,
|
||||
) -> kb_core::Result<()> {
|
||||
if required_signers.iter().any(|value| return value.as_str() != wallet_pubkey) {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"execution_metaplex_external_signer_unavailable",
|
||||
format!(
|
||||
"the Devnet Metaplex orchestrator can sign only with profile wallet {}; required signers are {}",
|
||||
wallet_pubkey,
|
||||
required_signers.join(",")
|
||||
),
|
||||
));
|
||||
}
|
||||
return std::result::Result::Ok(());
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
#[test]
|
||||
#[allow(deprecated)]
|
||||
fn request_rejects_deprecated_operations_and_empty_ids() {
|
||||
let deprecated = crate::DevnetMetaplexTokenMetadataExecutionRequest::new(
|
||||
"deprecated",
|
||||
kb_lib::ExMetaplexTokenMetadataOperation::PuffMetadata {
|
||||
metadata: kb_lib::MdPubkey("11111111111111111111111111111111".to_string()),
|
||||
},
|
||||
);
|
||||
assert!(deprecated.validate().is_err());
|
||||
let mut empty = deprecated;
|
||||
empty.intent_id.clear();
|
||||
assert!(empty.validate().is_err());
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn signer_guard_rejects_external_authorities() {
|
||||
assert!(super::validate_profile_wallet_signers(&["wallet".to_string()], "wallet").is_ok());
|
||||
assert!(
|
||||
super::validate_profile_wallet_signers(&["external".to_string()], "wallet").is_err()
|
||||
);
|
||||
}
|
||||
}
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: kb-pipeline-demo-scenarios/src/solana_metaplex_token_metadata_validation.rs
|
||||
// version: 2
|
||||
// version: 3
|
||||
|
||||
//! Machine-readable Metaplex Token Metadata validation contract.
|
||||
|
||||
@@ -438,3 +438,162 @@ mod tests {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/// One current Metaplex operation in the closed Devnet execution matrix.
|
||||
#[derive(Clone, Debug, Eq, PartialEq, serde::Deserialize, serde::Serialize)]
|
||||
#[serde(rename_all = "camelCase")]
|
||||
pub struct MetaplexTokenMetadataDevnetExecutionOperation {
|
||||
/// Stable instruction discriminator.
|
||||
pub discriminator: u8,
|
||||
/// Official instruction name.
|
||||
pub name: std::string::String,
|
||||
/// Stable executor operation code.
|
||||
pub operation_code: std::string::String,
|
||||
/// Whether the operation is deprecated.
|
||||
pub deprecated: bool,
|
||||
/// Prerelease responsible for the campaign.
|
||||
pub campaign_prerelease: std::string::String,
|
||||
/// Implementation status of the reusable runner.
|
||||
pub runner_status: std::string::String,
|
||||
/// Exact observed network status.
|
||||
pub network_status: std::string::String,
|
||||
/// Evidence required after simulation.
|
||||
pub required_evidence: std::vec::Vec<std::string::String>,
|
||||
/// Additional evidence required after submission.
|
||||
pub submission_evidence: std::vec::Vec<std::string::String>,
|
||||
}
|
||||
|
||||
/// Closed inventory of every current Metaplex operation requiring Devnet coverage.
|
||||
#[derive(Clone, Debug, Eq, PartialEq, serde::Deserialize, serde::Serialize)]
|
||||
#[serde(rename_all = "camelCase")]
|
||||
pub struct MetaplexTokenMetadataDevnetExecutionMatrix {
|
||||
/// Matrix schema version.
|
||||
pub matrix_version: u32,
|
||||
/// Owning prerelease.
|
||||
pub milestone: std::string::String,
|
||||
/// Canonical Token Metadata program ID.
|
||||
pub program_id: std::string::String,
|
||||
/// Ordered current operations.
|
||||
pub operations: std::vec::Vec<crate::MetaplexTokenMetadataDevnetExecutionOperation>,
|
||||
}
|
||||
|
||||
/// Loads and validates the closed Devnet execution matrix.
|
||||
pub fn load_metaplex_token_metadata_devnet_execution_matrix()
|
||||
-> kb_core::Result<crate::MetaplexTokenMetadataDevnetExecutionMatrix> {
|
||||
let matrix = match serde_json::from_str::<crate::MetaplexTokenMetadataDevnetExecutionMatrix>(
|
||||
include_str!(
|
||||
"../../test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_DEVNET_EXECUTION_MATRIX.json"
|
||||
),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"metaplex_devnet_execution_matrix_invalid_json",
|
||||
format!("Metaplex Devnet execution matrix JSON is invalid: {error}"),
|
||||
));
|
||||
},
|
||||
};
|
||||
if let std::result::Result::Err(error) =
|
||||
validate_metaplex_token_metadata_devnet_execution_matrix(&matrix)
|
||||
{
|
||||
return std::result::Result::Err(error);
|
||||
}
|
||||
return std::result::Result::Ok(matrix);
|
||||
}
|
||||
|
||||
/// Validates exact current-operation coverage and conservative network statuses.
|
||||
pub fn validate_metaplex_token_metadata_devnet_execution_matrix(
|
||||
matrix: &crate::MetaplexTokenMetadataDevnetExecutionMatrix,
|
||||
) -> kb_core::Result<()> {
|
||||
if matrix.matrix_version != 1
|
||||
|| matrix.milestone != "0.4.7-pre.011"
|
||||
|| matrix.program_id != kb_program_ids::METADATA_METAPLEX_TOKEN_METADATA_PROGRAM_ID
|
||||
|| matrix.operations.len() != 20
|
||||
{
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"metaplex_devnet_execution_matrix_contract_mismatch",
|
||||
"Metaplex Devnet matrix must declare exactly 20 current operations for pre.011",
|
||||
));
|
||||
}
|
||||
let expected = [
|
||||
"metadata.metaplex_token_metadata.create_escrow_account",
|
||||
"metadata.metaplex_token_metadata.close_escrow_account",
|
||||
"metadata.metaplex_token_metadata.transfer_out_of_escrow",
|
||||
"metadata.metaplex_token_metadata.burn",
|
||||
"metadata.metaplex_token_metadata.create",
|
||||
"metadata.metaplex_token_metadata.mint",
|
||||
"metadata.metaplex_token_metadata.delegate",
|
||||
"metadata.metaplex_token_metadata.revoke",
|
||||
"metadata.metaplex_token_metadata.lock",
|
||||
"metadata.metaplex_token_metadata.unlock",
|
||||
"metadata.metaplex_token_metadata.migrate",
|
||||
"metadata.metaplex_token_metadata.transfer",
|
||||
"metadata.metaplex_token_metadata.update",
|
||||
"metadata.metaplex_token_metadata.use",
|
||||
"metadata.metaplex_token_metadata.verify",
|
||||
"metadata.metaplex_token_metadata.unverify",
|
||||
"metadata.metaplex_token_metadata.collect",
|
||||
"metadata.metaplex_token_metadata.print",
|
||||
"metadata.metaplex_token_metadata.resize",
|
||||
"metadata.metaplex_token_metadata.close_accounts",
|
||||
]
|
||||
.into_iter()
|
||||
.collect::<std::collections::BTreeSet<&str>>();
|
||||
let observed = matrix
|
||||
.operations
|
||||
.iter()
|
||||
.map(|operation| return operation.operation_code.as_str())
|
||||
.collect::<std::collections::BTreeSet<&str>>();
|
||||
if observed != expected {
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"metaplex_devnet_execution_matrix_operation_mismatch",
|
||||
"Metaplex Devnet matrix must cover the exact 20 current operation codes",
|
||||
));
|
||||
}
|
||||
for operation in &matrix.operations {
|
||||
if operation.deprecated
|
||||
|| operation.required_evidence.is_empty()
|
||||
|| operation.submission_evidence.is_empty()
|
||||
|| !matches!(
|
||||
operation.network_status.as_str(),
|
||||
"not_run" | "simulated" | "confirmed" | "unavailable"
|
||||
)
|
||||
{
|
||||
return std::result::Result::Err(kb_core::Error::new(
|
||||
"metaplex_devnet_execution_matrix_entry_invalid",
|
||||
"Metaplex Devnet entries must be current, evidenced and conservatively classified",
|
||||
));
|
||||
}
|
||||
}
|
||||
return std::result::Result::Ok(());
|
||||
}
|
||||
|
||||
#[cfg(test)]
|
||||
mod devnet_execution_matrix_tests {
|
||||
#[test]
|
||||
fn devnet_execution_matrix_is_closed_current_and_conservative() {
|
||||
let result = crate::load_metaplex_token_metadata_devnet_execution_matrix();
|
||||
assert!(result.is_ok());
|
||||
let matrix = if let std::result::Result::Ok(value) = result {
|
||||
value
|
||||
} else {
|
||||
return;
|
||||
};
|
||||
assert_eq!(matrix.operations.len(), 20);
|
||||
assert_eq!(
|
||||
matrix
|
||||
.operations
|
||||
.iter()
|
||||
.filter(|operation| return operation.campaign_prerelease == "0.4.7-pre.011")
|
||||
.count(),
|
||||
4,
|
||||
);
|
||||
assert!(matrix.operations.iter().all(|operation| return !operation.deprecated));
|
||||
assert!(
|
||||
matrix
|
||||
.operations
|
||||
.iter()
|
||||
.all(|operation| return operation.network_status == "not_run")
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,23 +1,20 @@
|
||||
<!-- file: kb-pipeline/CHANGELOG.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 14 -->
|
||||
|
||||
# CHANGELOG — kb-pipeline
|
||||
|
||||
## 0.4.7-pre.007-delta-fix-001 — correction et documentation de l’API Metaplex
|
||||
## 0.4.7-pre.011 — réouverture des validations réseau
|
||||
|
||||
- ajout de la rustdoc manquante sur les paramètres de dérivation des comptes edition et token record ;
|
||||
- correction du test de préflight utilisant le code stable de `PuffMetadata` ;
|
||||
- ajout d’exemples d’utilisation des lectures stateful, du préflight, de l’orchestration simulation-first et des postconditions Metaplex.
|
||||
### Documentation
|
||||
|
||||
## 0.4.7-pre.007
|
||||
- réorganisation des quatre documents de crate ;
|
||||
- clarification que les campagnes Devnet appartiennent à `kb-pipeline-demo-scenarios`, tandis que `kb-pipeline` reste généraliste et indépendant des scénarios.
|
||||
|
||||
- ajout des lectures stateful bornées Metaplex Token Metadata ;
|
||||
- ajout du préflight, de l’orchestration simulation-first et des postconditions explicites.
|
||||
## 0.4.7-pre.007 — orchestration Metaplex généraliste
|
||||
|
||||
## 0.4.7-pre.003-delta-fix-002 — dette de compatibilité des exécuteurs
|
||||
|
||||
- ajout d’un TODO de réaudit de l’orchestration après extension future des exécuteurs Solana Core/SPL aux opérations obsolètes encore constructibles ;
|
||||
- exigence de propager les avertissements de dépréciation et l’approbation opérateur sans réintroduire les versions remplacées intermédiaires.
|
||||
- ajout des lectures stateful bornées, du préflight, de l’orchestration simulation-first et des postconditions ;
|
||||
- correction de la rustdoc et ajout d’exemples publics ;
|
||||
- ajout des diagnostics de dépréciation et de l’approbation opérateur.
|
||||
|
||||
## 0.4.6
|
||||
|
||||
|
||||
@@ -1,36 +1,44 @@
|
||||
<!-- file: kb-pipeline/README.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# kb-pipeline
|
||||
|
||||
`kb-pipeline` orchestre les traitements on-chain de `khadhroony-bot3`.
|
||||
`kb-pipeline` est le pipeline généraliste de `khadhroony-bot3`. Il coordonne les transports, le stockage et `kb-lib` sans dépendre d’un scénario de démonstration ni d’un cluster particulier.
|
||||
|
||||
## Responsabilités
|
||||
|
||||
- backfill HTTP borné ;
|
||||
- extraction des transactions canoniques vers le modèle Core ;
|
||||
- replay contextualisé des décodeurs ;
|
||||
- matérialisation optionnelle et idempotente ;
|
||||
- préflights et inspections stateful ;
|
||||
- orchestration Token-2022 et Metaplex Token Metadata, preuves et postconditions ;
|
||||
- corrélation entre instructions observées et états finaux.
|
||||
|
||||
La crate coordonne `kb-onchain-transport`, `kb-store`, `kb-lib`, `kb-core` et `kb-program-ids`. Elle ne contient pas l’interface desktop ni les scénarios opérateur de démonstration.
|
||||
|
||||
## Familles publiques
|
||||
|
||||
- backfill ;
|
||||
- insertion canonique ;
|
||||
- extraction Core ;
|
||||
- decode replay ;
|
||||
- inspections stateful Solana Core, SPL Token, ATA, Token-2022 et registre ElGamal ;
|
||||
- préflights stateful et orchestrations d’exécution Token-2022 et Metaplex Token Metadata.
|
||||
- replay contextualisé ;
|
||||
- matérialisation optionnelle et idempotente ;
|
||||
- lectures stateful et corrélations ;
|
||||
- préflights d’exécution ;
|
||||
- résolution des signers ;
|
||||
- orchestration simulation-first, confirmation, soumission et postvalidation ;
|
||||
- diagnostics stables exploitables par des applications ou scénarios.
|
||||
|
||||
Voir [USAGE.md](USAGE.md) pour les contrats publics.
|
||||
Pour Metaplex Token Metadata, la crate expose les lectures stateful bornées, le préflight, la validation de readiness et l’agrégation des postconditions. Elle ne contient ni fixture Devnet, ni wallet de démonstration, ni séquence métier spécifique à un test.
|
||||
|
||||
## Surface publique principale
|
||||
|
||||
- campagnes de backfill et progression ;
|
||||
- extraction Core et decode replay ;
|
||||
- inspections stateful Solana Core et SPL ;
|
||||
- `read_metaplex_token_metadata_stateful_account` ;
|
||||
- `inspect_metaplex_token_metadata_preflight` ;
|
||||
- `validate_metaplex_token_metadata_execution_readiness` ;
|
||||
- `summarize_metaplex_token_metadata_postconditions`.
|
||||
|
||||
Voir [USAGE.md](USAGE.md) pour les exemples et invariants.
|
||||
|
||||
## Relations avec le workspace
|
||||
|
||||
La crate coordonne `kb-onchain-transport`, `kb-store`, `kb-lib`, `kb-core` et `kb-program-ids`. Elle ne dépend jamais de `kb-pipeline-demo-scenarios` ni de `kb-app-demo-desktop`.
|
||||
|
||||
## Documentation
|
||||
|
||||
- [USAGE.md](USAGE.md)
|
||||
- [TODO.md](TODO.md)
|
||||
- [CHANGELOG.md](CHANGELOG.md)
|
||||
- [Guide d’utilisation](USAGE.md)
|
||||
- [Travaux restant à réaliser](TODO.md)
|
||||
- [Historique des changements](CHANGELOG.md)
|
||||
- [Architecture du pipeline](../docs/architecture/PIPELINE_ARCHITECTURE.md)
|
||||
- [Architecture du stockage](../docs/architecture/STORAGE_ARCHITECTURE.md)
|
||||
|
||||
@@ -1,25 +1,19 @@
|
||||
<!-- file: kb-pipeline/TODO.md -->
|
||||
<!-- version: 8 -->
|
||||
<!-- version: 10 -->
|
||||
|
||||
# TODO — kb-pipeline
|
||||
|
||||
## `0.4.7`
|
||||
|
||||
- [x] Metaplex Token Metadata - intégrer les lectures stateful bornées, le préflight et l’orchestration simulation-first généraliste.
|
||||
- [x] Metaplex Token Metadata - ajouter la résolution des signers, les diagnostics de dépréciation et les postconditions explicites.
|
||||
- [ ] Metaplex Token Metadata - compléter en `pre.008` les fixtures et campagnes Devnet/Testnet dans `kb-pipeline-demo-scenarios`.
|
||||
|
||||
## Réaudit ultérieur des surfaces historiques
|
||||
|
||||
- [ ] Version à déterminer - après le réaudit des exécuteurs Solana Core et SPL dans `kb-lib`, vérifier que `kb-pipeline` orchestre sans filtrage implicite les opérations courantes et les opérations obsolètes explicitement approuvées.
|
||||
- [ ] Préflight et diagnostics - propager les statuts de remplacement canonique, les avertissements de dépréciation et l’approbation opérateur exigée par les builders obsolètes.
|
||||
- [ ] Tests - ajouter les cas pipeline nécessaires pour les opérations dépréciées réintroduites, sans créer de chemins d’exécution pour les versions remplacées intermédiaires.
|
||||
- [ ] Version à déterminer - après le réaudit des exécuteurs Solana Core et SPL dans `kb-lib`, vérifier que le pipeline orchestre sans filtrage implicite les opérations courantes et les opérations obsolètes explicitement approuvées.
|
||||
- [ ] Préflight et diagnostics - propager les remplacements canoniques, avertissements de dépréciation et approbations opérateur des surfaces réauditées.
|
||||
- [ ] Tests - ajouter les cas pipeline nécessaires aux opérations dépréciées réintroduites, sans créer de chemin pour les versions remplacées intermédiaires.
|
||||
|
||||
## Versions ultérieures
|
||||
|
||||
- [ ] Dette technique - auditer les duplications résiduelles entre orchestrations SPL Token classique et Token-2022.
|
||||
- [ ] Dette technique - auditer les duplications résiduelles entre les orchestrations SPL Token classique et Token-2022.
|
||||
|
||||
## Report conditionnel — registre ElGamal
|
||||
|
||||
- [ ] Réseau - confirmer l’existence et le déploiement du programme avant toute campagne.
|
||||
- [ ] Réseau - confirmer l’existence et le déploiement du programme avant toute campagne réelle.
|
||||
- [ ] Intégration - compléter uniquement les couches justifiées par un scénario réellement exécutable.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: kb-pipeline/USAGE.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Utilisation de kb-pipeline
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: olddocs/archivekbot3/001.README.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Archive documentaire de khadhroony-bot3
|
||||
|
||||
@@ -17,10 +17,14 @@ Les documents archivés :
|
||||
## Arborescence
|
||||
|
||||
- `docs/` : audits, plans et rapports bot3 remplacés ;
|
||||
- `prompts/` : prompts utilisés pendant la migration architecturale.
|
||||
- `prompts/` : prompts utilisés pendant la migration architecturale et les versions fonctionnelles clôturées.
|
||||
|
||||
La documentation active reste sous `docs/`. Le point d’entrée normatif reste `RULES.md`.
|
||||
|
||||
## Clôture 0.4.6
|
||||
|
||||
Les audits, guides et checklist temporaires utilisés pour clôturer la migration sont conservés sous `docs/` dans cette archive. Ils ne sont plus normatifs.
|
||||
|
||||
## Clôture 0.4.7
|
||||
|
||||
Le plan, le prompt de session et les rapports de prerelease de Metaplex Token Metadata sont archivés sous `docs/plans/`, `docs/validation/` et `prompts/`. Le rapport final actif reste sous `docs/validation/` jusqu’à la publication.
|
||||
|
||||
@@ -0,0 +1,603 @@
|
||||
<!-- file: olddocs/archivekbot3/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# Plan `0.4.7` — achèvement de Metaplex Token Metadata
|
||||
|
||||
## 1. Statut du document
|
||||
|
||||
Ce document constitue le livrable de planification de `0.4.7-pre.001`.
|
||||
|
||||
Il est temporaire et normatif pendant le développement de `0.4.7`. Il devra être mis à jour lorsque les preuves techniques imposent un changement d’ordre ou de périmètre, puis archivé sous `olddocs/archivekbot3/` pendant la prerelease finale après transfert de ses informations durables vers les documents actifs appropriés.
|
||||
|
||||
Aucune capacité fonctionnelle Metaplex nouvelle n’est introduite par cette prerelease. Le correctif `pre.001-delta-fix-001` intègre la relecture systématique de tous les documents actifs sous `docs/` et aligne ce plan sur leurs règles transversales.
|
||||
|
||||
## 2. Conclusion de l’audit initial
|
||||
|
||||
La reprise part de la base bot3 complète migrée depuis bot2. La migration elle-même n’est pas partielle.
|
||||
|
||||
La surface existante ne doit pas être réimplémentée :
|
||||
|
||||
- le Program ID canonique est enregistré ;
|
||||
- le décodeur d’instructions est enregistré au runtime ;
|
||||
- les 58 discriminants publics `0..57` sont inventoriés dans la matrice active ;
|
||||
- les instructions actuelles et historiques sont distinguées ;
|
||||
- les principales familles de comptes Metaplex sont décodées avec validation d’owner, PDA, seeds, longueurs et suffixes ;
|
||||
- un modèle canonique de comptes actifs, expérimentaux et historiques existe ;
|
||||
- la matérialisation de l’état metadata principal et des comptes canoniques existe déjà ;
|
||||
- la séparation avec les metadata incorporées de Token-2022 est explicite ;
|
||||
- l’exécuteur est enregistré mais reste réservé : support `Maybe`, zéro instruction construite et payload `reserved_executor` ;
|
||||
- aucune orchestration stateful Metaplex dédiée n’est encore présente dans `kb-pipeline` ;
|
||||
- aucun scénario CLI Metaplex réutilisable ni panneau desktop d’exécution Metaplex n’est encore présent.
|
||||
|
||||
La version `0.4.7` doit donc achever la surface autour de l’existant, pas recommencer le décodeur ou les projections déjà prouvées.
|
||||
|
||||
## 3. Frontière fermée de la version
|
||||
|
||||
### 3.1 Inclus
|
||||
|
||||
- audit de propriété des faits matérialisés ;
|
||||
- complétion ciblée des faits metadata, admin, lifecycle et risk/compliance réellement absents ;
|
||||
- classification exécutable, decode-only ou non supportée de chaque instruction ;
|
||||
- intents typés et builders de toutes les opérations officiellement constructibles, non obsolètes et non remplacées ;
|
||||
- préflight borné, politique de confirmation, simulation obligatoire et plafonds de dépense ;
|
||||
- lectures stateful et corrélations de comptes Metaplex ;
|
||||
- postconditions et postvalidation ;
|
||||
- intégration replay et matérialisation idempotente ;
|
||||
- scénarios UI Devnet/Testnet dans le desktop, fixtures et validations automatisées parallèles dans `kb-pipeline-demo-scenarios` ;
|
||||
- adaptateurs Tauri et panneaux strictement nécessaires ;
|
||||
- documentation et clôture de version.
|
||||
|
||||
### 3.2 Exclus
|
||||
|
||||
- JSON off-chain référencé par URI ;
|
||||
- fetch HTTP, IPFS ou Arweave ;
|
||||
- création de `kb-offchain-transport` ;
|
||||
- SPL Token Metadata ;
|
||||
- Metaplex Core ;
|
||||
- Metaplex Bubblegum au-delà des frontières explicitement nécessaires pour classer une instruction bridge ;
|
||||
- réécriture des décodeurs ou comptes déjà couverts sans écart démontré ;
|
||||
- validation réseau déclarée lorsque les fixtures ou autorités nécessaires ne sont pas disponibles.
|
||||
|
||||
Les sujets off-chain et SPL Token Metadata restent affectés à `0.4.8`.
|
||||
|
||||
## 4. Inventaire de la base réutilisable
|
||||
|
||||
### 4.1 Instructions
|
||||
|
||||
La matrice active inventorie 58 instructions :
|
||||
|
||||
- 41 actuelles ;
|
||||
- 15 historiques ;
|
||||
- 1 historique dépréciée ;
|
||||
- 1 bridge actuelle liée à Bubblegum.
|
||||
|
||||
Les familles déjà décodées comprennent notamment :
|
||||
|
||||
- création et mise à jour metadata V1, V2, V3 et wrappers modernes ;
|
||||
- vérification, dévérification et administration de collections ;
|
||||
- collections dimensionnées ;
|
||||
- autorités d’usage et utilisation ;
|
||||
- signature de créateur et primary sale ;
|
||||
- normalisation, token standard et unverification de créateur ;
|
||||
- master editions, printed editions et conversions historiques ;
|
||||
- délégation, révocation, transfert, burn, lock, unlock et fermeture ;
|
||||
- freeze/thaw historiques ;
|
||||
- escrow et collect ;
|
||||
- wrappers modernes `Create`, `Mint`, `Print`, `Update`, `Use`, `Verify` et `Unverify` ;
|
||||
- migration, resize et gaps historiques finaux.
|
||||
|
||||
Le statut `decode: unspecified` encore présent dans certaines entrées de matrice est un défaut documentaire de classification, pas une preuve d’absence automatique dans le code. Il devra être résolu par confrontation entre matrice, registre du décodeur et tests avant toute modification fonctionnelle.
|
||||
|
||||
### 4.2 Comptes
|
||||
|
||||
Les familles déjà couvertes comprennent :
|
||||
|
||||
- Metadata ;
|
||||
- Edition et Master Edition ;
|
||||
- Edition Marker ;
|
||||
- Token Record programmable ;
|
||||
- Metadata Delegate Record et Holder Delegate Record ;
|
||||
- Collection Authority Record et Use Authority Record ;
|
||||
- Token Owned Escrow ;
|
||||
- Reservation List historique.
|
||||
|
||||
Le modèle canonique porte déjà :
|
||||
|
||||
- identité et Program ID ;
|
||||
- provenance ;
|
||||
- lifecycle actif, expérimental ou historique ;
|
||||
- politique de matérialisation ;
|
||||
- politique d’exécution candidate ou interdite pour l’historique.
|
||||
|
||||
### 4.3 Matérialisation
|
||||
|
||||
Les fonctions existantes matérialisent déjà :
|
||||
|
||||
- les metadata incorporées Token-2022 sous le domaine distinct `spl_token_2022_embedded_metadata` ;
|
||||
- l’état Metadata Metaplex sous le domaine `metaplex_token_metadata` ;
|
||||
- les autres snapshots canoniques de comptes Metaplex ;
|
||||
- une surface de risque metadata dédiée existe mais reste à auditer pour sa couverture réelle.
|
||||
|
||||
L’audit de `0.4.7` doit produire une table de propriété unique par fait avant d’ajouter une projection.
|
||||
|
||||
### 4.4 Exécution
|
||||
|
||||
L’exécuteur `ExMetadataMetaplexTokenMetadataExecutor` existe mais est réservé :
|
||||
|
||||
- il reconnaît le Program ID ;
|
||||
- il retourne `Maybe` pour cette surface ;
|
||||
- il ne construit aucune instruction ;
|
||||
- il ne possède pas encore d’intents, de builders, de préflight ou de postconditions Metaplex.
|
||||
|
||||
### 4.5 Pipeline et applications
|
||||
|
||||
L’extraction Core, le replay générique, le stockage canonique et la matérialisation générique sont réutilisables.
|
||||
|
||||
Les manques Metaplex spécifiques sont :
|
||||
|
||||
- contrat de lecture stateful ;
|
||||
- corrélation mint/metadata/edition/token record/collection/authority/rule set ;
|
||||
- orchestration de préparation et d’exécution ;
|
||||
- postvalidation ;
|
||||
- diagnostics structurés ;
|
||||
- scénarios Devnet/Testnet et CLI ;
|
||||
- adaptateurs et panneaux desktop.
|
||||
|
||||
## 5. Liste fermée des manques réels
|
||||
|
||||
Le développement fonctionnel de `0.4.7` est limité aux éléments suivants.
|
||||
|
||||
### 5.1 Contrat de couverture
|
||||
|
||||
1. Résoudre chaque statut de matrice incomplet ou ancien.
|
||||
2. Attribuer à chaque instruction un statut exact :
|
||||
- `executable_current` ;
|
||||
- `decode_only_historical` ;
|
||||
- `decode_only_bridge_boundary` ;
|
||||
- `unsupported_with_reason` ;
|
||||
- `executable_deprecated` ;
|
||||
- `decode_only_replaced`.
|
||||
3. Attribuer à chaque instruction exécutable : builder officiel, comptes, signers, préconditions, confirmation et postconditions.
|
||||
4. Maintenir l’inventaire exhaustif `0..57`.
|
||||
|
||||
### 5.2 Matérialisation
|
||||
|
||||
1. Produire la table de propriété des faits.
|
||||
2. Vérifier la couverture de : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config.
|
||||
3. Vérifier la couverture de : update authority, collection authority, delegates et changements d’autorité.
|
||||
4. Vérifier la couverture lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées.
|
||||
5. Vérifier la couverture risk/compliance : royalties, créateurs non vérifiés, mutabilité, rule sets et délégations sensibles.
|
||||
6. Ajouter uniquement les faits absents et stables.
|
||||
7. Ajouter les tests de non-fusion avec Token-2022 metadata.
|
||||
|
||||
### 5.3 Exécuteur
|
||||
|
||||
1. Définir les intents typés.
|
||||
2. Définir les builders à partir de `mpl-token-metadata` officiel pour toute opération officiellement constructible, non obsolète et non remplacée.
|
||||
3. Vérifier l’ordre des comptes et les signers exacts.
|
||||
4. Calculer les coûts contrôlables et plafonds de dépense.
|
||||
5. Rendre la simulation obligatoire avant soumission.
|
||||
6. Définir les confirmations opérateur sensibles.
|
||||
7. Interdire explicitement l’exécution des variantes historiques, obsolètes ou remplacées lorsque leur reconstruction n’est plus légitime.
|
||||
8. Remplacer le support `Maybe` réservé par une décision déterministe fondée sur l’intent.
|
||||
9. Interdire tout `Unsupported(reason)` motivé seulement par une priorité, un report ou une opération non retenue.
|
||||
|
||||
### 5.4 Stateful, préflight et postconditions
|
||||
|
||||
1. Lire les comptes nécessaires avec bornes de taille et owner exact.
|
||||
2. Recalculer les PDA et seeds.
|
||||
3. Vérifier les relations mint, metadata, edition, token account, collection et authority.
|
||||
4. Vérifier mutabilité, vérification, délégation, token standard et programmable config.
|
||||
5. Vérifier les rule sets et comptes d’autorisation lorsqu’ils s’appliquent.
|
||||
6. Définir les cas `not_applicable` au lieu de masquer une absence de preuve.
|
||||
7. Relire l’état après confirmation et vérifier les postconditions opérationnelles.
|
||||
|
||||
### 5.5 Pipeline généraliste
|
||||
|
||||
`kb-pipeline` doit rester utilisable depuis toute application, service, worker, CLI ou test, sans hypothèse propre à Devnet/Testnet.
|
||||
|
||||
1. Ajouter les DTO et résultats Metaplex strictement nécessaires.
|
||||
2. Ajouter la corrélation stateful.
|
||||
3. Ajouter la préparation et l’orchestration d’exécution.
|
||||
4. Ajouter la postvalidation.
|
||||
5. Raccorder les observations au replay et à la matérialisation idempotente.
|
||||
6. Fournir des diagnostics stables pour scénarios et desktop.
|
||||
|
||||
### 5.6 Scénarios Devnet/Testnet et desktop
|
||||
|
||||
Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipeline-demo-scenarios` fournit en parallèle les fixtures, aides de campagne et tests automatisés capables de reproduire les mêmes parcours à partir des APIs généralistes de `kb-pipeline`.
|
||||
|
||||
1. Conserver et compléter dans le desktop les scénarios UI simulation-only par défaut.
|
||||
2. Ajouter dans `kb-pipeline-demo-scenarios`, lorsque cela apporte une preuve utile à `0.4.7`, des tests automatisés Metaplex équivalents aux parcours desktop ; cette pratique doit ensuite être généralisée pendant la série `0.5.x`.
|
||||
3. Ajouter les fixtures synthétiques et fixtures réseau disponibles.
|
||||
4. Produire des résultats structurés et preuves de postcondition communs ou comparables entre tests automatisés et démonstrations UI.
|
||||
5. N'étendre `kb-pipeline-demo-scenarios-cli` que lorsqu'une préparation de fixture exige réellement une commande dédiée ; ne pas en faire implicitement le lanceur général de tous les scénarios.
|
||||
6. Ajouter uniquement les commandes Tauri et panneaux nécessaires, tout en conservant dans le desktop les états et séquences propres à l'expérience UI.
|
||||
7. Maintenir les primitives et orchestrations généralistes hors du desktop, dans `kb-pipeline` ou la crate métier propriétaire.
|
||||
|
||||
## 6. Choix structurants
|
||||
|
||||
### 6.1 Granularité des intents
|
||||
|
||||
**Option A — un intent par instruction Metaplex**
|
||||
|
||||
- fidélité maximale au SDK ;
|
||||
- surface publique volumineuse ;
|
||||
- duplication probable entre instructions historiques et wrappers modernes.
|
||||
|
||||
**Option B — intents métier canoniques compilés vers une instruction actuelle**
|
||||
|
||||
- API plus stable ;
|
||||
- meilleure séparation entre intention et génération SDK ;
|
||||
- nécessite une table explicite de résolution et empêche de choisir arbitrairement une variante historique.
|
||||
|
||||
**Option C — intents hybrides**
|
||||
|
||||
- intents métier pour les opérations communes ;
|
||||
- intents spécialisés pour les opérations Metaplex sans équivalent métier simple ;
|
||||
- complexité intermédiaire.
|
||||
|
||||
**Recommandation : Option C.** Elle correspond à l’architecture d’exécution existante, limite l’exposition des détails historiques et conserve les opérations programmables spécifiques.
|
||||
|
||||
### 6.2 Périmètre exécutable initial
|
||||
|
||||
**Option A — toutes les instructions actuelles en une seule campagne**
|
||||
|
||||
- couverture maximale immédiate ;
|
||||
- risque élevé de validation superficielle et de prereleases trop larges.
|
||||
|
||||
**Option B — noyau sûr puis extensions par familles**
|
||||
|
||||
- commence par create/update et opérations administratives dont les contrats sont les plus directement vérifiables ;
|
||||
- ajoute ensuite collections, délégations, programmable NFT, éditions, uses et escrow ;
|
||||
- permet une validation stateful progressive.
|
||||
|
||||
**Option C — uniquement les wrappers modernes**
|
||||
|
||||
- surface plus petite ;
|
||||
- couverture insuffisante de plusieurs opérations actuelles sans wrapper moderne complet.
|
||||
|
||||
**Recommandation : Option B.** Aucune famille ne devient exécutable avant preuve complète de ses comptes, signers, préflight et postconditions.
|
||||
|
||||
### 6.3 Propriété des faits matérialisés
|
||||
|
||||
**Option A — un matérialiseur Metaplex monolithique**
|
||||
|
||||
- simple à appeler ;
|
||||
- mélange metadata, administration, lifecycle et risque.
|
||||
|
||||
**Option B — propriété par domaine fonctionnel existant**
|
||||
|
||||
- metadata possède les attributs descriptifs ;
|
||||
- admin possède autorités et délégations ;
|
||||
- lifecycle possède les transitions prouvées ;
|
||||
- risk/compliance possède uniquement les signaux dérivés ;
|
||||
- exige une table anti-duplication.
|
||||
|
||||
**Recommandation : Option B.** Elle respecte la règle de propriétaire unique et les frontières déjà utilisées par le workspace.
|
||||
|
||||
### 6.4 Rule sets programmables
|
||||
|
||||
**Option A — accepter un rule set opaque et transmettre les comptes fournis**
|
||||
|
||||
- mise en œuvre rapide ;
|
||||
- ne prouve pas l’autorisation et affaiblit le fail-closed.
|
||||
|
||||
**Option B — limiter l’envoi programmable aux rule sets et authorization data vérifiables**
|
||||
|
||||
- cohérent avec simulation-first et préflight strict ;
|
||||
- le builder universel reste présent lorsqu’il est officiellement constructible ; l’envoi peut rester interdit faute de preuve stateful suffisante.
|
||||
|
||||
**Recommandation : Option B.** Une opération programmable officiellement constructible conserve son builder, mais sa préparation ou son envoi échoue explicitement lorsque le rule set ou les données d’autorisation ne peuvent pas être vérifiés. Cette limite ne doit pas être confondue avec une absence d’implémentation de l’exécuteur.
|
||||
|
||||
### 6.5 Validation réseau
|
||||
|
||||
**Option A — exiger Devnet pour toute opération exécutable**
|
||||
|
||||
- preuve forte ;
|
||||
- peut bloquer les opérations nécessitant des actifs, autorités ou rule sets indisponibles.
|
||||
|
||||
**Option B — niveaux de preuve distincts**
|
||||
|
||||
- builder parity et tests synthétiques obligatoires ;
|
||||
- simulation réseau lorsque les comptes existent ;
|
||||
- envoi et postcondition uniquement avec fixture contrôlée ;
|
||||
- statut réseau exact consigné par opération.
|
||||
|
||||
**Recommandation : Option B.** La version peut clôturer avec certaines opérations validées synthétiquement seulement, à condition que ce statut soit explicite et que leur exécution publique soit limitée en conséquence.
|
||||
|
||||
## 7. Ordonnancement proposé par prerelease
|
||||
|
||||
La numérotation ci-dessous est un plan fermé initial. Elle peut être regroupée uniquement si deux lots restent cohérents et si le plan est mis à jour avant livraison.
|
||||
|
||||
### `0.4.7-pre.001` — planification et inventaire
|
||||
|
||||
**Travaux**
|
||||
|
||||
- audit de la base migrée ;
|
||||
- inventaire instructions, comptes, matérialisations, exécuteur, pipeline et applications ;
|
||||
- liste fermée des manques ;
|
||||
- options architecturales et recommandations ;
|
||||
- plan par prerelease.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- aucun code fonctionnel Metaplex ajouté ;
|
||||
- plan accepté avant `pre.002` ;
|
||||
- confirmation qu’aucune capacité existante ne sera réimplémentée sans écart prouvé.
|
||||
|
||||
### `0.4.7-pre.002` — contrat de couverture et propriété des faits
|
||||
|
||||
**Dépendance** : acceptation de `pre.001`.
|
||||
|
||||
**Travaux**
|
||||
|
||||
- corriger les statuts incomplets de la matrice ;
|
||||
- classer les 58 instructions ;
|
||||
- produire la table instruction → builder/comptes/signers/préflight/postconditions ;
|
||||
- produire la table fait → propriétaire unique ;
|
||||
- compléter uniquement les projections stables manquantes et leurs tests.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- matrice exhaustive et sans statut ambigu ;
|
||||
- aucune duplication silencieuse avec Token-2022 ;
|
||||
- tests de matérialisation et d’idempotence ciblés validés.
|
||||
|
||||
### `0.4.7-pre.003` — fondations de l’exécuteur et noyau metadata
|
||||
|
||||
**Dépendance** : matrice et propriété des faits stabilisées.
|
||||
|
||||
**Travaux**
|
||||
|
||||
- intents communs, enveloppe d’exécution et politiques de coût ;
|
||||
- builders des wrappers courants `Create` (42) et `Update` (50), sans reconstruire les anciennes instructions remplacées ;
|
||||
- signers, comptes, PDA et mutabilité ;
|
||||
- simulation obligatoire ;
|
||||
- postconditions de création et mise à jour.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- parity tests avec builders officiels ;
|
||||
- erreurs fail-closed avant signature ;
|
||||
- variantes historiques rejetées explicitement.
|
||||
|
||||
### `0.4.7-pre.004` — collections, créateurs et autorités — implémentée, validation locale requise
|
||||
|
||||
**Travaux**
|
||||
|
||||
- wrappers courants `Verify` et `Unverify` pour collections et créateurs ;
|
||||
- wrapper courant `Delegate`/`Revoke` pour les autorités de collection lorsque la variante correspondante est prouvée ;
|
||||
- aucune reconstruction de `SignMetadata`, des instructions sized collection historiques ni de `UpdatePrimarySaleHappenedViaToken` ;
|
||||
- confirmations opérateur et postconditions.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- autorités et records corrélés statefully ;
|
||||
- transitions de vérification prouvées ;
|
||||
- mauvais owners, PDA, authority et collection rejetés.
|
||||
|
||||
### `0.4.7-pre.005` — programmable NFTs et délégations — réalisée
|
||||
|
||||
**Travaux**
|
||||
|
||||
- delegate/revoke ;
|
||||
- transfer, burn, lock, unlock et close accounts officiellement constructibles ;
|
||||
- token records, programmable config, rule sets et authorization data ;
|
||||
- politique de confirmation renforcée.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- aucune transmission opaque de rule set non vérifié ;
|
||||
- simulation et postconditions par opération ;
|
||||
- builders présents pour toute opération officiellement constructible ; préparation ou envoi refusé avec une raison stable lorsque les préconditions stateful ne sont pas prouvables.
|
||||
|
||||
### `0.4.7-pre.006` — editions, use, escrow et opérations restantes — réalisée
|
||||
|
||||
**Travaux**
|
||||
|
||||
- master edition et printed edition actuelles ;
|
||||
- use authority et utilization ;
|
||||
- escrow et collect ;
|
||||
- create/mint/print/update/use/verify/unverify wrappers restants ;
|
||||
- resize/migrate et toute autre opération restante lorsque leurs contrats officiels permettent une construction exacte ;
|
||||
- classification définitive des instructions historiques et bridge.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- la surface `kb-lib` est fermée pour les 58 instructions : chaque opération officiellement constructible courante ou obsolète possède un intent et un builder ; seules les versions remplacées et la frontière Bubblegum restent sans builder ;
|
||||
- les opérations obsolètes encore officiellement constructibles sont exécutables sous `#[deprecated]` et approbation opérateur explicite ; les versions remplacées ne sont pas réexposées ;
|
||||
- aucun `Unsupported(reason)` ne masque une opération simplement non réalisée ou reportée ;
|
||||
- contrats d’edition marker et supply bornés ;
|
||||
- frontières Bubblegum explicites ;
|
||||
- `pre.007` ne doit normalement plus ajouter de builder Metaplex, sauf correction d’un écart démontré dans la matrice.
|
||||
|
||||
### `0.4.7-pre.007` — intégration au pipeline généraliste stateful
|
||||
|
||||
**Dépendance** : intents et familles exécutables stabilisés.
|
||||
|
||||
**Travaux**
|
||||
|
||||
- lectures stateful bornées ;
|
||||
- corrélation des comptes ;
|
||||
- préparation, simulation, confirmation, soumission et postvalidation ;
|
||||
- diagnostics structurés ;
|
||||
- replay et matérialisation idempotente.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- résultats déterministes et exploitables depuis toute application, service, worker, CLI ou test, sans dépendance aux scénarios de démonstration ;
|
||||
- tests de conflits Metaplex/Token-2022 ;
|
||||
- replay PostgreSQL idempotent.
|
||||
|
||||
### `0.4.7-pre.008` — fixtures et validations automatisées Devnet/Testnet
|
||||
|
||||
**Travaux**
|
||||
|
||||
- fixtures NFT, SFT, fungible, collection et pNFT ;
|
||||
- scénarios synthétiques de démonstration ;
|
||||
- aides de préparation des campagnes Devnet/Testnet ;
|
||||
- tests automatisés Metaplex reproduisant, lorsque pertinent pour `0.4.7`, les parcours destinés au desktop ;
|
||||
- simulation-only par défaut dans les tests et campagnes ;
|
||||
- extension ciblée du CLI uniquement si une fixture Metaplex ne peut pas être préparée proprement autrement ;
|
||||
- résultats et preuves de postcondition.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- couverture automatisée parallèle disponible pour les parcours Metaplex retenus, sans suppression ni migration des scénarios UI du desktop ;
|
||||
- tests et campagnes fondés exclusivement sur les APIs généralistes de `kb-pipeline` et les contrats métier propriétaires ;
|
||||
- aucune soumission réelle automatique sans garde-fou explicite adapté aux tests réseau ;
|
||||
- statuts de validation réseau exacts.
|
||||
|
||||
### `0.4.7-pre.009` — desktop
|
||||
|
||||
**Dépendance** : APIs généralistes et contrats de fixtures stabilisés.
|
||||
|
||||
**Travaux**
|
||||
|
||||
- conservation et achèvement des scénarios UI Devnet/Testnet dans le desktop ;
|
||||
- adaptateurs Tauri minces autour des APIs généralistes ;
|
||||
- panneaux nécessaires ;
|
||||
- affichage préflight, simulation, confirmation et postconditions ;
|
||||
- aucun déplacement de logique métier vers l’application.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- audits Tauri/frontend validés ;
|
||||
- fonctionnement manuel des parcours retenus ;
|
||||
- réouverture et état applicatif cohérents.
|
||||
|
||||
### `0.4.7-pre.010` — corpus et validations croisées — réalisée, validation locale requise
|
||||
|
||||
**Travaux**
|
||||
|
||||
- outer et CPI ;
|
||||
- succès et échec transactionnel ;
|
||||
- Program ID, owner, PDA, comptes, payload, suffixe et discriminant invalides ;
|
||||
- corpus NFT/SFT/fungible/collection/pNFT ;
|
||||
- simulations, envois disponibles et postconditions ;
|
||||
- rapports de validation.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- aucune validation réseau surdéclarée ;
|
||||
- matrice, tests, rapports et runtime alignés ;
|
||||
- écarts résiduels fermés ou reportés explicitement.
|
||||
|
||||
### `0.4.7-pre.011` — clôture
|
||||
|
||||
**Travaux**
|
||||
|
||||
- aucune nouvelle surface majeure ;
|
||||
- tests finaux et audits de conformité ;
|
||||
- documentation générale et des crates ;
|
||||
- nettoyage des TODO, outils temporaires et références obsolètes ;
|
||||
- archivage du présent plan et des rapports devenus historiques ;
|
||||
- prompt `0.4.8` avec prerelease initiale de planification et prerelease finale de clôture ;
|
||||
- livraison finale.
|
||||
|
||||
**Acceptation**
|
||||
|
||||
- commandes de validation finales réussies ;
|
||||
- code, matrices, registres, bindings et documentation alignés ;
|
||||
- archive finale conforme aux règles du workspace.
|
||||
|
||||
## 8. Dépendances et ordre critique
|
||||
|
||||
L’ordre critique est :
|
||||
|
||||
1. classification exhaustive ;
|
||||
2. propriété des faits ;
|
||||
3. intents et builders ;
|
||||
4. préflight et postconditions ;
|
||||
5. pipeline stateful ;
|
||||
6. fixtures et validations automatisées Devnet/Testnet ;
|
||||
7. scénarios UI desktop ;
|
||||
8. validation croisée ;
|
||||
9. clôture.
|
||||
|
||||
Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou l’envoi d’une opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce qu’un builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
|
||||
|
||||
## 9. Critères globaux d’acceptation
|
||||
|
||||
`0.4.7` est fonctionnellement achevée lorsque :
|
||||
|
||||
- les 58 instructions sont classées sans ambiguïté ;
|
||||
- les comptes pris en charge conservent owners, PDA, seeds, bornes et variantes historiques ;
|
||||
- les faits matérialisés ont un propriétaire unique ;
|
||||
- toutes les opérations officiellement constructibles, non obsolètes et non remplacées possèdent intents, builders et contrats exacts ; leurs signers, coûts, préflight, simulation, confirmation et postconditions sont appliqués dès qu’ils sont pertinents ;
|
||||
- les opérations historiques sont decode-only ;
|
||||
- le pipeline généraliste expose des résultats structurés et idempotents sans dépendance à un cluster de démonstration ;
|
||||
- les scénarios UI Devnet/Testnet restent disponibles dans le desktop ;
|
||||
- les parcours retenus disposent en parallèle d’une couverture automatisée dans `kb-pipeline-demo-scenarios` lorsque cette preuve est nécessaire à `0.4.7` ;
|
||||
- le desktop reste propriétaire de ses états et séquences UI, sans absorber les primitives généralistes ;
|
||||
- les conflits entre sources metadata restent explicites ;
|
||||
- le fetch off-chain est absent ;
|
||||
- chaque validation réseau est déclarée selon la preuve réellement obtenue.
|
||||
|
||||
## 10. Validations prévues
|
||||
|
||||
Pendant chaque prerelease :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
Les tests ciblés des crates modifiées sont obligatoires avant livraison du delta.
|
||||
|
||||
À la clôture :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Si le desktop est modifié :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
## 11. Décisions requises avant `pre.002`
|
||||
|
||||
Le développement fonctionnel peut commencer après acceptation des recommandations suivantes :
|
||||
|
||||
1. intents hybrides, métier lorsque possible et spécialisés lorsque nécessaire ;
|
||||
2. activation progressive par familles, avec fermeture exhaustive de toute la surface exécutable à la fin de `pre.006` ;
|
||||
3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
|
||||
4. rule sets programmables fail-closed ;
|
||||
5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
|
||||
6. séquence de prereleases `pre.002` à `pre.011` décrite ci-dessus.
|
||||
|
||||
|
||||
## État de `0.4.7-pre.007`
|
||||
|
||||
- lectures stateful bornées dans `kb-pipeline` ;
|
||||
- préflight généraliste lié aux plans `kb-lib` ;
|
||||
- orchestration simulation-first, résolution des signers et postconditions explicites ;
|
||||
- aucune dépendance vers `kb-pipeline-demo-scenarios` ;
|
||||
- les fixtures et campagnes réseau restent réservées à `pre.008`.
|
||||
|
||||
|
||||
## État de `0.4.7-pre.008`
|
||||
|
||||
- inventaire synthétique fermé pour NFT, SFT, fungible, collection et pNFT ;
|
||||
- matrice automatisée de validation Metaplex avec preuves bornées ;
|
||||
- aucune soumission automatique ;
|
||||
- CLI inchangé faute de besoin démontré pour une fixture Metaplex dédiée ;
|
||||
- scénarios UI du desktop conservés pour `pre.009`.
|
||||
|
||||
|
||||
## État de `0.4.7-pre.009`
|
||||
|
||||
- fenêtre desktop Metaplex dédiée ;
|
||||
- adaptateurs Tauri limités aux contrats de scénarios ;
|
||||
- affichage des exigences de préflight, simulation-first et postconditions ;
|
||||
- scénario sélectionné restauré à la réouverture ;
|
||||
- aucune logique métier dupliquée et aucune soumission automatique.
|
||||
@@ -0,0 +1,193 @@
|
||||
<!-- file: olddocs/archivekbot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata
|
||||
|
||||
## 1. Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture validée de `0.4.6` et achever la surface Metaplex Token Metadata partiellement développée dans bot2. Tout ce qui avait été réalisé dans bot2 a été migré dans bot3 ; la reprise doit donc partir de cette base migrée complète, sans présenter la migration comme partielle.
|
||||
|
||||
Le travail ne consiste pas à recommencer le décodeur ni les matérialisations déjà présentes. Il doit partir de l’état réel du code, établir un plan de travail fermé, puis compléter l’exécuteur, les contrats stateful, le pipeline, les scénarios réutilisables, le CLI, le desktop et les validations finales.
|
||||
|
||||
Program ID canonique :
|
||||
|
||||
```text
|
||||
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s
|
||||
```
|
||||
|
||||
## 2. Base validée `0.4.6`
|
||||
|
||||
La base comprend :
|
||||
|
||||
- architecture bot3 consolidée en onze crates ;
|
||||
- Solana Core, SPL Memo, SPL Token classique, ATA et Token-2022 ;
|
||||
- transports HTTP/WebSocket, stockage PostgreSQL, extraction Core et replay ;
|
||||
- exécution simulation-first, confirmations, signers et postvalidation ;
|
||||
- décodeur Metaplex Token Metadata d’instructions ;
|
||||
- décodeur des comptes Metaplex avec owners, PDA, seeds, bornes et variantes historiques ;
|
||||
- matrice `test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_MATRIX.json` ;
|
||||
- matérialisation metadata déjà substantielle ;
|
||||
- coexistence explicite avec les metadata incorporées de Token-2022 ;
|
||||
- workspace, matrices, registres et bindings TS-RS validés.
|
||||
|
||||
Exception conservée : le registre ElGamal n’est pas déclaré validé réellement sur réseau. Cette exception ne doit pas être mêlée au jalon Metaplex.
|
||||
|
||||
## 3. Lectures obligatoires
|
||||
|
||||
1. `RULES.md`, `README.md`, `ROADMAP.md`, `CHANGELOG.md` et ce prompt ;
|
||||
2. `kb-lib/README.md`, `kb-lib/USAGE.md`, `kb-lib/TODO.md` ;
|
||||
3. `kb-pipeline/README.md`, `kb-pipeline-demo-scenarios/README.md` et `kb-app-demo-desktop/README.md` ;
|
||||
4. la matrice Metaplex active et les tests existants ;
|
||||
5. l’IDL archivée `idls/metadata.metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metaplex_token_metadata.V1_14_0.from_github_mpl-token-metadata.json` ;
|
||||
6. le prompt historique `olddocs/archivekbot2/prompts/026_v0_4_7_metaplex_token_metadata.md`, uniquement comme source historique à confronter au code bot3 actuel.
|
||||
|
||||
## 4. Première prerelease — plan de travail et brainstorming
|
||||
|
||||
La première prerelease de `0.4.7` est consacrée exclusivement à la préparation du développement. Elle ne doit pas introduire l’exécuteur, le pipeline Metaplex ou les démonstrations finales.
|
||||
|
||||
Elle doit :
|
||||
|
||||
- relire le code, les matrices, les tests, les documents actifs et les sources officielles retenues ;
|
||||
- inventorier les instructions et comptes déjà décodés ;
|
||||
- inventorier les projections metadata, admin, lifecycle et risk/compliance déjà présentes ;
|
||||
- identifier les opérations actuelles, historiques decode-only et non supportées ;
|
||||
- distinguer les travaux certains, les choix d’architecture et les questions encore ouvertes ;
|
||||
- proposer plusieurs options lorsque des choix structurants existent ;
|
||||
- produire un plan de travail ordonné par prerelease, avec dépendances, critères d’acceptation et validations prévues ;
|
||||
- établir une liste fermée des manques réels ;
|
||||
- confirmer explicitement qu’aucune capacité déjà couverte ne sera réimplémentée.
|
||||
|
||||
Cette première prerelease doit aboutir à un plan accepté avant le commencement du développement fonctionnel.
|
||||
|
||||
## 5. Frontière fonctionnelle
|
||||
|
||||
Metaplex Token Metadata reste distinct de :
|
||||
|
||||
- metadata incorporées de Token-2022 ;
|
||||
- SPL Token Metadata, prévu en `0.4.8` ;
|
||||
- Metaplex Core ;
|
||||
- JSON off-chain référencé par URI.
|
||||
|
||||
Le fetch HTTP/IPFS/Arweave et la création éventuelle de `kb-offchain-transport` sont hors périmètre de `0.4.7`. Cette décision sera étudiée en `0.4.8` avec SPL Token Metadata.
|
||||
|
||||
## 6. Matérialisation
|
||||
|
||||
Auditer les projections existantes et compléter uniquement les faits stables manquants :
|
||||
|
||||
- metadata : nom, symbole, URI, seller fee, créateurs, collection, uses, token standard, mutabilité et programmable config ;
|
||||
- admin : update authority, collection authority, delegates et changements d’autorité ;
|
||||
- lifecycle : création, mise à jour, vérification, édition, burn, lock/unlock et transitions prouvées ;
|
||||
- risk/compliance : royalties, mutabilité, créateurs non vérifiés, rule sets et délégations sensibles.
|
||||
|
||||
Chaque fait doit avoir un propriétaire unique. Ne jamais fusionner silencieusement metadata Metaplex et metadata Token-2022.
|
||||
|
||||
## 7. Exécution
|
||||
|
||||
Implémenter dans `kb-lib` :
|
||||
|
||||
- intents typés ;
|
||||
- builders validés contre les interfaces officielles ;
|
||||
- liste exacte des signers et comptes ;
|
||||
- coûts et plafonds de dépense ;
|
||||
- dry-run par défaut et simulation obligatoire ;
|
||||
- confirmation opérateur dédiée pour burn, changement d’autorité, verify/unverify, delegate/revoke, lock/unlock ;
|
||||
- classification explicite des opérations historiques decode-only.
|
||||
|
||||
## 8. Préflight et postconditions
|
||||
|
||||
Vérifier selon l’opération :
|
||||
|
||||
- owner et Program ID ;
|
||||
- PDA et seeds ;
|
||||
- mint, metadata, edition, token account, collection et authority ;
|
||||
- état de mutabilité, vérification, délégation, token standard et programmable config ;
|
||||
- cohérence des rule sets et comptes d’autorisation ;
|
||||
- postconditions stateful après soumission.
|
||||
|
||||
Tout écart doit échouer avant signature ou être classé explicitement non applicable.
|
||||
|
||||
## 9. Pipeline
|
||||
|
||||
Intégrer dans `kb-pipeline` :
|
||||
|
||||
- lectures stateful bornées ;
|
||||
- préparation et orchestration d’exécution ;
|
||||
- corrélation des comptes Metaplex ;
|
||||
- postvalidation ;
|
||||
- insertion canonique, extraction Core, replay et matérialisation idempotente ;
|
||||
- diagnostics stables et résultats exploitables par les scénarios.
|
||||
|
||||
## 10. Scénarios et démonstrations
|
||||
|
||||
Ajouter dans `kb-pipeline-demo-scenarios` :
|
||||
|
||||
- scénarios simulation-only par défaut ;
|
||||
- CLI pour les opérations retenues ;
|
||||
- fixtures synthétiques et, si possible, réseau ;
|
||||
- résultats structurés et preuves de postcondition.
|
||||
|
||||
Ajouter dans `kb-app-demo-desktop` uniquement les adaptateurs Tauri et panneaux nécessaires. La logique fonctionnelle doit rester dans les crates réutilisables.
|
||||
|
||||
## 11. Corpus et validations
|
||||
|
||||
Couvrir au minimum :
|
||||
|
||||
- NFT, SFT, token fongible, collection et programmable NFT ;
|
||||
- outer et CPI ;
|
||||
- transactions réussies et échouées ;
|
||||
- mauvais Program ID, owner, PDA, comptes, payload tronqué, suffixe et discriminant inconnu ;
|
||||
- conflits entre metadata Metaplex et metadata Token-2022 ;
|
||||
- replay PostgreSQL idempotent ;
|
||||
- simulation, confirmation, envoi et postconditions pour les opérations exécutables.
|
||||
|
||||
Ne pas déclarer une validation réseau si les fixtures ou préconditions ne sont pas disponibles.
|
||||
|
||||
## 12. Documentation pendant le développement
|
||||
|
||||
Mettre à jour au fil des prereleases uniquement les documents nécessaires pour refléter les décisions et contrats réellement introduits :
|
||||
|
||||
- les quatre documents des crates modifiées ;
|
||||
- la matrice Metaplex active ;
|
||||
- la documentation des opérations supportées, decode-only et non supportées ;
|
||||
- les rapports de validation propres aux capacités effectivement testées.
|
||||
|
||||
La mise à jour générale de clôture appartient à la dernière prerelease.
|
||||
|
||||
## 13. Dernière prerelease — clôture de `0.4.7`
|
||||
|
||||
La dernière prerelease doit être réservée à la clôture de la version. Elle ne doit pas introduire une nouvelle surface fonctionnelle majeure.
|
||||
|
||||
Elle doit obligatoirement :
|
||||
|
||||
- exécuter les tests finaux, les audits de conformité et les validations applicatives nécessaires ;
|
||||
- vérifier l’alignement entre code, matrices, registres, bindings TS-RS et documentation ;
|
||||
- mettre à jour définitivement `README.md`, `ROADMAP.md` et `CHANGELOG.md` ;
|
||||
- mettre à jour les `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` des crates concernées ;
|
||||
- retirer des TODO les tâches terminées et transférer les travaux reportés vers la version correcte ;
|
||||
- archiver les prompts, plans, rapports ou documents de travail devenus historiques ;
|
||||
- supprimer les outils temporaires, fichiers de validation et références obsolètes qui ne doivent pas rester dans la version publiée ;
|
||||
- préparer le prompt complet de la session `0.4.8 — SPL Token Metadata et décision off-chain metadata` ;
|
||||
- vérifier que ce prompt commence lui aussi par une prerelease de planification et se termine par une prerelease de clôture ;
|
||||
- préparer la livraison finale de `0.4.7` selon les règles du workspace.
|
||||
|
||||
## 14. Validation finale
|
||||
|
||||
Exécuter :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Si le desktop est modifié, valider avec :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
## 15. Livraisons
|
||||
|
||||
Après l’archive complète de départ, livrer uniquement des ZIP delta contenant `delta.md`, sans SHA-256. Les correctifs d’une même prerelease utilisent `-delta-fix-XXX.zip`, avec une numérotation recommençant à `fix-001` pour chaque nouvelle prerelease.
|
||||
@@ -0,0 +1,487 @@
|
||||
{
|
||||
"matrixVersion": 1,
|
||||
"milestone": "0.4.7-pre.011",
|
||||
"programId": "metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s",
|
||||
"operations": [
|
||||
{
|
||||
"discriminator": 38,
|
||||
"name": "CreateEscrowAccount",
|
||||
"operationCode": "metadata.metaplex_token_metadata.create_escrow_account",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 39,
|
||||
"name": "CloseEscrowAccount",
|
||||
"operationCode": "metadata.metaplex_token_metadata.close_escrow_account",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 40,
|
||||
"name": "TransferOutOfEscrow",
|
||||
"operationCode": "metadata.metaplex_token_metadata.transfer_out_of_escrow",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 41,
|
||||
"name": "Burn",
|
||||
"operationCode": "metadata.metaplex_token_metadata.burn",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 42,
|
||||
"name": "Create",
|
||||
"operationCode": "metadata.metaplex_token_metadata.create",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.011",
|
||||
"runnerStatus": "implemented",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 43,
|
||||
"name": "Mint",
|
||||
"operationCode": "metadata.metaplex_token_metadata.mint",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 44,
|
||||
"name": "Delegate",
|
||||
"operationCode": "metadata.metaplex_token_metadata.delegate",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 45,
|
||||
"name": "Revoke",
|
||||
"operationCode": "metadata.metaplex_token_metadata.revoke",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 46,
|
||||
"name": "Lock",
|
||||
"operationCode": "metadata.metaplex_token_metadata.lock",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 47,
|
||||
"name": "Unlock",
|
||||
"operationCode": "metadata.metaplex_token_metadata.unlock",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 48,
|
||||
"name": "Migrate",
|
||||
"operationCode": "metadata.metaplex_token_metadata.migrate",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 49,
|
||||
"name": "Transfer",
|
||||
"operationCode": "metadata.metaplex_token_metadata.transfer",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 50,
|
||||
"name": "Update",
|
||||
"operationCode": "metadata.metaplex_token_metadata.update",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.011",
|
||||
"runnerStatus": "implemented",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 51,
|
||||
"name": "Use",
|
||||
"operationCode": "metadata.metaplex_token_metadata.use",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 52,
|
||||
"name": "Verify",
|
||||
"operationCode": "metadata.metaplex_token_metadata.verify",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.011",
|
||||
"runnerStatus": "implemented",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 53,
|
||||
"name": "Unverify",
|
||||
"operationCode": "metadata.metaplex_token_metadata.unverify",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.011",
|
||||
"runnerStatus": "implemented",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 54,
|
||||
"name": "Collect",
|
||||
"operationCode": "metadata.metaplex_token_metadata.collect",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 55,
|
||||
"name": "Print",
|
||||
"operationCode": "metadata.metaplex_token_metadata.print",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 56,
|
||||
"name": "Resize",
|
||||
"operationCode": "metadata.metaplex_token_metadata.resize",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
},
|
||||
{
|
||||
"discriminator": 57,
|
||||
"name": "CloseAccounts",
|
||||
"operationCode": "metadata.metaplex_token_metadata.close_accounts",
|
||||
"deprecated": false,
|
||||
"campaignPrerelease": "0.4.7-pre.012",
|
||||
"runnerStatus": "planned",
|
||||
"networkStatus": "not_run",
|
||||
"requiredEvidence": [
|
||||
"cluster",
|
||||
"genesis_hash",
|
||||
"simulation_slot",
|
||||
"simulation_logs",
|
||||
"message_hash",
|
||||
"fee_lamports"
|
||||
],
|
||||
"submissionEvidence": [
|
||||
"signature",
|
||||
"confirmation_status",
|
||||
"confirmation_slot",
|
||||
"before_state",
|
||||
"after_state"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user