v0.4.7-pre.016
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/DEVNET_EXECUTION_GUIDE.md -->
|
||||
<!-- version: 22 -->
|
||||
<!-- version: 23 -->
|
||||
|
||||
# Guide d’exécution Devnet
|
||||
|
||||
@@ -100,7 +100,7 @@ Arrêter avec `Ctrl+C`, puis relancer `T01`.
|
||||
### C01 — Initialiser l’environnement de validation
|
||||
|
||||
```bash
|
||||
cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/pre.062-clean" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet : %s\n' "$KB_DEVNET_WALLET";
|
||||
cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/current" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet : %s\n' "$KB_DEVNET_WALLET";
|
||||
```
|
||||
|
||||
### C02 — Capturer les versions CLI
|
||||
@@ -109,7 +109,7 @@ cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="lo
|
||||
command -v solana && command -v solana-keygen && command -v spl-token && { date --iso-8601=seconds; solana --version; solana-keygen --version; spl-token --version; } | tee "$KB_DEVNET_VALIDATION_DIR/00-cli-versions.txt";
|
||||
```
|
||||
|
||||
La première campagne `pre.062` utilisait `solana-cli 4.0.2`, `solana-keygen 4.0.2` et `spl-token-cli 5.5.0`. Une nouvelle campagne doit capturer ses propres versions.
|
||||
Chaque campagne doit capturer les versions exactes des outils externes qu’elle utilise. Les fixtures Rust natives ne doivent pas dépendre implicitement de la configuration globale d’une CLI.
|
||||
|
||||
### C03 — Vérifier l’identité du réseau
|
||||
|
||||
@@ -758,7 +758,7 @@ puis `50b`, `50c`, etc., avant chaque appel à `C07`.
|
||||
|
||||
## 11. Scénario S06 — Registre ElGamal — reporté
|
||||
|
||||
### Statut de `0.1.0-pre.062`
|
||||
### Statut de la campagne de référence historique
|
||||
|
||||
Le registre ElGamal reste implémenté mais **non validé sur Devnet** dans cette campagne. Ce report ne remet pas en cause les validations S01 à S05.
|
||||
|
||||
|
||||
@@ -1,94 +1,45 @@
|
||||
<!-- file: docs/IDEA_REMINDERS.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Rappels d’idées
|
||||
|
||||
Ce document regroupe les améliorations utiles mais non bloquantes pour la clôture de la migration et pour la reprise du développement fonctionnel.
|
||||
Ce document conserve les idées utiles qui ne constituent pas encore des engagements de version. Les orientations déjà intégrées au ROADMAP ne sont pas répétées comme propositions ouvertes.
|
||||
|
||||
## Application desktop
|
||||
|
||||
- Ajouter une autocomplétion Token lorsque des tables de référence fiables existeront.
|
||||
- Ajouter une autocomplétion Pool lorsque des tables de référence fiables existeront.
|
||||
- Introduire une pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs.
|
||||
- Étudier une résolution configurable du chemin de base utilisé par `kb-store`.
|
||||
- Séparer à terme la configuration du logging dans un fichier JSON dédié avec son propre schéma et ses propres profils de logging.
|
||||
- Permettre de sélectionner et changer un profil de logging indépendamment du profil applicatif actif, afin que les fenêtres Devnet puissent écrire dans des routes ou fichiers distincts sans changer le profil général de l’application.
|
||||
- autocomplétion Token et Pool lorsque des tables de référence fiables existeront ;
|
||||
- pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs ;
|
||||
- résolution configurable du chemin de base de `kb-store` ;
|
||||
- sélection indépendante du profil de logging ;
|
||||
- protection systématique contre les doubles déclenchements des actions réseau ;
|
||||
- affichage explicite des preuves de matérialisation après confirmation.
|
||||
|
||||
## Pipeline et PostgreSQL
|
||||
|
||||
- Dimensionner dynamiquement la concurrence Decode replay en fonction du pool PostgreSQL disponible.
|
||||
- Ajouter un retry borné et observable pour les erreurs transitoires de pool PostgreSQL.
|
||||
- Conserver dans les résumés des compteurs distincts pour les échecs fonctionnels, les erreurs de traitement ou de stockage, les entrées récupérées après retry et les échecs finaux.
|
||||
- Étudier une persistance dédiée des erreurs transitoires qui surviennent avant qu’une ligne de ledger puisse être écrite.
|
||||
- dimensionnement dynamique de la concurrence Decode replay selon le pool ;
|
||||
- retry borné et observable des erreurs transitoires ;
|
||||
- compteurs séparés pour erreurs fonctionnelles, traitement, stockage, reprises et échecs finaux ;
|
||||
- persistance éventuelle des erreurs survenant avant l’écriture du ledger.
|
||||
|
||||
## Metadata et validation réseau
|
||||
|
||||
- compléter ultérieurement les validations Devnet spécialisées Metaplex Token Metadata : Print, Burn, collections avancées, pNFT delegate/lock/unlock/revoke/transfer et rule sets ;
|
||||
- maintenir une distinction stricte entre validation synthétique, simulation RPC et soumission confirmée ;
|
||||
- prévoir les scénarios Devnet desktop dès la planification de chaque nouvelle surface, pas après l’implémentation ;
|
||||
- étudier `kb-offchain-transport` sans coupler le fetch distant au replay canonique.
|
||||
|
||||
## Documentation et outils
|
||||
|
||||
- Refaire les scripts Python d’audit après stabilisation définitive de la structure, des targets et de la nomenclature.
|
||||
- Maintenir un inventaire des IDL actives avec leur source, leur version ou commit, leur Program ID et les surfaces qui les utilisent.
|
||||
- refaire les scripts Python d’audit après stabilisation définitive de la nomenclature ;
|
||||
- maintenir un inventaire des IDL avec source, version/commit, Program ID et surfaces utilisatrices ;
|
||||
- rescanner les archives bot2 et bobobot avant de déclarer le registre Program IDs complet.
|
||||
|
||||
## Transport off-chain des metadata
|
||||
## Workers et applications
|
||||
|
||||
- Évaluer une crate `kb-offchain-transport` générale après le pipeline metadata : fetch HTTP(S)/IPFS/Arweave, prix SOL/USD-EUR-CHF, APIs Jupiter et autres fournisseurs non Solana RPC.
|
||||
- Décider séparément si cette crate accepte uniquement des lectures ou aussi des opérations off-chain authentifiées/mutables, avec contrats de sécurité distincts.
|
||||
- Borner tailles, types MIME, redirections, délais et schémas HTTP(S)/IPFS/Arweave.
|
||||
- Ne pas coupler le fetch off-chain au décodage déterministe ni au replay canonique on-chain.
|
||||
L’orientation W1/W2, rattrapage historique, application de contrôle et applications consommatrices est désormais intégrée au ROADMAP. Les points encore ouverts sont :
|
||||
|
||||
## Registre Program IDs, IDL et surfaces implémentées
|
||||
|
||||
- Analyser `olddocs/archivekbobobot/docs/SOLSCAN_ACCOUNT_SOURCE_MATRIX.md` et les documents équivalents de bot2.
|
||||
- Construire un registre croisé contenant au minimum Program ID, protocole, source vérifiée, présence d’IDL, provenance de l’IDL et chemin local.
|
||||
- Comparer ce registre avec les constantes de `kb-program-ids`.
|
||||
- Comparer chaque entrée avec les décodeurs, exécuteurs et matérialisateurs réellement présents dans `kb-lib`.
|
||||
- Distinguer les IDL provenant de Solscan, Solana Explorer, dépôts Git officiels ou autres sources vérifiées.
|
||||
- Ne pas déclarer l’inventaire complet avant le rescan des archives bot2 et bobobot.
|
||||
|
||||
## Architecture future des workers et applications
|
||||
|
||||
Cette proposition doit être étudiée avant intégration au ROADMAP définitif.
|
||||
|
||||
### Worker W1 — acquisition temps réel
|
||||
|
||||
- Binaire long-running utilisant `kb-onchain-transport`.
|
||||
- Écoute configurable de Program IDs, logs, comptes ou autres filtres.
|
||||
- Support progressif WebSocket, gRPC et recours HTTP/RPC lorsque nécessaire.
|
||||
- Écriture des signatures et transactions raw dans `kb-store`.
|
||||
- Modification à chaud des abonnements.
|
||||
- Notification fiable de l’arrivée de nouvelles données raw.
|
||||
- Arrêt uniquement sur demande explicite ou erreur fatale contrôlée.
|
||||
|
||||
### Worker W2 — décodage et matérialisation temps réel
|
||||
|
||||
- Binaire recevant ou détectant les notifications de nouveaux raw.
|
||||
- Exécution des décodeurs et matérialisateurs activés.
|
||||
- Configuration à chaud des surfaces actives.
|
||||
- Notification après décodage et matérialisation.
|
||||
- Traitement uniquement des données reçues pendant son activité ; aucun rattrapage implicite des périodes d’arrêt.
|
||||
|
||||
### Application de rattrapage historique
|
||||
|
||||
- Application ou binaire séparé, éventuellement Tauri.
|
||||
- Réutilisation des capacités Core extraction, decode replay et matérialisation.
|
||||
- Traitement des raw non pris en charge en temps réel par W2.
|
||||
- Coordination explicite pour éviter la concurrence ou la double prise en charge avec W2.
|
||||
- Backfill ciblé pour combler des périodes manquantes.
|
||||
- Décodage et matérialisation configurables comme dans W2.
|
||||
|
||||
### Pilotage W1/W2
|
||||
|
||||
- Application de contrôle permettant de modifier à chaud les filtres d’acquisition, décodeurs et matérialisateurs.
|
||||
- Diagnostics, état des workers, files d’attente, erreurs et métriques.
|
||||
- Contrats d’administration séparés des contrats de données.
|
||||
|
||||
### Applications consommatrices
|
||||
|
||||
- Application de trading consommant les événements temps réel de W2 et l’historique de `kb-store`.
|
||||
- Filtrage d’événements tels que nouveaux tokens, nouvelles paires, prix, migrations launchpad vers AMM, burns et changements de liquidité.
|
||||
- Construction d’historiques et OHLC depuis les matérialisations stockées.
|
||||
- Application non trading utilisant la même combinaison temps réel et historique pour visualiser les autres matérialisations.
|
||||
|
||||
### Principe de déploiement progressif
|
||||
|
||||
- W1 doit pouvoir continuer à acquérir les raw pendant le développement de nouveaux décodeurs.
|
||||
- W2 et les applications peuvent être redémarrés pour charger de nouvelles surfaces.
|
||||
- Le rattrapage historique doit traiter les périodes non couvertes sans perturber le flux temps réel.
|
||||
- Les frontières de notification, ownership de traitement, idempotence et reprise doivent être définies avant implémentation.
|
||||
- mécanisme de notification fiable entre acquisition, stockage et décodage ;
|
||||
- ownership et idempotence entre W2 et le rattrapage historique ;
|
||||
- configuration à chaud et reprise après erreur ;
|
||||
- métriques, files d’attente et contrats d’administration ;
|
||||
- frontière entre événements temps réel et historiques OHLC.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/README.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# Documentation active de Khadhroony Bot3
|
||||
|
||||
@@ -43,19 +43,16 @@ Modèles documentaires non génératifs :
|
||||
|
||||
Ces audits seront archivés sous `olddocs/archivekbot3/` lorsqu’ils auront été remplacés par des documents normatifs ou des rapports de clôture.
|
||||
|
||||
## 5. Documents techniques actifs à reclasser
|
||||
## 5. Documents techniques actifs
|
||||
|
||||
Les documents suivants restent actifs mais seront reclassés progressivement après correction de leurs références :
|
||||
- [`DEVNET_EXECUTION_GUIDE.md`](DEVNET_EXECUTION_GUIDE.md) ;
|
||||
- [`IDL_AUDIT.md`](IDL_AUDIT.md) ;
|
||||
- [`IDL_TO_KB_LIB_NOMENCLATURE.md`](IDL_TO_KB_LIB_NOMENCLATURE.md) ;
|
||||
- [`MISSING_PROGRAM_IDLS.md`](MISSING_PROGRAM_IDLS.md) ;
|
||||
- [`OPERATION_NAMING_CONVENTION.md`](OPERATION_NAMING_CONVENTION.md) ;
|
||||
- [`IDEA_REMINDERS.md`](IDEA_REMINDERS.md).
|
||||
|
||||
- `DEVNET_EXECUTION_GUIDE.md` ;
|
||||
- `PRE_062_DEVNET_VALIDATION_REPORT.md` ;
|
||||
- `IDL_AUDIT.md` ;
|
||||
- `IDL_TO_KB_LIB_NOMENCLATURE.md` ;
|
||||
- `MISSING_PROGRAM_IDLS.md` ;
|
||||
- `OPERATION_NAMING_CONVENTION.md` ;
|
||||
- `IDEA_REMINDERS.md`.
|
||||
|
||||
Les idées de `IDEA_REMINDERS.md` ne doivent rejoindre un `TODO.md` de crate qu’après confirmation, attribution et reformulation en tâche vérifiable.
|
||||
Les idées ne rejoignent un `TODO.md` qu’après confirmation, attribution et reformulation en tâche vérifiable.
|
||||
|
||||
## 6. Matrices contractuelles
|
||||
|
||||
@@ -91,10 +88,10 @@ Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHA
|
||||
- [Extraction Core, replay et matérialisation](guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md)
|
||||
- [PostgreSQL et stockage](guides/POSTGRES_STORAGE.md)
|
||||
- [Validation Devnet](guides/DEVNET_VALIDATION.md)
|
||||
- [`validation/PRE_062_DEVNET_VALIDATION_REPORT.md`](validation/PRE_062_DEVNET_VALIDATION_REPORT.md) ;
|
||||
- [Validation Metaplex Token Metadata 0.4.7](validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md)
|
||||
- [`validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md`](validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md) ;
|
||||
- [`validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md`](validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md) ;
|
||||
|
||||
## Prompt de reprise
|
||||
|
||||
- [`0.4.7 — achèvement de Metaplex Token Metadata`](../prompts/027_v0_4_7_metaplex_token_metadata_completion.md).
|
||||
- [`Prompt actif 0.4.8`](../prompts/028_v0_4_8_spl_token_metadata_and_offchain_decision.md).
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/guides/DEVNET_VALIDATION.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Guide de validation Devnet
|
||||
|
||||
@@ -59,14 +59,14 @@ Le registre ElGamal ne doit pas être déclaré validé sur Devnet ou Mainnet sa
|
||||
|
||||
## Références
|
||||
|
||||
- `docs/PRE_062_DEVNET_VALIDATION_REPORT.md` ;
|
||||
- `docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md` ;
|
||||
- `docs/DEVNET_EXECUTION_GUIDE.md` ;
|
||||
- `kb-pipeline-demo-scenarios/USAGE.md` ;
|
||||
- `kb-app-demo-desktop/USAGE.md`.
|
||||
|
||||
## Metaplex Token Metadata
|
||||
|
||||
Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Une fixture `Create` prépare le mint et dérive les PDA canoniques.
|
||||
Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Chaque parcours prépare sa fixture et dérive automatiquement les PDA et comptes de postcondition nécessaires à l’étape courante.
|
||||
|
||||
Une liste de profils vide est une erreur de configuration ou de raccordement et doit être signalée explicitement. Une validation réseau exige une simulation RPC réelle ; une soumission exige en plus confirmation opérateur, signature, confirmation et postconditions observées.
|
||||
|
||||
|
||||
@@ -1,680 +0,0 @@
|
||||
<!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
|
||||
<!-- version: 14 -->
|
||||
|
||||
# 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.
|
||||
|
||||
**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
|
||||
|
||||
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` — 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**
|
||||
|
||||
- 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 ;
|
||||
- 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 ;
|
||||
- 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
|
||||
|
||||
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. 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é.
|
||||
|
||||
## 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.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
|
||||
|
||||
|
||||
## É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.
|
||||
|
||||
|
||||
## É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.
|
||||
|
||||
## État de `0.4.7-pre.012`
|
||||
|
||||
- le runner RPC réutilisable accepte les 20 opérations `executable_current` ;
|
||||
- la matrice ne contient plus aucune opération au statut `planned` ;
|
||||
- un test opt-in permet de fournir l’intent typé et les lectures stateful par JSON ;
|
||||
- les statuts réseau restent `not_run` jusqu’aux campagnes locales avec fixtures ;
|
||||
- la préparation des fixtures et la collecte des preuves observées restent obligatoires avant `pre.013`.
|
||||
@@ -1,82 +0,0 @@
|
||||
<!-- file: docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Rapport de validation Devnet — `0.1.0-pre.062`
|
||||
|
||||
## Portée
|
||||
|
||||
Ce rapport clôt la campagne Devnet exécutée sur une base PostgreSQL propre, sans réinitialisation entre les scénarios.
|
||||
|
||||
- profil : `local_devnet` ;
|
||||
- RPC : `https://api.devnet.solana.com` ;
|
||||
- genesis hash : `EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG` ;
|
||||
- wallet opérateur : `J12WA6c42oqpWkLu1dFa4pCegkQJPpxabwc3RRCMSUuH` ;
|
||||
- preuves locales : `/tmp/devnet-validation/pre.062-clean` ;
|
||||
- CLI observées : `solana-cli 4.0.2`, `solana-keygen 4.0.2`, `spl-token-cli 5.5.0` ;
|
||||
- PostgreSQL : 13 tables sur 13 disponibles.
|
||||
|
||||
## Scénarios validés
|
||||
|
||||
| Code | Surface | Opération | Signature | Slot | Statut |
|
||||
|-------|---------------------|------------------|--------------------------------------------------------------------------------------------|------------:|----------|
|
||||
| S01 | Solana Core | System Transfer | preuve locale de campagne | — | validé |
|
||||
| S02 | SPL Memo v4 | Memo v4 | `3LJN8URRqvCJcjKMEpHmdVcJXsQHFMDc5cUiSCE4MkCsieqtPDXB39ReyzZ3oGh9WGTTaVT4ew5NPju8AWCzsUAk` | `479794063` | finalisé |
|
||||
| S03A | ATA classique | CreateIdempotent | `5ugba9K7NHN8vUsDnxhBGM37n3UsBsaX56B1ccrH3j64BbSgYcrxT1fsV5Z98waeyquYyxi46w4AENgrdhPucedn` | `479803680` | finalisé |
|
||||
| S03B | ATA Token-2022 | CreateIdempotent | `4Cv8p6bB2iqc1qRJDxhVgjGtriPx1Ji3F7AirqXPRUmCLVLCDhtQPLTipWgigGVSDTLSsrvz3mZtnNPe5GQwuUWG` | `479805232` | finalisé |
|
||||
| S04 | SPL Token classique | TransferChecked | `4ghND4BHUxVhCgRfKbZgtLHKV1f3VrF3XVXqSjCawT4dX2qEAHsRTKsDvHod9xKeNQE7HrHCZmPY4D9e8XENY7XT` | `479828478` | finalisé |
|
||||
| S05.1 | Token-2022 | MintToChecked | `3hdeszJNUdopzVNiBUSXLb7GYbuRJgQjVmXo9Rc6UUguWcuS3DcxeDGaVTxCsuuTA2uM5f6cKbJRkmYobU2FdkPX` | `479925764` | finalisé |
|
||||
| S05.2 | Token-2022 | TransferChecked | `5nx6eGR44AexrgSutBo8CvrpdDVCwgA3YcPrXomnBwPpKqBB3WcbZuNxy8H6AryKj3d4dF5kszKsvUYGx5qSzNPY` | `479926573` | finalisé |
|
||||
| S05.3 | Token-2022 | ApproveChecked | `2QLSCz3FqimxPqxFSGyiJtHJAJoFAoRxTsQPnageetGYZcMdtH3CprByPV4ho33xGAn1wTERkwJ56JQcBbSabYYn` | `479926994` | finalisé |
|
||||
| S05.4 | Token-2022 | Revoke | `3WjYXTMH8h7WAhpG641UHFGC3PfSYKZBHrnQuFJxsJ1agDq8BS7BfmKzXB1ciF3LKtLndRog4HiDybJ41EmTDgwC` | `479927342` | finalisé |
|
||||
| S05.5 | Token-2022 | BurnChecked | `4qRMULuArbjfnbqqqgpbs1AdVHA5XLZkxSA1h8M3BnkTjRCXNA7rDbGhNhMBc2GCoYeYyKmfT1YCPxySfYp67Rhz` | `479927657` | finalisé |
|
||||
| S05.6 | Token-2022 | FreezeAccount | `4E5GuHkRQjRJNCnr1WgMk9c4XYEu2qpH1KibrQcj1dK5wa1x9Jh3RTCxqYh63EZtbMB9JeK9F5SMcP6TqQm1pT4R` | `479927943` | finalisé |
|
||||
| S05.7 | Token-2022 | ThawAccount | `37D9d14hHpkBSj8WbKc4wtKssNhMzfTrXUANwvt8xZ3VypSZe43MxtEm2u7RHkdBhUVfms7vsuE5gjAfmREAXMJ2` | `479928232` | finalisé |
|
||||
| S05.8 | Token-2022 | CloseAccount | `3rarADrqnYkmGBFsNYCABE2WCKoE9KcP7d2bsqZDCn7pjLwHFKnjw7w3h1hMa3aWodXfcZz7DDCqgzvMamuS4AHP` | `479928489` | finalisé |
|
||||
|
||||
## Invariants vérifiés
|
||||
|
||||
Pour les scénarios applicatifs S02 à S05 concernés, les sorties ont confirmé selon la surface :
|
||||
|
||||
- simulation exacte réussie ;
|
||||
- confirmation réseau ;
|
||||
- insertion canonique ;
|
||||
- extraction Core ;
|
||||
- replay de décodage sans échec ;
|
||||
- matérialisation attendue ;
|
||||
- second replay idempotent ;
|
||||
- séparation correcte entre SPL Token classique, ATA et Token-2022.
|
||||
|
||||
La fixture Token-2022 est générée par une commande idempotente :
|
||||
|
||||
```bash
|
||||
cargo run -p kb-pipeline-demo-scenarios --bin kb-pipeline-demo-scenarios-cli -- prepare-token-2022-fixture --rpc-url "$KB_DEVNET_RPC_URL" --wallet "$KB_DEVNET_WALLET" --wallet-dir "$PWD/wallets/temporary/local_devnet" --decimals 9
|
||||
```
|
||||
|
||||
Le second passage a retourné `fixture_written=false`, sans recréer les comptes.
|
||||
|
||||
## Surface reportée
|
||||
|
||||
Le registre ElGamal n’est pas validé dans `pre.062`.
|
||||
|
||||
Motifs :
|
||||
|
||||
- absence d’un générateur de compte de contexte de preuve `PubkeyValidity` ;
|
||||
- panneau desktop Registry non raccordé à un handler et à une commande Tauri complète.
|
||||
|
||||
Le code existant ne doit pas être présenté comme validé Devnet avant une campagne dédiée.
|
||||
|
||||
## État avant commit
|
||||
|
||||
La prerelease est commitable lorsque les commandes suivantes restent propres dans le workspace utilisateur :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
Le user a confirmé Clippy et l’audit après ajout manuel de deux `return` manquants dans des closures `or_else`. Ces corrections locales doivent être incluses dans le commit.
|
||||
|
||||
La refonte générale de `README.md`, `ROADMAP.md`, `CHANGELOG.md` et des documents historiques est volontairement reportée à la phase suivante ; ce rapport ne prétend pas la remplacer.
|
||||
@@ -0,0 +1,44 @@
|
||||
<!-- file: docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation fonctionnelle — Metaplex Token Metadata 0.4.7
|
||||
|
||||
## Périmètre
|
||||
|
||||
La version couvre le décodage d’instructions et de comptes, les PDA et owners, les matérialisations, les builders et l’exécuteur, l’orchestration stateful, les scénarios synthétiques et le runner Devnet desktop.
|
||||
|
||||
## Validations réseau observées
|
||||
|
||||
Des parcours représentatifs ont été exécutés avec :
|
||||
|
||||
- préparation Rust native du mint SPL ;
|
||||
- simulation RPC exacte ;
|
||||
- soumission explicitement confirmée ;
|
||||
- confirmation Devnet ;
|
||||
- lectures de postcondition ;
|
||||
- matérialisation optionnelle.
|
||||
|
||||
Les opérations observées comprennent `Create`, `UpdateAsUpdateAuthorityV2` et la transition vers des metadata immutables, notamment sur les parcours NFT et fungible.
|
||||
|
||||
## Qualification des autres opérations
|
||||
|
||||
Les autres opérations exposées par l’exécuteur restent validées par leurs builders, matrices, tests unitaires, tests stateful et scénarios synthétiques. Leur validation Devnet spécialisée est reportée lorsque les fixtures nécessitent des chaînes de comptes supplémentaires : édition imprimée, burn, collection parent/membre, token records pNFT, délégations et rule sets.
|
||||
|
||||
Ce report ne doit pas être interprété comme une preuve réseau. Les statuts de validation doivent continuer à distinguer synthétique, simulé, soumis, non applicable et indisponible.
|
||||
|
||||
## Limites
|
||||
|
||||
- aucun fetch HTTP/IPFS/Arweave ;
|
||||
- aucune fusion avec SPL Token Metadata ou metadata Token-2022 ;
|
||||
- aucune déclaration de validation réseau du registre ElGamal.
|
||||
|
||||
## Contrôles de clôture
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
@@ -1,94 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_002_METAPLEX_COVERAGE_AND_FACT_OWNERSHIP.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# `0.4.7-pre.002` — couverture Metaplex et propriété des faits
|
||||
|
||||
## Résultat corrigé
|
||||
|
||||
Le contrat couvre les 58 discriminants `0..57` sans trou. La classification a été corrigée pendant `pre.003` après confrontation avec les recommandations de dépréciation officielles de Metaplex : une instruction encore décodable dans l’IDL historique n’est pas nécessairement légitime à reconstruire.
|
||||
|
||||
- `decode_only_bridge_boundary` : 1 ;
|
||||
- `decode_only_obsolete` : 15 ;
|
||||
- `decode_only_replaced` : 22 ;
|
||||
- `executable_current` : 20.
|
||||
|
||||
Les 20 opérations courantes doivent toutes posséder un intent et un builder à la fin de `pre.006`. Les instructions remplacées ou obsolètes restent décodées et peuvent produire les faits stables prouvés, mais leur reconstruction est interdite.
|
||||
|
||||
## Contrat par instruction
|
||||
|
||||
| Disc. | Instruction | Statut | Exécution | Cible | Signers IDL |
|
||||
|------:|-------------------------------------------------------------|-------------------------------|------------------------------------|-----------|---------------------------------------------------------------------------------------------------------|
|
||||
| 0 | `CreateMetadataAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
|
||||
| 1 | `UpdateMetadataAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority |
|
||||
| 2 | `DeprecatedCreateMasterEdition` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority, printingMintAuthority, mintAuthority, payer, oneTimePrintingAuthorizationMintAuthority |
|
||||
| 3 | `DeprecatedMintNewEditionFromMasterEditionViaPrintingToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | mintAuthority, burnAuthority, payer |
|
||||
| 4 | `UpdatePrimarySaleHappenedViaToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner |
|
||||
| 5 | `DeprecatedSetReservationList` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | resource |
|
||||
| 6 | `DeprecatedCreateReservationList` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | payer, updateAuthority |
|
||||
| 7 | `SignMetadata` | `decode_only_replaced` | `forbidden_replaced` | `—` | creator |
|
||||
| 8 | `DeprecatedMintPrintingTokensViaToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | burnAuthority |
|
||||
| 9 | `DeprecatedMintPrintingTokens` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority |
|
||||
| 10 | `CreateMasterEdition` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, mintAuthority, payer |
|
||||
| 11 | `MintNewEditionFromMasterEditionViaToken` | `decode_only_replaced` | `forbidden_replaced` | `—` | newMintAuthority, payer, tokenAccountOwner |
|
||||
| 12 | `ConvertMasterEditionV1ToV2` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | aucun |
|
||||
| 13 | `MintNewEditionFromMasterEditionViaVaultProxy` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | newMintAuthority, payer, vaultAuthority |
|
||||
| 14 | `PuffMetadata` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | aucun |
|
||||
| 15 | `UpdateMetadataAccountV2` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority |
|
||||
| 16 | `CreateMetadataAccountV2` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
|
||||
| 17 | `CreateMasterEditionV3` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, mintAuthority, payer |
|
||||
| 18 | `VerifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
|
||||
| 19 | `Utilize` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | useAuthority |
|
||||
| 20 | `ApproveUseAuthority` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner, payer |
|
||||
| 21 | `RevokeUseAuthority` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner |
|
||||
| 22 | `UnverifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority |
|
||||
| 23 | `ApproveCollectionAuthority` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, payer |
|
||||
| 24 | `RevokeCollectionAuthority` | `decode_only_replaced` | `forbidden_replaced` | `—` | revokeAuthority |
|
||||
| 25 | `SetAndVerifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
|
||||
| 26 | `FreezeDelegatedAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | delegate |
|
||||
| 27 | `ThawDelegatedAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | delegate |
|
||||
| 28 | `RemoveCreatorVerification` | `decode_only_replaced` | `forbidden_replaced` | `—` | creator |
|
||||
| 29 | `BurnNft` | `decode_only_replaced` | `forbidden_replaced` | `—` | owner |
|
||||
| 30 | `VerifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
|
||||
| 31 | `UnverifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
|
||||
| 32 | `SetAndVerifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
|
||||
| 33 | `CreateMetadataAccountV3` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
|
||||
| 34 | `SetCollectionSize` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | collectionAuthority |
|
||||
| 35 | `SetTokenStandard` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority |
|
||||
| 36 | `BubblegumSetCollectionSize` | `decode_only_bridge_boundary` | `forbidden_cross_program_boundary` | `—` | collectionAuthority, bubblegumSigner |
|
||||
| 37 | `BurnEditionNft` | `decode_only_replaced` | `forbidden_replaced` | `—` | owner |
|
||||
| 38 | `CreateEscrowAccount` | `executable_current` | `required` | `pre.006` | payer, authority |
|
||||
| 39 | `CloseEscrowAccount` | `executable_current` | `required` | `pre.006` | payer |
|
||||
| 40 | `TransferOutOfEscrow` | `executable_current` | `required` | `pre.006` | payer, authority |
|
||||
| 41 | `Burn` | `executable_current` | `required` | `pre.005` | authority |
|
||||
| 42 | `Create` | `executable_current` | `required` | `pre.003` | authority, payer |
|
||||
| 43 | `Mint` | `executable_current` | `required` | `pre.006` | authority, payer |
|
||||
| 44 | `Delegate` | `executable_current` | `required` | `pre.005` | authority, payer |
|
||||
| 45 | `Revoke` | `executable_current` | `required` | `pre.005` | authority, payer |
|
||||
| 46 | `Lock` | `executable_current` | `required` | `pre.005` | authority, payer |
|
||||
| 47 | `Unlock` | `executable_current` | `required` | `pre.005` | authority, payer |
|
||||
| 48 | `Migrate` | `executable_current` | `required` | `pre.006` | payer, authority |
|
||||
| 49 | `Transfer` | `executable_current` | `required` | `pre.005` | authority, payer |
|
||||
| 50 | `Update` | `executable_current` | `required` | `pre.003` | authority, payer |
|
||||
| 51 | `Use` | `executable_current` | `required` | `pre.006` | authority, payer |
|
||||
| 52 | `Verify` | `executable_current` | `required` | `pre.004` | authority |
|
||||
| 53 | `Unverify` | `executable_current` | `required` | `pre.004` | authority |
|
||||
| 54 | `Collect` | `executable_current` | `required` | `pre.006` | authority |
|
||||
| 55 | `Print` | `executable_current` | `required` | `pre.006` | editionMintAuthority, payer |
|
||||
| 56 | `Resize` | `executable_current` | `required` | `pre.006` | authority |
|
||||
| 57 | `CloseAccounts` | `executable_current` | `required` | `pre.005` | authority |
|
||||
|
||||
## Propriété des faits
|
||||
|
||||
La matrice contient 26 faits à propriétaire unique. Les domaines Metaplex et Token-2022 embedded restent séparés.
|
||||
|
||||
## Validations exécutées par l’opérateur pour `pre.002`
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK
|
||||
python3 scripts/audit_rust_workspace_rules.py clean
|
||||
cargo test -p kb-lib 627 + 4 tests OK
|
||||
```
|
||||
|
||||
La classification corrigée et le code de `pre.003` doivent être revalidés avant acceptation.
|
||||
@@ -1,58 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_003_METAPLEX_EXECUTOR_FOUNDATIONS.md -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# `0.4.7-pre.003` — fondations de l’exécuteur Metaplex
|
||||
|
||||
## Portée
|
||||
|
||||
Cette prerelease remplace la frontière réservée de l’exécuteur Metaplex Token Metadata par une surface typée initiale comprenant :
|
||||
|
||||
- `Create`, discriminant `42`, avec `CreateArgs::V1` ;
|
||||
- `Update`, discriminant `50`, avec `UpdateArgs::AsUpdateAuthorityV2` ;
|
||||
- `PuffMetadata`, discriminant `14`, exécutable dépréciée ;
|
||||
- `SetTokenStandard`, discriminant `35`, exécutable dépréciée.
|
||||
|
||||
Les autres variantes du wrapper `Update` restent planifiées selon leurs domaines d’autorité. Les anciennes instructions create/update remplacées restent decode-only et pointent vers leur wrapper canonique final.
|
||||
|
||||
## Contrats introduits
|
||||
|
||||
- intents typés et codes d’opération stables ;
|
||||
- `#[deprecated]` sur les variantes Rust obsolètes ;
|
||||
- approbation opérateur runtime obligatoire pour toute opération dépréciée ;
|
||||
- builders officiels `mpl-token-metadata 5.1.x` ;
|
||||
- validation des PDA metadata et edition ;
|
||||
- comptes et signers exacts dérivés de l’instruction construite ;
|
||||
- simulation obligatoire et dry-run imposé pour cette première tranche ;
|
||||
- plafonds positifs de frais et de dépense ;
|
||||
- paire complète obligatoire pour les comptes Token Authorization Rules ;
|
||||
- autorisation explicite de chaque signer requis ;
|
||||
- erreurs fail-closed avant production du plan préparé.
|
||||
|
||||
## Classification corrigée
|
||||
|
||||
- 20 instructions courantes et constructibles ;
|
||||
- 15 instructions obsolètes mais constructibles, classées `executable_deprecated` ;
|
||||
- 22 instructions remplacées par leur version canonique finale ;
|
||||
- 1 frontière Bubblegum.
|
||||
|
||||
`pre.003` implémente les deux opérations courantes de sa tranche et les deux opérations obsolètes qui lui sont affectées. Les autres opérations dépréciées sont réparties jusqu’à `pre.006`.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-lib
|
||||
```
|
||||
|
||||
Cargo n’est pas disponible dans l’environnement de préparation. Les validations Rust doivent être exécutées par l’opérateur avant acceptation.
|
||||
|
||||
## Correctif de conformité `fix-002`
|
||||
|
||||
- la dépendance directe `solana-program` introduite par `pre.003` est retirée ;
|
||||
- les contrats internes reposent sur `solana_instruction::Instruction` et `solana_pubkey::Pubkey` ;
|
||||
- les types historiques internes de `mpl-token-metadata 5.1.1` sont laissés à l’inférence puis convertis immédiatement, sans fuite dans l’API de `kb-lib` ;
|
||||
- tous les usages de l’opérateur `?` introduits dans le builder et le dispatcher Metaplex sont remplacés par une propagation explicite des erreurs ;
|
||||
- les TODO de réaudit des exécuteurs Solana Core/SPL et de l’orchestration pipeline sont enregistrés pour une version ultérieure à déterminer.
|
||||
@@ -1,23 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_004_METAPLEX_COLLECTIONS_CREATORS_AUTHORITIES.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.004` — collections, créateurs et autorités
|
||||
|
||||
## Surface livrée
|
||||
|
||||
- wrappers courants `Verify` et `Unverify` ;
|
||||
- variantes `CreatorV1` et `CollectionV1` ;
|
||||
- opération dépréciée `SetCollectionSize` avec approbation explicite ;
|
||||
- validation des combinaisons de comptes et des PDA collection metadata/master edition ;
|
||||
- anciennes instructions remplacées conservées en decode-only.
|
||||
|
||||
## Validation de préparation
|
||||
|
||||
- audit Rust général : à exécuter ;
|
||||
- audit des exports : à exécuter ;
|
||||
- `cargo fmt --all` : à exécuter localement ;
|
||||
- `cargo check --workspace` : à exécuter localement ;
|
||||
- `cargo clippy --all-targets` : à exécuter localement ;
|
||||
- `cargo test -p kb-lib` : à exécuter localement.
|
||||
|
||||
Aucune validation réseau n'est déclarée dans cette prerelease.
|
||||
@@ -1,26 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_006_METAPLEX_EXECUTOR_CLOSURE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.006` — fermeture de l’exécuteur Metaplex
|
||||
|
||||
## Résultat contractuel
|
||||
|
||||
- 58 discriminants classés sans état ouvert ;
|
||||
- 20 opérations courantes avec intent et builder ;
|
||||
- 15 opérations obsolètes officiellement constructibles avec `#[deprecated]` et approbation opérateur explicite ;
|
||||
- 22 versions remplacées conservées en decode-only avec remplacement canonique ;
|
||||
- 1 frontière Bubblegum sans builder Metaplex ;
|
||||
- aucune opération officiellement constructible reportée après `pre.006`.
|
||||
|
||||
## Construction
|
||||
|
||||
Les opérations restantes utilisent le contrat de comptes positionnels de l’IDL archivée et les types d’arguments Borsh officiels de `mpl-token-metadata 5.1.1`. Les signers et flags writable sont conservés exactement dans les `AccountMeta`.
|
||||
|
||||
## Contrôles de préparation
|
||||
|
||||
- matrice JSON lisible et fermée ;
|
||||
- audit Rust général propre ;
|
||||
- audit de complétude des exports propre ;
|
||||
- absence de `?`, `unwrap`, `expect` et `panic!` dans la surface Metaplex ajoutée.
|
||||
|
||||
Les commandes Cargo doivent être exécutées sur le workspace opérateur avant validation définitive de la prerelease.
|
||||
@@ -1,21 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_007_METAPLEX_PIPELINE_GENERALISTE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.007` — pipeline généraliste Metaplex
|
||||
|
||||
## Contrats introduits
|
||||
|
||||
- lectures RPC `confirmed` bornées pour metadata, edition et token record ;
|
||||
- validation owner, taille, contexte, PDA et décodage délégué à `kb-lib` ;
|
||||
- préflight des plans Metaplex, corrélation bornée et approbation des opérations dépréciées ;
|
||||
- orchestration liée au hash exact de simulation ;
|
||||
- résolution complète des signers et blocage du send en dry-run ;
|
||||
- postconditions `confirmed`, `contradicted` et `not_applicable` sans succès inventé.
|
||||
|
||||
## Frontière
|
||||
|
||||
`kb-pipeline` reste généraliste et ne dépend pas de `kb-pipeline-demo-scenarios`. Les fixtures et campagnes Devnet/Testnet sont reportées à `pre.008`.
|
||||
|
||||
## Validation de préparation
|
||||
|
||||
Les audits statiques doivent être exécutés dans l’environnement de préparation. Les commandes Cargo doivent être exécutées sur le workspace local, car `cargo` n’est pas disponible ici.
|
||||
@@ -1,30 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_008_METAPLEX_SYNTHETIC_AND_NETWORK_VALIDATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.008` — scénarios Metaplex
|
||||
|
||||
## Couverture
|
||||
|
||||
- NFT ;
|
||||
- SFT ;
|
||||
- token fongible ;
|
||||
- collection ;
|
||||
- programmable NFT.
|
||||
|
||||
## Contrats
|
||||
|
||||
Les scénarios synthétiques sont déterministes et simulation-safe. La matrice réseau distingue `not_run`, `synthetic_validated`, `simulated`, `submitted`, `confirmed`, `unavailable` et `failed`. Aucun statut réseau n’est déclaré sans preuve observée.
|
||||
|
||||
## CLI
|
||||
|
||||
Aucune nouvelle commande n’est ajoutée : le CLI reste destiné à la préparation Token-2022 tant qu’une fixture Metaplex dédiée n’est pas nécessaire.
|
||||
|
||||
## Validation locale à exécuter
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
```
|
||||
@@ -1,37 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_009_METAPLEX_DESKTOP.md -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Validation `0.4.7-pre.009` — desktop Metaplex Token Metadata
|
||||
|
||||
## Périmètre
|
||||
|
||||
La prerelease ajoute la fenêtre Tauri `demo_execution_metadata` et adapte les inventaires synthétiques et Devnet de `kb-pipeline-demo-scenarios`.
|
||||
|
||||
## État constaté après `fix-001`
|
||||
|
||||
Le panneau changeait uniquement les contrats JSON affichés. Il ne chargeait aucun profil Devnet, ne préparait aucune base PostgreSQL et n'appelait aucune commande de simulation ou de soumission Metaplex. La présence de scénarios marqués `network_simulation` ne constituait donc pas une validation réseau.
|
||||
|
||||
## Correction `fix-002`
|
||||
|
||||
- ajout du choix d'un profil Devnet compatible ;
|
||||
- réutilisation de la commande commune `demo_execution_solana_core_options` pour charger les profils ;
|
||||
- réutilisation de `demo_execution_devnet_prepare_profile` pour vérifier ou initialiser réellement la base PostgreSQL du profil ;
|
||||
- affichage du rapport de préparation de la base avec le JSON viewer commun ;
|
||||
- ajout explicite de `networkExecutionPerformed: false` et `networkEvidenceCollected: false` dans les résultats tant qu'aucune transaction Metaplex n'est simulée ;
|
||||
- suppression de toute présentation des contrats Devnet comme preuve de simulation réseau ;
|
||||
- conservation des scénarios synthétiques de démonstration.
|
||||
|
||||
## Limite restante
|
||||
|
||||
`fix-002` corrige le faux raccordement Devnet et restaure le chargement du profil et de la base. Il n'ajoute pas encore l'orchestration complète d'une transaction Metaplex Devnet. `pre.009` ne peut donc pas être déclarée validée sur réseau tant que le desktop n'appelle pas un scénario d'exécution réel produisant au minimum une simulation RPC, un slot et les postconditions correspondantes.
|
||||
|
||||
## Validation locale
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-app-demo-desktop
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
@@ -1,72 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_010_METAPLEX_CROSS_VALIDATION.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Validation `0.4.7-pre.010` — corpus croisé Metaplex Token Metadata
|
||||
|
||||
## Objet
|
||||
|
||||
Cette prerelease ferme le corpus de validation croisée sans ajouter une nouvelle capacité d’exécution. Elle vérifie l’alignement entre décodeur, matérialisation, exécuteur, pipeline, scénarios réutilisables et desktop.
|
||||
|
||||
## Corpus machine-readable
|
||||
|
||||
`test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_CROSS_VALIDATION_MATRIX.json` contient 19 cas :
|
||||
|
||||
- chemins outer et CPI ;
|
||||
- transactions réussies et échouées ;
|
||||
- NFT, SFT, token fongible, collection et programmable NFT ;
|
||||
- mauvais Program ID, owner, PDA et comptes ;
|
||||
- payload tronqué, suffixe interdit et discriminant inconnu ;
|
||||
- conflit Metaplex/metadata Token-2022 ;
|
||||
- contrats séparés de simulation, soumission et postcondition Devnet.
|
||||
|
||||
## Exactitude des preuves réseau
|
||||
|
||||
Les trois cas réseau restent `not_run` sans preuve. Le validateur interdit de les promouvoir avec le statut `synthetic_validated` et exige toutes les catégories de preuves prévues avant `simulated`, `submitted` ou `confirmed`.
|
||||
|
||||
Le panneau desktop `pre.009-fix-002` charge le profil et prépare la base Devnet, mais n’exécute pas encore une transaction Metaplex. Cette préparation n’est donc pas comptée comme validation réseau.
|
||||
|
||||
## Validation locale exécutée le 2 août 2026
|
||||
|
||||
Les commandes suivantes ont été exécutées sur le workspace local `0.4.7-pre.10` :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
cargo test -p kb-lib
|
||||
cargo test -p kb-pipeline
|
||||
cargo test -p kb-app-demo-desktop
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Résultats observés :
|
||||
|
||||
- `cargo fmt --all` : succès ;
|
||||
- `cargo check --workspace` : succès sur les onze crates ;
|
||||
- `cargo clippy --all-targets` : succès ;
|
||||
- audit Rust général : propre ;
|
||||
- complétude des exports : `0 candidate(s)` ;
|
||||
- audit Khadhroony : propre ;
|
||||
- `kb-pipeline-demo-scenarios` : 47 tests de bibliothèque et 1 test du binaire réussis ;
|
||||
- `kb-lib` : 641 tests unitaires et 4 tests d’intégration réussis ;
|
||||
- `kb-pipeline` : 92 tests réussis ;
|
||||
- `kb-app-demo-desktop` : 120 tests réussis ;
|
||||
- lancement Tauri : application démarrée et panneau Metadata ouvert.
|
||||
|
||||
## Archive d’observation `mainnet_research`
|
||||
|
||||
L’archive `mainnet_research.v0.4.7-pre.010-01.zip` prouve les éléments suivants :
|
||||
|
||||
- démarrage du desktop avec le profil actif `mainnet_research` ;
|
||||
- chargement de trois profils configurés ;
|
||||
- initialisation ou vérification des treize tables PostgreSQL attendues ;
|
||||
- ouverture de la fenêtre `demo_execution_metadata` ;
|
||||
- absence d’erreur applicative ou Rust dans les journaux fournis.
|
||||
|
||||
Cette archive ne contient toutefois aucune signature, aucun slot de simulation Metaplex, aucun log `simulateTransaction` et aucune preuve de postcondition réseau. Elle valide donc le démarrage applicatif, le profil et la préparation PostgreSQL, mais pas une simulation ou une soumission Metaplex sur Mainnet.
|
||||
|
||||
## Statut de `pre.010`
|
||||
|
||||
La validation locale du code et des contrats est réussie. Les trois cas de preuve réseau de la matrice restent `not_run` jusqu’à production des artefacts réseau exigés. Cette absence de preuve n’empêche pas la validation de la prerelease de consolidation, mais interdit toute déclaration de validation réseau Metaplex.
|
||||
@@ -1,25 +0,0 @@
|
||||
<!-- 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.
|
||||
@@ -1,31 +0,0 @@
|
||||
<!-- 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.
|
||||
@@ -1,43 +0,0 @@
|
||||
<!-- 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,54 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_012_METAPLEX_DEVNET_RUNNER_COVERAGE.md -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Validation `0.4.7-pre.012` — couverture du runner Devnet Metaplex
|
||||
|
||||
## Résultat
|
||||
|
||||
La matrice Devnet couvre exactement les 20 opérations `executable_current`. Les quatre opérations du premier lot restent attribuées à `pre.011` et les seize restantes à `pre.012`. Toutes portent désormais `runnerStatus: implemented`.
|
||||
|
||||
## Accès aux campagnes
|
||||
|
||||
`DevnetMetaplexTokenMetadataExecutionRequest::from_operation_json` désérialise une opération typée, rejette les opérations dépréciées et produit une requête simulation-only. Le test opt-in `optional_devnet_current_operation_from_env` permet une simulation RPC réelle ou une soumission explicitement confirmée.
|
||||
|
||||
## Correctif de compilation
|
||||
|
||||
Le contrat `MetaplexTokenMetadataStatefulReadRequest` dérive désormais `Deserialize` et `Serialize`. Les listes JSON fournies par `KB_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` et `KB_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` peuvent donc être chargées par le test opt-in. Un test de round-trip JSON protège ce contrat.
|
||||
|
||||
## Statut réseau
|
||||
|
||||
Aucune preuve réseau n’est inventée dans ce livrable. Les 20 opérations restent `not_run` jusqu’à exécution locale avec fixtures, endpoint Devnet, wallet et préconditions compatibles.
|
||||
|
||||
## Validations à exécuter localement
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
```
|
||||
|
||||
## Correctif ergonomique `fix-002`
|
||||
|
||||
Le placeholder `{"operation":"..."}` n'est plus présenté comme exécutable et est rejeté avec une erreur dédiée. La crate expose désormais :
|
||||
|
||||
- l'inventaire des vingt opérations courantes ;
|
||||
- des modèles JSON pour `Create`, `Update`, `Verify` et `Unverify` ;
|
||||
- des constructeurs nommés pour `Verify` et `Unverify` créateur ;
|
||||
- des tests vérifiant la validité JSON des modèles et le caractère conservateur des requêtes nommées.
|
||||
|
||||
Les modèles utilisent des valeurs entre chevrons qui doivent être remplacées par des comptes Devnet réels. Ils ne constituent pas une preuve réseau.
|
||||
|
||||
|
||||
## Correctif de dépendance et d’assertion `fix-003`
|
||||
|
||||
La crate déclare désormais explicitement `mpl-token-metadata.workspace = true`, nécessaire aux types utilisés directement par les modèles de campagnes. Le test de rejet du placeholder attend le code stable `config`, conformément au contrat de `kb_core::Error::config`.
|
||||
|
||||
Validations opérateur observées avant ce correctif :
|
||||
|
||||
- `cargo fmt --all` : réussi ;
|
||||
- `cargo check --workspace` : réussi ;
|
||||
- `cargo clippy --all-targets` : réussi ;
|
||||
- audit général, exports et règles Khadhroony : propres ;
|
||||
- `cargo test -p kb-pipeline-demo-scenarios` : 53 tests réussis et un seul échec limité à l’assertion `configuration_error` au lieu de `config`.
|
||||
@@ -1,125 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_013_METAPLEX_DESKTOP_DEVNET_EXECUTION.md -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Validation `0.4.7-pre.013` — exécution Metadata Devnet desktop
|
||||
|
||||
## Périmètre
|
||||
|
||||
- adaptateurs Tauri minces vers `kb-pipeline-demo-scenarios` ;
|
||||
- inventaire des 20 opérations courantes ;
|
||||
- modèles JSON typés disponibles pour les parcours nommés ;
|
||||
- simulation RPC Devnet réelle par défaut ;
|
||||
- soumission uniquement avec `submit` et `operatorConfirmed` ;
|
||||
- affichage distinct du plan, du préflight, de la simulation et des preuves stateful ;
|
||||
- maintien des scénarios synthétiques.
|
||||
|
||||
## Contrats de sécurité
|
||||
|
||||
- profil obligatoirement classé Devnet ;
|
||||
- opérations dépréciées rejetées par le runner réutilisable ;
|
||||
- intent et lectures stateful désérialisés côté Rust ;
|
||||
- une campagne Devnet déjà active bloque une seconde exécution ;
|
||||
- aucune preuve réseau n’est produite par les scénarios synthétiques.
|
||||
|
||||
## Correctif `pre.013-fix-001`
|
||||
|
||||
- correction de la conversion de `MdSignature` vers la chaîne UI en lisant explicitement la valeur du newtype ;
|
||||
- aucun changement du contrat réseau, du runner ou des DTO ;
|
||||
- compilation et validations locales à rejouer après application.
|
||||
|
||||
## Validation locale attendue
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-app-demo-desktop
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
La validation manuelle doit remplacer les placeholders par des comptes Devnet réels, lancer une simulation puis, pour un parcours maîtrisé, une soumission explicitement confirmée. Les signatures, slots et postconditions doivent être conservés comme preuves avant la clôture.
|
||||
|
||||
## Correctif guide, fixture Create et profils Devnet
|
||||
|
||||
- ajout du guide intégré et du journal d’exécution dans le panneau Metadata ;
|
||||
- ajout des titres des blocs JSON ;
|
||||
- ajout du préparateur de fixture `Create` avec mint SPL classique et PDA dérivés ;
|
||||
- ajout des dépendances directes `mpl-token-metadata` et `solana-pubkey` dans `kb-pipeline-demo-scenarios` ;
|
||||
- chargement des profils via une commande Metadata dédiée ;
|
||||
- préparation automatique du profil sélectionné, comme dans les panneaux Solana Core et SPL ;
|
||||
- diagnostic explicite lorsqu’aucun profil Devnet compatible n’est retourné.
|
||||
|
||||
## Correctif d’initialisation frontend
|
||||
|
||||
- les listes de profils, contrats et opérations restaient vides parce que l’initialisation `DOMContentLoaded` échouait avant les appels Tauri ;
|
||||
- le TypeScript attendait `clearMetadataLogButton` et `metadataExecutionLogOutput`, absents du HTML ;
|
||||
- les deux contrôles sont ajoutés au panneau ;
|
||||
- un test de contrat vérifie désormais la présence de tous les identifiants nécessaires au chargement initial.
|
||||
|
||||
|
||||
## Correctif fix-005
|
||||
|
||||
- suppression de la duplication des contrôles Copier/Effacer du journal ;
|
||||
- ajout d’un panneau de paramètres communs Devnet avec limites du profil ;
|
||||
- séparation des boutons Simuler et Soumettre ;
|
||||
- autorisation de construire un plan de soumission avec `dry_run = false`, la simulation exacte restant obligatoire avant signature et envoi ;
|
||||
- maintien du refus de soumission sans confirmation opérateur.
|
||||
|
||||
## Correctif `pre.013-fix-006` — print supply NFT
|
||||
|
||||
La campagne Devnet a atteint le programme Metaplex et exécuté l’instruction `Create` en simulation réelle. Le programme a refusé le modèle avec l’erreur `Print supply is required for non-fungibles` (`Custom(166)`) parce que `print_supply` était `null`.
|
||||
|
||||
Le modèle nommé et le préparateur de fixture utilisent désormais `PrintSupply::Zero`, sérialisé sous la forme JSON `"Zero"`, pour le scénario `NonFungible`. Un test empêche la régression. La simulation et la soumission doivent être rejouées après application ; aucune soumission réussie n’est déclarée dans ce rapport.
|
||||
## Correctif `pre.013-fix-007` — programme SPL Token requis
|
||||
|
||||
La simulation réelle suivante a dépassé la validation de `PrintSupply::Zero`, puis le programme Metaplex a refusé l’instruction avec `Missing SPL token program` (`Custom(149)`). Le transport RPC, la compilation du message, l’estimation des frais et l’appel `simulateTransaction` ont donc été confirmés ; aucune soumission n’a eu lieu.
|
||||
|
||||
Le modèle nommé et le préparateur de fixture `Create` renseignent désormais explicitement le programme SPL Token classique canonique :
|
||||
|
||||
```text
|
||||
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
|
||||
```
|
||||
|
||||
Les tests vérifient conjointement `print_supply = "Zero"` et ce Program ID. La campagne doit être rejouée en simulation avant toute soumission.
|
||||
|
||||
|
||||
## Correctif `fix-008` — préconditions réseau par opération
|
||||
|
||||
- la fixture `Create` utilise un nouveau mint versionné créé avec freeze authority active ;
|
||||
- owner, layout classique, décimales, supply, mint authority et freeze authority sont vérifiés avant génération de l’intent ;
|
||||
- une opération sans modèle nommé efface l’intent courant et bloque simulation/soumission, au lieu de réutiliser le JSON précédent ;
|
||||
- les requirements Metaplex sont documentés dans `kb-lib/USAGE.md` et `kb-pipeline/USAGE.md` ;
|
||||
- les simulations observées avant ce correctif ont toutes échoué et ne sont pas déclarées validées.
|
||||
|
||||
## Correctif 009 — parcours cohérents et matérialisation optionnelle
|
||||
|
||||
La validation desktop n’utilise plus implicitement une opération isolée sans contexte de fixture. L’inventaire expose cinq parcours : NFT classique, SFT, fungible, collection parent/membre et pNFT. Chaque parcours précise la fixture, l’état initial, l’état terminal, les opérations applicables et les projections attendues.
|
||||
|
||||
La matérialisation est désormais une option opérateur indépendante. Après confirmation, elle exige des lectures de postcondition, décode les comptes Metaplex bornés et produit les projections canoniques correspondantes. Elle ne télécharge pas les URI off-chain.
|
||||
|
||||
La fixture NFT a été versionnée en `create-mint-profile-authority-v3.json` afin de ne pas réutiliser le mint déjà soumis. La mint authority et la freeze authority doivent être le wallet du profil, tandis que le keypair du mint ne sert qu’à signer la création du compte mint.
|
||||
|
||||
## Correctif `0.4.7-pre.013-fix-010` — compatibilité de la CLI `spl-token`
|
||||
|
||||
La CLI locale utilisée pour les validations ne prend pas en charge l’option `create-token --freeze-authority`. Le préparateur utilise donc le parcours compatible suivant :
|
||||
|
||||
1. création du mint classique à `0` décimale avec `--enable-freeze` ;
|
||||
2. transfert explicite de l’autorité `freeze` depuis le keypair du mint vers le wallet du profil ;
|
||||
3. transfert explicite de l’autorité `mint` vers le même wallet ;
|
||||
4. relecture du compte et validation stricte des deux autorités avant génération de l’intent Metaplex.
|
||||
|
||||
La fixture est versionnée en `create-mint-profile-authority-v4.json` afin de ne pas réutiliser un mint absent ou partiellement préparé par le correctif précédent.
|
||||
|
||||
### 0.4.7-pre.13 fix-011
|
||||
|
||||
- remplace la préparation Metaplex fondée sur `solana-keygen`, `solana` et `spl-token` par une transaction Rust native ;
|
||||
- crée le mint par `SystemCreateAccount` puis `SPL Token InitializeMint2` dans un même message simulé, signé et confirmé ;
|
||||
- utilise explicitement le wallet du profil comme mint authority et freeze authority ;
|
||||
- conserve le keypair du mint dans `kb-wallet` sans exposer ni déléguer ses secrets à une CLI externe.
|
||||
|
||||
|
||||
## Correctif fonctionnel fix-014
|
||||
|
||||
Le panneau n’expose plus les cinq parcours Devnet comme s’ils étaient tous préparables. Le premier parcours réellement exécutable est le NFT classique `create -> update`. La préparation d’étape génère conjointement l’intent, les lectures avant confirmation et les lectures après confirmation utilisées par la matérialisation. Les parcours collection, SFT, fungible et pNFT restent présents dans la matrice synthétique cible et devront être activés seulement après ajout de leurs fixtures complètes.
|
||||
@@ -1,42 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_014_METAPLEX_COHERENT_DEVNET_JOURNEYS.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.014` — parcours Metaplex Devnet cohérents
|
||||
|
||||
## Objet
|
||||
|
||||
Cette prérelease étend le runner Metadata depuis le seul parcours NFT vers cinq parcours Devnet préparables : NFT, SFT, fungible, collection parent et pNFT sans rule set.
|
||||
|
||||
Chaque parcours expose d'abord un cycle borné et comparable :
|
||||
|
||||
1. création native d'un mint SPL classique par le workspace ;
|
||||
2. préparation contextuelle de `Create` ;
|
||||
3. simulation exacte ;
|
||||
4. soumission et confirmation explicites ;
|
||||
5. relecture et matérialisation optionnelle des comptes applicables ;
|
||||
6. préparation de `UpdateAsUpdateAuthorityV2` depuis l'état créé ;
|
||||
7. simulation, soumission, confirmation et postconditions.
|
||||
|
||||
## Familles et contrats Create
|
||||
|
||||
| Parcours | `token_standard` | Edition relue | Particularité |
|
||||
|------------|---------------------------|--------------:|-----------------------------------------|
|
||||
| NFT | `NonFungible` | oui | `print_supply = Zero` |
|
||||
| SFT | `FungibleAsset` | non | `decimals = 0`, pas de master edition |
|
||||
| Fungible | `Fungible` | non | `decimals = 0`, pas de master edition |
|
||||
| Collection | `NonFungible` | oui | `collection_details = V1(size=0)` |
|
||||
| pNFT | `ProgrammableNonFungible` | oui | aucun rule set pour ce premier parcours |
|
||||
|
||||
## Limite volontaire
|
||||
|
||||
Cette prérelease ne déclare pas encore validées les opérations spécialisées `mint`, `verify`, `unverify`, `delegate`, `lock`, `unlock`, `transfer`, `revoke`, `burn`, `resize` et apparentées. Elles doivent être ajoutées comme étapes dépendantes d'un contexte confirmé, pas comme modèles JSON isolés.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
- `cargo fmt --all` ;
|
||||
- `cargo check --workspace` ;
|
||||
- `cargo clippy --all-targets` ;
|
||||
- `python3 scripts/audit_rust_workspace_rules.py` ;
|
||||
- `cargo test -p kb-pipeline-demo-scenarios` ;
|
||||
- `cargo test -p kb-app-demo-desktop` ;
|
||||
- pour chaque parcours : préparer `Create`, simuler, soumettre, confirmer, puis préparer et valider `Update`.
|
||||
@@ -1,34 +0,0 @@
|
||||
<!-- file: docs/validation/V0_4_7_PRE_015_METAPLEX_NFT_LIFECYCLE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Validation `0.4.7-pre.015` — cycle NFT classique
|
||||
|
||||
## Portée
|
||||
|
||||
Cette prérelease prolonge le parcours Devnet NFT classique validé en `pre.014`.
|
||||
|
||||
Le parcours exécutable devient :
|
||||
|
||||
1. création native du mint SPL classique ;
|
||||
2. `Create` Metaplex avec metadata et master edition ;
|
||||
3. `UpdateAsUpdateAuthorityV2` pour enregistrer la vente primaire ;
|
||||
4. `UpdateAsUpdateAuthorityV2` avec `is_mutable = false`.
|
||||
|
||||
La master edition n’est pas une étape séparée : elle est créée par le wrapper `Create` lorsque `master_edition` et `print_supply = Zero` sont fournis.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
Pour chaque étape :
|
||||
|
||||
- préparation contextuelle ;
|
||||
- simulation exacte réussie ;
|
||||
- soumission explicitement confirmée ;
|
||||
- confirmation Devnet ;
|
||||
- relecture du PDA metadata ;
|
||||
- matérialisation optionnelle du snapshot confirmé.
|
||||
|
||||
Après la dernière étape, une nouvelle mise à jour doit être refusée par Metaplex puisque les metadata sont immutables.
|
||||
|
||||
## Hors portée de cette prérelease
|
||||
|
||||
`Print` et `Burn` exigent encore des fixtures supplémentaires : token account du master, mint et token account de l’édition, edition marker et comptes de burn. Ils restent à implémenter dans la prérelease suivante et ne sont pas déclarés validés ici.
|
||||
Reference in New Issue
Block a user