khadhroony-bot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md

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 :

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 :

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 :

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.