v0.4.8-pre.014
This commit is contained in:
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md -->
|
||||
<!-- version: 55 -->
|
||||
<!-- version: 59 -->
|
||||
|
||||
# Plan `0.4.8` — Solana Program Metadata et complétude Token-2022
|
||||
|
||||
## 1. Statut et rôle
|
||||
|
||||
Ce document est le livrable principal de `0.4.8-pre.001`, réconcilié après l’audit contractuel de `0.4.8-pre.002`, les modèles de `pre.003`, les décodeurs de comptes de `pre.004`, le décodeur d’instructions de `pre.005`, la matérialisation de `pre.006`, l’exécuteur de `pre.007`, l’orchestration généraliste de `pre.008`, les scénarios réutilisables de `pre.009`, leur intégration desktop et leur campagne Devnet de `pre.010`, puis la complétude Token-2022 Token Metadata de `pre.011` et la préparation de sa campagne Devnet dédiée en `pre.012`. Il constitue le plan vivant de la version et reste modifiable lorsque l’audit du code, des interfaces officielles, de l’IDL ou des validations Devnet impose un ajustement.
|
||||
Ce document est le livrable principal de `0.4.8-pre.001`, réconcilié après l’audit contractuel de `0.4.8-pre.002`, les modèles de `pre.003`, les décodeurs de comptes de `pre.004`, le décodeur d’instructions de `pre.005`, la matérialisation de `pre.006`, l’exécuteur de `pre.007`, l’orchestration généraliste de `pre.008`, les scénarios réutilisables de `pre.009`, leur intégration desktop et leur campagne Devnet de `pre.010`, puis la complétude Token-2022 Token Metadata de `pre.011`, la préparation de sa campagne Devnet dédiée en `pre.012` et la clôture réseau Metaplex de `pre.013`. Il constitue le plan vivant de la version et reste modifiable lorsque l’audit du code, des interfaces officielles, de l’IDL ou des validations Devnet impose un ajustement.
|
||||
|
||||
Il doit être maintenu pendant chaque prerelease, puis archivé pendant la dernière prerelease après transfert des décisions durables vers le ROADMAP, les matrices, les guides, les rapports, les TODO et les changelogs concernés.
|
||||
|
||||
@@ -361,23 +361,141 @@ Résultat durable : la campagne réelle du 7 août 2026 confirme les cinq scéna
|
||||
|
||||
Les validations suivantes ferment ensuite `Create -> Mint` sur les cinq familles et `Verify -> Unverify` sur collection. Après `fix-019`, la matrice v3 compte 4 opérations `confirmed` et 16 `not_run`. `fix-020` corrige la fixture `Print` en laissant mint et ATA d’édition absents avant l’instruction. La tentative suivante confirme réellement `Print` avec la signature `2199PTvKyTAfnGRHVaaCceW4u8phdJSu5ULkceD9uJeQyjjenEupK9osRZu1Pzx2NuQaJnAwngSAXMvr5oNtf5y6` au slot `482068400`, puis s’arrête sur la lecture stateful du compte `Edition` compact. `fix-021` corrige cette frontière 41 octets sérialisés / 42 octets alloués, ajoute une régression stateful et préserve `Sync` sur les références de signataires additionnels ; la validation suivante montre toutefois qu'une conversion locale en `Vec<&dyn Signer>` efface encore cette propriété dans l'état du futur Tauri. `Print` et `Burn` restent `not_run` jusqu’à un rerun complet du pipeline de preuve.
|
||||
|
||||
#### Chronologie détaillée de qualification réseau
|
||||
|
||||
Les jalons ci-dessous conservent les décisions et preuves intermédiaires de la seconde moitié de `pre.013`. Ils restent rattachés à cette prerelease afin que le plan ne crée pas une seconde chronologie après les critères de clôture.
|
||||
|
||||
##### Consolidation `pre.013-delta-fix-013`
|
||||
|
||||
La campagne SFT `Create -> Mint` est confirmée avec preuves machine-readable complètes : `Create` signature `2s81m6k9HYDLmCy7oXKaqBvtb62iyX4bJmij2f2VjHuoRQBBA6YqRuAsjyaM7JCaJXasbU3WCfiko91cZcDLLdxV` slot `481908028`, puis `Mint` signature `4pAemhEJewuLAeqLkqwzPvVmsCRbkyLiN6uAUWBA5RMsofaEDt5Xr8YGiBEvLWQM7Qvxnd81mmCHpandmfmWuyAm` slot `481908039`. `Mint` fait passer supply et amount de `0` à `10`, et les deux étapes terminent hydratation canonique, extraction Core, replay, matérialisation et idempotence. La matrice Devnet passe en version 3 afin de conserver un bundle de preuves indépendant par famille ; `Create` et `Mint` sont donc confirmés sur NFT et SFT sans fusionner leurs signatures ou slots. Fungible, collection et pNFT restent les trois variantes `Create -> Mint` à exécuter avant les fixtures spécialisées Print/Burn, collection parent-membre, pNFT, uses et escrow.
|
||||
|
||||
##### Consolidation `pre.013-delta-fix-014`
|
||||
|
||||
La campagne fungible `Create -> Mint` est confirmée avec un mint à 9 décimales : `Create` signature `3J1Ebq9DVkupVFQmqQ84QaNeztwMuRwbtXj7CiyUWwZPj4KCAJpKLAbPvpYss5cdiY33foXXScWWZE98H7tvbZed` slot `481910724`, puis `Mint` signature `2GKiY9foLmioYtUHttA2D6nCSmsftRL1JDKxENHmCnb5w38FGSxwBiRNMfF7mH8htv3G45irmge6DVtr6VN359j2` slot `481910734`. `Mint` fait passer supply et amount de `0` à `1_000_000_000`; les deux étapes terminent le pipeline de preuve complet. La matrice v3 contient désormais des bundles indépendants `nft`, `sft` et `fungible` pour `Create` et `Mint`. Collection et pNFT restent les deux dernières variantes `Create -> Mint` avant le passage aux fixtures spécialisées Print/Burn, collection parent-membre, pNFT lifecycle, uses et escrow.
|
||||
|
||||
##### État après `pre.013-delta-fix-015`
|
||||
|
||||
Les campagnes `Create -> Mint` NFT, SFT, fungible et collection sont maintenant confirmées sur Devnet avec bundles de preuve séparés par famille. Collection valide explicitement metadata + Master Edition, deux snapshots stateful par étape et la transition supply/amount `0 -> 1`. La variante `programmable_nft` est la dernière à exécuter pour fermer ce cycle multi-famille ; elle devra en plus prouver l'apparition du token record après `Mint`. Une fois cette variante qualifiée, le travail `pre.013` bascule vers les fixtures spécialisées collection parent-membre, Print/Burn/éditions, lifecycle pNFT, uses et escrow.
|
||||
|
||||
##### État après `pre.013-delta-fix-016`
|
||||
|
||||
La première tentative `programmable_nft` atteint et confirme `Mint` (`Gkg5A6ehuSzkU1N318kYoRHm5RdxV2yBRpaK9Gwyt6vN1ToYwAS6Vzpk2rQYWS9NJz1rnUpypLCn7DqWFzQzxFc`, slot `481913765`) puis échoue uniquement sur une postcondition SPL commune qui exigeait `Initialized=1`. L’ATA observé possède le mint, l’owner et l’amount exacts mais `state=2`, soit `Frozen`, état attendu pour la couche SPL d’un pNFT. `fix-016` distingue donc l’état SPL par famille et conserve désormais `tokenAccountStateBeforeMint/AfterMint` dans la preuve machine-readable. Le bundle pNFT n’est pas encore promu : un rerun complet doit retourner `ok`, valider le Token Record et démontrer explicitement `Initialized(1) -> Frozen(2)`.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-017`
|
||||
|
||||
- `Create -> Mint` est qualifié sur les cinq familles : NFT, SFT, fungible, collection et pNFT.
|
||||
- `Create` et `Mint` restent les deux seules opérations Metaplex `confirmed`; chacune possède cinq bundles `familyEvidence` complets.
|
||||
- le premier lot spécialisé suivant est la collection parent-membre `Verify -> Unverify`; son runner est préparé mais reste sans preuve réseau tant que le test Devnet opt-in n’a pas terminé `ok`.
|
||||
- la postcondition de collection utilise l’état autoritatif du programme (`verified` et `CollectionDetails::V1.size`) et ne réintroduit pas `SetCollectionSize`.
|
||||
- après qualification de `Verify`/`Unverify`, poursuivre vers les fixtures `Print/Burn`, puis les cycles pNFT delegate/revoke/lock/unlock/transfer, avant uses/escrow/maintenance.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-018`
|
||||
|
||||
La première exécution collection spécialisée atteint et confirme `Verify(CollectionV1)` au slot `481931061`, puis s’arrête pendant le decode replay. L’autorité étant également fee payer, ses privilèges Core globaux sont `signer + writable`; le décodeur exigeait à tort l’égalité locale `signer + readonly`. Le correctif applique à `Verify`/`Unverify` la règle déjà validée pour `Create`/`Mint` : seuls les privilèges requis constituent des minima. Il corrige en outre l’arité de `Unverify` de 8 à 7 positions conformément au wrapper courant.
|
||||
|
||||
Aucune promotion réseau n’est faite à partir de cette preuve partielle. Le prochain jalon reste le rerun intégral `Verify -> Unverify`, avec postconditions membre `false -> true -> false` et taille parent `0 -> 1 -> 0`, avant de passer aux fixtures Print/Burn.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-019`
|
||||
|
||||
Le rerun collection est complètement qualifié : `Verify` (`39JwUoxF2WWYWvEEWzFxSmKZVwoqXD1wH78sgGaoXv2vZKYUsXDNNnKikeuyQcfCqDftEMHSKFDHnTeSQ3bRpFcJ`, slot `481936730`) puis `Unverify` (`4Kfv42BGZtuBEwqTie5RWwdQ772hyxKiU9d3F3gfRnwVNrxCs2iZMvwL17Rwmuyr3XCVoHdaJVgaqCwv8y7bKoZY`, slot `481936742`) terminent le pipeline complet et prouvent `verified false -> true -> false` ainsi que `size 0 -> 1 -> 0`. La matrice Devnet passe à 4 opérations courantes `confirmed` (`Create`, `Mint`, `Verify`, `Unverify`) et 16 `not_run`.
|
||||
|
||||
Le prochain sous-lot est `Print -> Burn` : master NFT imprimable `Limited(1)`, mint d’édition frais, Edition Marker stateful et support explicite d’un signataire supplémentaire déjà déclaré par la requête. La postcondition `Burn` est bornée par la fixture fraîche : supply imprimée `1 -> 0`, master supply `1 -> 0`, fermeture du token account et de l'Edition imprimée, fermeture sémantique de Metadata et fermeture de l’Edition Marker redevenu vide. Les preuves réseau restent fermées : ni `Print` ni `Burn` ne sont promus avant un test Devnet complet. Après cette campagne, poursuivre vers le lifecycle pNFT courant (`Delegate/Revoke/Lock/Unlock/Transfer/Burn` selon les préconditions exactes), puis uses, escrow et opérations de maintenance restantes.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-020`
|
||||
|
||||
La première exécution réelle de `Print -> Burn` s’arrête pendant la simulation exacte de `Print`, avant toute soumission. Le programme retourne `MetadataError::NotEnoughTokens` (`0x20`). Le réaudit du chemin courant identifie la cause dans la fixture `fix-019` : elle précréait le mint d’édition **et son ATA vide**. Or `Print` exige `amount=1` lorsqu’un token account d’édition existe déjà ; lorsqu’ils sont absents, il crée lui-même le mint, crée l’ATA et frappe exactement un token. `fix-020` conserve donc uniquement le keypair signataire frais et exige l’absence on-chain du mint et de l’ATA avant `Print`.
|
||||
|
||||
Le runner valide séparément l’ATA du master à `amount=1` avant simulation afin qu’un défaut de précondition master produise un diagnostic distinct. Il réembarque également le contrat stateful public `EditionMarker` et ajoute une régression d’API externe, car le workspace local ayant reçu `fix-019` contenait le nouveau scénario mais pas ce variant `kb-pipeline`. `Print` et `Burn` restent tous deux `not_run`; la matrice demeure à 4 opérations `confirmed` et 16 `not_run` jusqu’au rerun complet.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-021`
|
||||
|
||||
Le compte `Edition` imprimé est désormais décodé avec les allocations Metaplex bornées : 41 octets sérialisés, 42 octets compacts ou 241 octets historiques avec padding nul. Le rerun franchit alors la validation post-exécution de `Print`, exécute `Burn` et atteint sa dernière postcondition locale. En parallèle, `cargo check --workspace` révèle que la voie multi-signataires reste non-`Send` : le `Signer + Sync` public est effacé dans une `Vec<&dyn Signer>` conservée par le futur. `kb-lib` révèle aussi un seul test `Print` incorrect qui déclare readonly un `edition_token_record` réellement writable.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-022`
|
||||
|
||||
Le prochain rerun part désormais d'un contrat plus exact : la conversion vers `&dyn Signer` est enfermée dans une fonction synchrone de signature, la régression `Print` conserve le writable obligatoire du token record, et la fermeture Metadata n'est plus assimilée à une absence RPC stricte. Pour `MetadataV1`, le programme peut conserver les fees résiduels et laisser un compte d'un octet `0x00` `Uninitialized`; seul ce tombstone exact ou l'absence complète est accepté comme fermeture. Le token account imprimé, l'Edition et l'Edition Marker vide doivent toujours disparaître. `Print` et `Burn` restent `not_run` jusqu'à la sortie complète `METAPLEX_PRINT_BURN_*` avec preuves opérateur.
|
||||
|
||||
##### Consolidation `pre.013-delta-fix-023`
|
||||
|
||||
Le rerun `fix-022` ferme entièrement `Print -> Burn`. `Print` est simulé au slot `482087795`, confirmé par `REHAxUZrSdKDj8F8k27Amrg7hwuJFhVfstjc9xjn2XGfTX38fH4tFwPeNrF5zeMN5pc21PpUPSgaKXMMfTFd7TE` au slot `482087799`, puis `Burn` est simulé au slot `482087813` et confirmé par `4cNUxGGSWifuAtqdPJAtM3Cjpi4JATitRDqrvEAe85NLpMWcgWmC27bsfjNUmK6sEBDovNPtkPV3wDH1LpfGbhd1` au slot `482087818`. `Print` matérialise une instruction et cinq snapshots ; `Burn` une instruction et deux snapshots. Les deux étapes terminent hydratation canonique, extraction Core, replay et seconde passe idempotente. La supply du master suit `0 -> 1 -> 0`, le mint imprimé `0 -> 1 -> 0`, l’Edition et l’Edition Marker sont créés puis fermés, et Metadata termine sous le tombstone fee exact d’un octet `0x00`. La matrice v3 passe donc à 6 opérations `confirmed` et 14 `not_run`.
|
||||
|
||||
Le lot prépare ensuite un parcours pNFT unique et cohérent couvrant cinq opérations encore non qualifiées : `Delegate(StakingV1) -> Lock -> Unlock -> Revoke(StakingV1) -> Delegate(TransferV1) -> Transfer`. Le premier delegate prouve le cycle de lock du Token Record ; le second prouve le transfert délégué vers une ATA et un Token Record destination frais. Le transfert doit vider l’ATA source, remplir l’ATA destination, conserver les comptes SPL pNFT gelés et supprimer la délégation sur le Token Record destination. Aucun Rule Set n’est fabriqué artificiellement : la fixture pNFT sans rule set suffit pour qualifier les wrappers et les transitions de délégation. `Migrate` reste séparé car il concerne la conversion d’un actif legacy vers pNFT et ne peut pas être exercé sur cette fixture déjà programmable.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-029`
|
||||
|
||||
Le cycle pNFT est maintenant qualifié avec six preuves transactionnelles complètes : deux variantes `Delegate` (`StakingV1`, `TransferV1`) et les opérations `Lock`, `Unlock`, `Revoke`, `Transfer`. Les cinq opérations canoniques correspondantes passent à `confirmed` sur `programmable_nft`. Avec `Create`, `Mint`, `Verify`, `Unverify`, `Print` et `Burn`, la matrice compte désormais **11/20 opérations confirmées**, **1 `unavailable` (`Use`)** et **8 `not_run`**.
|
||||
|
||||
Le probe `Use` est désormais exécuté et classé : Devnet rejette l’instruction courante de discriminant 51 avec `InvalidInstructionData`, aucune transaction n’est soumise et l’opération passe à `unavailable`. Le SDK et le runtime restent donc explicitement divergents sur cette surface. `Migrate` est par ailleurs explicitement `Removed` dans le routeur courant et devra être classé avec la même discipline de preuve.
|
||||
|
||||
Le prochain jalon est le graphe escrow (`CreateEscrowAccount -> TransferOutOfEscrow -> CloseEscrowAccount`) avec un NFT contrôlé, un Token Owned Escrow et un token attribut SPL contrôlé. Ensuite réconcilier `Update`, `Collect`, `Resize`, `CloseAccounts` et `Migrate` avec leur disponibilité réelle avant consolidation de `pre.013`.
|
||||
|
||||
##### Avancement `pre.013-delta-fix-033`
|
||||
|
||||
Token Owned Escrow est entièrement qualifié sur Devnet. Les trois transactions Metaplex `CreateEscrowAccount`, `TransferOutOfEscrow`, `CloseEscrowAccount` sont confirmées avec replay et matérialisation complets ; l’unité SPL déposée dans l’ATA du PDA revient exactement à l’opérateur, l’ATA vide est fermée, puis l’escrow est fermé sans modifier le NFT parent. La matrice est désormais à **14 `confirmed`, 1 `unavailable`, 5 `not_run`**.
|
||||
|
||||
La première tentative de la dernière campagne montre que les créations actuelles sont déjà au layout cible : après un `Update` validé en interne, `Resize` atteint `IX: Resize` mais la simulation retourne `AlreadyResized(201)` et aucune soumission n’a lieu. Une réussite positive exigerait un compte legacy sous-dimensionné contrôlé, non constructible par la fixture courante. `Resize` passe donc à `unavailable`, portant la matrice à **14 `confirmed`, 2 `unavailable`, 4 `not_run`**.
|
||||
|
||||
Le rerun final soumet uniquement `Update`. `Resize`, `Migrate`, `Collect` et `CloseAccounts` sont des probes simulation-only, avec refus attendus `AlreadyResized(201)`, `Removed(75)`, `UpdateAuthorityIncorrect(7)` et `InvalidCloseAuthority(188)`. Si le bundle est conforme, la matrice pourra se fermer à **15 `confirmed`, 5 `unavailable`, 0 `not_run`** puis passer à la consolidation finale de `pre.013`.
|
||||
|
||||
##### Clôture de la matrice Metaplex `pre.013-delta-fix-036`
|
||||
|
||||
La dernière campagne maintenance est qualifiée. `Update` passe à `confirmed` sur NFT et les probes `Resize`, `Migrate`, `Collect`, `CloseAccounts` produisent exactement les refus runtime attendus sans soumission. Avec `Use` déjà classé, la matrice des 20 opérations courantes atteint **15 `confirmed`, 5 `unavailable`, 0 `not_run`**.
|
||||
|
||||
Les cinq indisponibilités sont distinctes et ne doivent pas être amalgamées : `Use` diverge du SDK courant sur Devnet ; `Resize` exige un compte legacy sous-dimensionné contrôlé ; `Migrate` est retiré du runtime ; `Collect` et `CloseAccounts` exigent des autorités Metaplex fixes hors du profil opérateur contrôlé.
|
||||
|
||||
Le prochain delta de `pre.013` doit être une **consolidation**, pas une nouvelle campagne fonctionnelle : audit des statuts finaux, réconciliation des rapports/TODO/changelogs et vérification que toutes les matrices et guides reflètent 0 ligne `not_run`. Après cette consolidation et les tests de conformité locaux, le développement peut passer à `0.4.8-pre.014`.
|
||||
|
||||
#### Clôture de `pre.013`
|
||||
|
||||
La consolidation suivant `fix-036` confirme que la matrice Metaplex est intégralement classée et que les contrôles locaux sont propres : formatage, `cargo check --workspace`, Clippy sans warning, audit workspace, puis 105 tests unitaires + 1 CLI + 1 API externe de `kb-pipeline-demo-scenarios`. Les guides et TODO actifs sont réconciliés avec cet état. `pre.014` peut donc commencer directement sur la finalisation desktop metadata ; aucune nouvelle campagne Metaplex fondamentale n'est attendue sauf régression observée.
|
||||
|
||||
### `0.4.8-pre.014` — finalisation desktop metadata
|
||||
### `0.4.8-pre.014` — finalisation desktop Metadata — terminée et validée
|
||||
|
||||
- compléter le sous-panneau Token-2022 après les travaux de `pre.011` et `pre.012` et intégrer les éventuels compléments Metaplex de `pre.013` ;
|
||||
- conserver des accordéons ou sous-panneaux séparés pour `ProgM6…`, Token-2022 et Metaplex ;
|
||||
Objectif : réunir dans `demo_execution_metadata` les trois domaines Metadata sans dupliquer les orchestrations réseau déjà qualifiées, tout en conservant des frontières UI et des modules desktop explicites.
|
||||
|
||||
- compléter le sous-panneau Token-2022 après `pre.011` et `pre.012` ;
|
||||
- intégrer les campagnes Metaplex qualifiées de `pre.013` plutôt qu’un parcours Devnet générique incomplet ;
|
||||
- conserver des accordéons distincts pour `ProgM6…`, Token-2022 et Metaplex ;
|
||||
- réutiliser le JsonViewer commun pour les résultats intégralement JSON ;
|
||||
- réconcilier préparation, simulation, soumission, lectures et preuves des trois domaines ;
|
||||
- aucun bouton de fetch URI.
|
||||
- ne fournir aucun bouton de fetch URI.
|
||||
|
||||
#### `pre.014-delta` — ouverture du jalon
|
||||
|
||||
Le workspace passe à `0.4.8-pre.14` tandis que `package.json` et `tauri.conf.json` restent à `0.4.8`. Token-2022 Token Metadata est ajouté au panneau en appelant directement `execute_devnet_token_2022_metadata_campaign`. Les trois domaines partagent le profil Devnet préparé et les trois JsonViewer communs. Le journal d’exécution est sorti de la grille `5/7` et occupe toute la largeur du `container-fluid`.
|
||||
|
||||
La validation Tauri réelle confirme ensuite les campagnes desktop Token-2022 Token Metadata et Solana Program Metadata sur Devnet.
|
||||
|
||||
#### `pre.014-delta-fix-001` — campagnes Metaplex qualifiées
|
||||
|
||||
L’ancien chemin Metaplex `scénario -> étape -> intent JSON` s’arrêtait après la préparation de fixture et ne lançait aucune campagne spécialisée. Le parcours Devnet principal est remplacé par onze campagnes réutilisables : cinq `Create -> Mint`, collection `Verify -> Unverify`, `Print -> Burn`, lifecycle pNFT, Token Owned Escrow, maintenance et probe Use. Les opérations `unavailable` restent confinées aux probes simulation-only et ne deviennent jamais des soumissions isolées. La carte **Exigences** est déplacée en bas de la colonne droite.
|
||||
|
||||
#### `pre.014-delta-fix-002` — stabilité du dispatch et validation réseau desktop
|
||||
|
||||
Deux essais initiaux de `Create -> Mint — NFT` montrent un arrêt brutal après confirmation de `Create`, pendant l’hydratation canonique. Le dispatch des onze campagnes est ensuite boxé avant son attente par Tauri et reçoit des marqueurs `campaign_start`, `campaign_completed` et `campaign_failed`. Le test historique des contrôles frontend est réaligné sur la nouvelle UI.
|
||||
|
||||
Le rerun du 9 août 2026 ferme cette régression : les onze campagnes Metaplex atteignent toutes `campaign_completed`, sans `campaign_failed` ni fichier `error*.jsonl` non vide. Maintenance conserve `3 confirmed / 4 unavailable` et Use `2 confirmed / 1 unavailable`, conformément aux qualifications de `pre.013`. Les 144 tests desktop sont verts.
|
||||
|
||||
#### `pre.014-delta-fix-003` — consolidation structurelle et UX
|
||||
|
||||
Les deux modules Metaplex desktop sont fusionnés dans `demo_execution_metadata_metaplex_token_metadata.rs`, afin de suivre le même modèle de module unique que Token-2022 Token Metadata et Solana Program Metadata. Les commandes Tauri et les contrats TS-RS restent inchangés.
|
||||
|
||||
Les blocs **Préflight et opérations**, **Simulation et confirmation** et **Postconditions et preuves** deviennent trois accordéons Bootstrap utilisant les JsonViewer existants. **Exigences** reste sous ces résultats et le journal reste en pleine largeur.
|
||||
|
||||
La validation finale confirme `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, l’audit workspace et les 144 tests desktop. La disposition est également validée visuellement dans Tauri. `pre.014` est clôturée ; aucune nouvelle campagne Devnet n’est requise avant `pre.015`.
|
||||
|
||||
### `0.4.8-pre.015` — stockage, matrices et réconciliation transversale
|
||||
|
||||
- stockage si de nouveaux contrats persistants sont requis ;
|
||||
- exports, registres, matrices, nomenclature IDL et guides ;
|
||||
- retrait des statuts `reserved` uniquement lorsque l’implémentation correspondante est réelle.
|
||||
Objectif : réconcilier les trois surfaces Metadata désormais implémentées et validées avant la clôture documentaire de `pre.016`, sans ouvrir de nouvelle capacité réseau.
|
||||
|
||||
- auditer d’abord les besoins de stockage réellement introduits par Solana Program Metadata, Token-2022 Token Metadata et Metaplex Token Metadata ; ne modifier le schéma que si un contrat persistant manque effectivement ;
|
||||
- recouper les matrices de comptes, instructions, exécution, pipeline et validation Devnet avec les inventaires compilés ;
|
||||
- vérifier les registres runtime de décodeurs et matérialiseurs, les exports publics et les tests d’API externe ;
|
||||
- réconcilier `docs/IDL_AUDIT.md`, `docs/IDL_TO_KB_LIB_NOMENCLATURE.md` et les statuts `reserved` avec l’implémentation réelle ;
|
||||
- vérifier README, USAGE, TODO et changelogs des crates concernées uniquement lorsque leur état courant est faux ou incomplet ;
|
||||
- conserver les preuves Devnet existantes comme références : aucune nouvelle campagne réseau n’est requise sauf régression détectée par la réconciliation.
|
||||
|
||||
Critère : aucune divergence non expliquée entre code, matrices, registres, IDL, stockage et documentation active ; les éventuelles dettes restantes sont explicitement reportées avant `pre.016`.
|
||||
|
||||
### `0.4.8-pre.016` — clôture obligatoire
|
||||
|
||||
@@ -427,83 +545,3 @@ python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
### Consolidation `pre.013-delta-fix-013`
|
||||
|
||||
La campagne SFT `Create -> Mint` est confirmée avec preuves machine-readable complètes : `Create` signature `2s81m6k9HYDLmCy7oXKaqBvtb62iyX4bJmij2f2VjHuoRQBBA6YqRuAsjyaM7JCaJXasbU3WCfiko91cZcDLLdxV` slot `481908028`, puis `Mint` signature `4pAemhEJewuLAeqLkqwzPvVmsCRbkyLiN6uAUWBA5RMsofaEDt5Xr8YGiBEvLWQM7Qvxnd81mmCHpandmfmWuyAm` slot `481908039`. `Mint` fait passer supply et amount de `0` à `10`, et les deux étapes terminent hydratation canonique, extraction Core, replay, matérialisation et idempotence. La matrice Devnet passe en version 3 afin de conserver un bundle de preuves indépendant par famille ; `Create` et `Mint` sont donc confirmés sur NFT et SFT sans fusionner leurs signatures ou slots. Fungible, collection et pNFT restent les trois variantes `Create -> Mint` à exécuter avant les fixtures spécialisées Print/Burn, collection parent-membre, pNFT, uses et escrow.
|
||||
|
||||
### Consolidation `pre.013-delta-fix-014`
|
||||
|
||||
La campagne fungible `Create -> Mint` est confirmée avec un mint à 9 décimales : `Create` signature `3J1Ebq9DVkupVFQmqQ84QaNeztwMuRwbtXj7CiyUWwZPj4KCAJpKLAbPvpYss5cdiY33foXXScWWZE98H7tvbZed` slot `481910724`, puis `Mint` signature `2GKiY9foLmioYtUHttA2D6nCSmsftRL1JDKxENHmCnb5w38FGSxwBiRNMfF7mH8htv3G45irmge6DVtr6VN359j2` slot `481910734`. `Mint` fait passer supply et amount de `0` à `1_000_000_000`; les deux étapes terminent le pipeline de preuve complet. La matrice v3 contient désormais des bundles indépendants `nft`, `sft` et `fungible` pour `Create` et `Mint`. Collection et pNFT restent les deux dernières variantes `Create -> Mint` avant le passage aux fixtures spécialisées Print/Burn, collection parent-membre, pNFT lifecycle, uses et escrow.
|
||||
|
||||
### État après `pre.013-delta-fix-015`
|
||||
|
||||
Les campagnes `Create -> Mint` NFT, SFT, fungible et collection sont maintenant confirmées sur Devnet avec bundles de preuve séparés par famille. Collection valide explicitement metadata + Master Edition, deux snapshots stateful par étape et la transition supply/amount `0 -> 1`. La variante `programmable_nft` est la dernière à exécuter pour fermer ce cycle multi-famille ; elle devra en plus prouver l'apparition du token record après `Mint`. Une fois cette variante qualifiée, le travail `pre.013` bascule vers les fixtures spécialisées collection parent-membre, Print/Burn/éditions, lifecycle pNFT, uses et escrow.
|
||||
|
||||
### État après `pre.013-delta-fix-016`
|
||||
|
||||
La première tentative `programmable_nft` atteint et confirme `Mint` (`Gkg5A6ehuSzkU1N318kYoRHm5RdxV2yBRpaK9Gwyt6vN1ToYwAS6Vzpk2rQYWS9NJz1rnUpypLCn7DqWFzQzxFc`, slot `481913765`) puis échoue uniquement sur une postcondition SPL commune qui exigeait `Initialized=1`. L’ATA observé possède le mint, l’owner et l’amount exacts mais `state=2`, soit `Frozen`, état attendu pour la couche SPL d’un pNFT. `fix-016` distingue donc l’état SPL par famille et conserve désormais `tokenAccountStateBeforeMint/AfterMint` dans la preuve machine-readable. Le bundle pNFT n’est pas encore promu : un rerun complet doit retourner `ok`, valider le Token Record et démontrer explicitement `Initialized(1) -> Frozen(2)`.
|
||||
|
||||
## Avancement `pre.013-delta-fix-017`
|
||||
|
||||
- `Create -> Mint` est qualifié sur les cinq familles : NFT, SFT, fungible, collection et pNFT.
|
||||
- `Create` et `Mint` restent les deux seules opérations Metaplex `confirmed`; chacune possède cinq bundles `familyEvidence` complets.
|
||||
- le premier lot spécialisé suivant est la collection parent-membre `Verify -> Unverify`; son runner est préparé mais reste sans preuve réseau tant que le test Devnet opt-in n’a pas terminé `ok`.
|
||||
- la postcondition de collection utilise l’état autoritatif du programme (`verified` et `CollectionDetails::V1.size`) et ne réintroduit pas `SetCollectionSize`.
|
||||
- après qualification de `Verify`/`Unverify`, poursuivre vers les fixtures `Print/Burn`, puis les cycles pNFT delegate/revoke/lock/unlock/transfer, avant uses/escrow/maintenance.
|
||||
|
||||
### Avancement `pre.013-delta-fix-018`
|
||||
|
||||
La première exécution collection spécialisée atteint et confirme `Verify(CollectionV1)` au slot `481931061`, puis s’arrête pendant le decode replay. L’autorité étant également fee payer, ses privilèges Core globaux sont `signer + writable`; le décodeur exigeait à tort l’égalité locale `signer + readonly`. Le correctif applique à `Verify`/`Unverify` la règle déjà validée pour `Create`/`Mint` : seuls les privilèges requis constituent des minima. Il corrige en outre l’arité de `Unverify` de 8 à 7 positions conformément au wrapper courant.
|
||||
|
||||
Aucune promotion réseau n’est faite à partir de cette preuve partielle. Le prochain jalon reste le rerun intégral `Verify -> Unverify`, avec postconditions membre `false -> true -> false` et taille parent `0 -> 1 -> 0`, avant de passer aux fixtures Print/Burn.
|
||||
|
||||
### Avancement `pre.013-delta-fix-019`
|
||||
|
||||
Le rerun collection est complètement qualifié : `Verify` (`39JwUoxF2WWYWvEEWzFxSmKZVwoqXD1wH78sgGaoXv2vZKYUsXDNNnKikeuyQcfCqDftEMHSKFDHnTeSQ3bRpFcJ`, slot `481936730`) puis `Unverify` (`4Kfv42BGZtuBEwqTie5RWwdQ772hyxKiU9d3F3gfRnwVNrxCs2iZMvwL17Rwmuyr3XCVoHdaJVgaqCwv8y7bKoZY`, slot `481936742`) terminent le pipeline complet et prouvent `verified false -> true -> false` ainsi que `size 0 -> 1 -> 0`. La matrice Devnet passe à 4 opérations courantes `confirmed` (`Create`, `Mint`, `Verify`, `Unverify`) et 16 `not_run`.
|
||||
|
||||
Le prochain sous-lot est `Print -> Burn` : master NFT imprimable `Limited(1)`, mint d’édition frais, Edition Marker stateful et support explicite d’un signataire supplémentaire déjà déclaré par la requête. La postcondition `Burn` est bornée par la fixture fraîche : supply imprimée `1 -> 0`, master supply `1 -> 0`, fermeture du token account et de l'Edition imprimée, fermeture sémantique de Metadata et fermeture de l’Edition Marker redevenu vide. Les preuves réseau restent fermées : ni `Print` ni `Burn` ne sont promus avant un test Devnet complet. Après cette campagne, poursuivre vers le lifecycle pNFT courant (`Delegate/Revoke/Lock/Unlock/Transfer/Burn` selon les préconditions exactes), puis uses, escrow et opérations de maintenance restantes.
|
||||
|
||||
### Avancement `pre.013-delta-fix-020`
|
||||
|
||||
La première exécution réelle de `Print -> Burn` s’arrête pendant la simulation exacte de `Print`, avant toute soumission. Le programme retourne `MetadataError::NotEnoughTokens` (`0x20`). Le réaudit du chemin courant identifie la cause dans la fixture `fix-019` : elle précréait le mint d’édition **et son ATA vide**. Or `Print` exige `amount=1` lorsqu’un token account d’édition existe déjà ; lorsqu’ils sont absents, il crée lui-même le mint, crée l’ATA et frappe exactement un token. `fix-020` conserve donc uniquement le keypair signataire frais et exige l’absence on-chain du mint et de l’ATA avant `Print`.
|
||||
|
||||
Le runner valide séparément l’ATA du master à `amount=1` avant simulation afin qu’un défaut de précondition master produise un diagnostic distinct. Il réembarque également le contrat stateful public `EditionMarker` et ajoute une régression d’API externe, car le workspace local ayant reçu `fix-019` contenait le nouveau scénario mais pas ce variant `kb-pipeline`. `Print` et `Burn` restent tous deux `not_run`; la matrice demeure à 4 opérations `confirmed` et 16 `not_run` jusqu’au rerun complet.
|
||||
|
||||
### Avancement `pre.013-delta-fix-021`
|
||||
|
||||
Le compte `Edition` imprimé est désormais décodé avec les allocations Metaplex bornées : 41 octets sérialisés, 42 octets compacts ou 241 octets historiques avec padding nul. Le rerun franchit alors la validation post-exécution de `Print`, exécute `Burn` et atteint sa dernière postcondition locale. En parallèle, `cargo check --workspace` révèle que la voie multi-signataires reste non-`Send` : le `Signer + Sync` public est effacé dans une `Vec<&dyn Signer>` conservée par le futur. `kb-lib` révèle aussi un seul test `Print` incorrect qui déclare readonly un `edition_token_record` réellement writable.
|
||||
|
||||
### Avancement `pre.013-delta-fix-022`
|
||||
|
||||
Le prochain rerun part désormais d'un contrat plus exact : la conversion vers `&dyn Signer` est enfermée dans une fonction synchrone de signature, la régression `Print` conserve le writable obligatoire du token record, et la fermeture Metadata n'est plus assimilée à une absence RPC stricte. Pour `MetadataV1`, le programme peut conserver les fees résiduels et laisser un compte d'un octet `0x00` `Uninitialized`; seul ce tombstone exact ou l'absence complète est accepté comme fermeture. Le token account imprimé, l'Edition et l'Edition Marker vide doivent toujours disparaître. `Print` et `Burn` restent `not_run` jusqu'à la sortie complète `METAPLEX_PRINT_BURN_*` avec preuves opérateur.
|
||||
|
||||
## Consolidation `pre.013-delta-fix-023`
|
||||
|
||||
Le rerun `fix-022` ferme entièrement `Print -> Burn`. `Print` est simulé au slot `482087795`, confirmé par `REHAxUZrSdKDj8F8k27Amrg7hwuJFhVfstjc9xjn2XGfTX38fH4tFwPeNrF5zeMN5pc21PpUPSgaKXMMfTFd7TE` au slot `482087799`, puis `Burn` est simulé au slot `482087813` et confirmé par `4cNUxGGSWifuAtqdPJAtM3Cjpi4JATitRDqrvEAe85NLpMWcgWmC27bsfjNUmK6sEBDovNPtkPV3wDH1LpfGbhd1` au slot `482087818`. `Print` matérialise une instruction et cinq snapshots ; `Burn` une instruction et deux snapshots. Les deux étapes terminent hydratation canonique, extraction Core, replay et seconde passe idempotente. La supply du master suit `0 -> 1 -> 0`, le mint imprimé `0 -> 1 -> 0`, l’Edition et l’Edition Marker sont créés puis fermés, et Metadata termine sous le tombstone fee exact d’un octet `0x00`. La matrice v3 passe donc à 6 opérations `confirmed` et 14 `not_run`.
|
||||
|
||||
Le lot prépare ensuite un parcours pNFT unique et cohérent couvrant cinq opérations encore non qualifiées : `Delegate(StakingV1) -> Lock -> Unlock -> Revoke(StakingV1) -> Delegate(TransferV1) -> Transfer`. Le premier delegate prouve le cycle de lock du Token Record ; le second prouve le transfert délégué vers une ATA et un Token Record destination frais. Le transfert doit vider l’ATA source, remplir l’ATA destination, conserver les comptes SPL pNFT gelés et supprimer la délégation sur le Token Record destination. Aucun Rule Set n’est fabriqué artificiellement : la fixture pNFT sans rule set suffit pour qualifier les wrappers et les transitions de délégation. `Migrate` reste séparé car il concerne la conversion d’un actif legacy vers pNFT et ne peut pas être exercé sur cette fixture déjà programmable.
|
||||
|
||||
### Avancement `pre.013-delta-fix-029`
|
||||
|
||||
Le cycle pNFT est maintenant qualifié avec six preuves transactionnelles complètes : deux variantes `Delegate` (`StakingV1`, `TransferV1`) et les opérations `Lock`, `Unlock`, `Revoke`, `Transfer`. Les cinq opérations canoniques correspondantes passent à `confirmed` sur `programmable_nft`. Avec `Create`, `Mint`, `Verify`, `Unverify`, `Print` et `Burn`, la matrice compte désormais **11/20 opérations confirmées**, **1 `unavailable` (`Use`)** et **8 `not_run`**.
|
||||
|
||||
Le probe `Use` est désormais exécuté et classé : Devnet rejette l’instruction courante de discriminant 51 avec `InvalidInstructionData`, aucune transaction n’est soumise et l’opération passe à `unavailable`. Le SDK et le runtime restent donc explicitement divergents sur cette surface. `Migrate` est par ailleurs explicitement `Removed` dans le routeur courant et devra être classé avec la même discipline de preuve.
|
||||
|
||||
Le prochain jalon est le graphe escrow (`CreateEscrowAccount -> TransferOutOfEscrow -> CloseEscrowAccount`) avec un NFT contrôlé, un Token Owned Escrow et un token attribut SPL contrôlé. Ensuite réconcilier `Update`, `Collect`, `Resize`, `CloseAccounts` et `Migrate` avec leur disponibilité réelle avant consolidation de `pre.013`.
|
||||
|
||||
### Avancement `pre.013-delta-fix-033`
|
||||
|
||||
Token Owned Escrow est entièrement qualifié sur Devnet. Les trois transactions Metaplex `CreateEscrowAccount`, `TransferOutOfEscrow`, `CloseEscrowAccount` sont confirmées avec replay et matérialisation complets ; l’unité SPL déposée dans l’ATA du PDA revient exactement à l’opérateur, l’ATA vide est fermée, puis l’escrow est fermé sans modifier le NFT parent. La matrice est désormais à **14 `confirmed`, 1 `unavailable`, 5 `not_run`**.
|
||||
|
||||
La première tentative de la dernière campagne montre que les créations actuelles sont déjà au layout cible : après un `Update` validé en interne, `Resize` atteint `IX: Resize` mais la simulation retourne `AlreadyResized(201)` et aucune soumission n’a lieu. Une réussite positive exigerait un compte legacy sous-dimensionné contrôlé, non constructible par la fixture courante. `Resize` passe donc à `unavailable`, portant la matrice à **14 `confirmed`, 2 `unavailable`, 4 `not_run`**.
|
||||
|
||||
Le rerun final soumet uniquement `Update`. `Resize`, `Migrate`, `Collect` et `CloseAccounts` sont des probes simulation-only, avec refus attendus `AlreadyResized(201)`, `Removed(75)`, `UpdateAuthorityIncorrect(7)` et `InvalidCloseAuthority(188)`. Si le bundle est conforme, la matrice pourra se fermer à **15 `confirmed`, 5 `unavailable`, 0 `not_run`** puis passer à la consolidation finale de `pre.013`.
|
||||
|
||||
### Clôture de la matrice Metaplex `pre.013-delta-fix-036`
|
||||
|
||||
La dernière campagne maintenance est qualifiée. `Update` passe à `confirmed` sur NFT et les probes `Resize`, `Migrate`, `Collect`, `CloseAccounts` produisent exactement les refus runtime attendus sans soumission. Avec `Use` déjà classé, la matrice des 20 opérations courantes atteint **15 `confirmed`, 5 `unavailable`, 0 `not_run`**.
|
||||
|
||||
Les cinq indisponibilités sont distinctes et ne doivent pas être amalgamées : `Use` diverge du SDK courant sur Devnet ; `Resize` exige un compte legacy sous-dimensionné contrôlé ; `Migrate` est retiré du runtime ; `Collect` et `CloseAccounts` exigent des autorités Metaplex fixes hors du profil opérateur contrôlé.
|
||||
|
||||
Le prochain delta de `pre.013` doit être une **consolidation**, pas une nouvelle campagne fonctionnelle : audit des statuts finaux, réconciliation des rapports/TODO/changelogs et vérification que toutes les matrices et guides reflètent 0 ligne `not_run`. Après cette consolidation et les tests de conformité locaux, le développement peut passer à `0.4.8-pre.014`.
|
||||
|
||||
Reference in New Issue
Block a user