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`.
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
<!-- file: docs/validation/V0_4_8_PRE_014_DESKTOP_METADATA_VALIDATION_REPORT.md -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Validation desktop Metadata `0.4.8-pre.014`
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce rapport consolide la première validation réelle du panneau `demo_execution_metadata` après l’ouverture de `0.4.8-pre.014`, puis motive le correctif de câblage Metaplex du delta suivant.
|
||||
|
||||
Il ne remplace pas les matrices réseau spécialisées. Il qualifie uniquement l’intégration desktop et la correspondance entre l’UI Tauri et les campagnes réutilisables déjà validées.
|
||||
|
||||
## 2. Contrôles locaux
|
||||
|
||||
Le 8 août 2026, après application du premier delta `pre.014`, les contrôles suivants réussissent :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-pipeline-demo-scenarios 105 unitaires + 1 CLI + 1 API externe
|
||||
kb-app-demo-desktop 139 unitaires
|
||||
cargo tauri dev démarrage OK
|
||||
```
|
||||
|
||||
La validation visuelle confirme :
|
||||
|
||||
- trois accordéons distincts pour Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata ;
|
||||
- synchronisation du profil sélectionné entre les trois domaines ;
|
||||
- journal d’exécution placé sous la grille et utilisant toute la largeur disponible.
|
||||
|
||||
## 3. Token-2022 Token Metadata
|
||||
|
||||
Les logs fournis montrent une campagne desktop complète sur Devnet, sans entrée dans les fichiers `error*.jsonl`.
|
||||
|
||||
| Opération | Signature | Slot |
|
||||
|-------------------|--------------------------------------------------------------------------------------------|------------:|
|
||||
| `Initialize` | `23aXutFc25Ncn4XPSGdaaEzvUpe9s57gYunmMq1asmFRK9xe1tAYVCnV3dePUn2a7qqq51JDsPKp5ep5d1DLypNv` | `482188064` |
|
||||
| `UpdateField` | `Uws9Laene33LxYet4562LKXMkKjAhW5FPweQSnFJv7NG6s4u7LqB7zbppQgQgaNFE52d9UVZKLmjZoK9zb4xdHK` | `482188079` |
|
||||
| `Emit` | `2uNggBbSvvj7Cqdddt1KtFgFhTJ9jsyvobeGUaAU6kPNY9o4hJ6BVHEhpELe1sRSyrMrgbeGLoRiWAMU2UrisMcE` | `482188091` |
|
||||
| `RemoveKey` | `3xUUnjQvWzSkMQPe2VFDyYX14K3STxBzFjzWEawrK28UsoJzXTPYA61nzkL5JvLwCfhNRg7YpBcsSSjhTJqtqNYT` | `482188102` |
|
||||
| `UpdateAuthority` | `2U9zrLL9NusrhpW9Dx15SqZ8c4d6zbcgSyM4hBcewr1Ar7JwLYwvBduLKs4HKEgZP9i5YQQ9cyTC977mjJGLWqXW` | `482188113` |
|
||||
|
||||
Les traces `kb-pipeline` et `kb-lib` montrent le décodage Token-2022, la matérialisation `materializer.metadata.token_2022` et la seconde passe de replay/idempotence. La fixture a été préparée auparavant par la signature `LNwzGfvCgZdumbYXfAecCxU6hfHYGa6XRwC7E71jc4JTDUj5QyVBVV5Sd9KLWmX2t72XfKBiYUEV6WYCvPqC4wd`, slot `482188053`.
|
||||
|
||||
**Statut desktop : validé.**
|
||||
|
||||
## 4. Solana Program Metadata
|
||||
|
||||
La campagne desktop `ProgM6…` traverse les deux parcours complets après préparation des PDA frais `buffer=6bs5XpPsNUqw8FatFJTJu81ZAUBCvxmyxptNyUY4RnDU` et `metadata=7fTTM3KCtFMjxmTaWa6xJ3nSbK9Yi7MdVXP3dSa8ahPB`.
|
||||
|
||||
Les neuf opérations atteignent toutes l’état `Confirmed` dans les contrôles post-exécution :
|
||||
|
||||
```text
|
||||
Buffer : Allocate -> Extend -> Write -> SetAuthority -> Trim -> Close
|
||||
Metadata : Initialize -> SetData -> SetImmutable
|
||||
```
|
||||
|
||||
Signatures observées :
|
||||
|
||||
```text
|
||||
Allocate Je6SLx7wfNqEJ8Huo64r177Sm9bda4uFXUPwuxfZG89jvb1zKMKLnzTJEL5DFHxftMq38FsLNF3TZ14kaWSZ7Hb
|
||||
Extend LYgf8ac4CKYdY2xkw9bCS8J9cvkphWA8ueCUJ5CBKZ11jEdS2NZLykF4jwmSA5AnVYWxzNABeXhGV4d1dFvzMnM
|
||||
Write 4p7XEXeGgWQjJkWTfrBB5rL9XwDadxzoCPreLfaB3fBGACyrPqZYmnBGqVYVgyR9zDZNxuKhimEwMtmiGdJseKa2
|
||||
SetAuthority 5kPi3eBqbq92kV5ZFWPur9afAokGxhgr84PPQh7s5btyQYayC3TDuaH9TCcspxbd4YEYDD4icFYnSWX2Ej9XdLgA
|
||||
Trim 5YG7Yp6x1waZZKoRjb37q7QUNJL5CMEUgu8gs7ehDwHUx1TXvV5BaeUJFT1Pb58z4hSo4woey2qaKQggAzaNtYEG
|
||||
Close 2jyZzegSM2v7LJ15nF3r9zXsLXd7ZDsWsCEWHLXQdoBrLkrbuSuwVrGx1jTqYejw195FVhWHeJQYY6BaN98s5R6
|
||||
Initialize 2kzvpRi8KwRhaQPiwtR8PCQGTuQ3e3kUNSi7EVsMXqJzhQkZanjNwxsL2sGeB8Xs56N22TaaYbS6LJimQpHZWk6J
|
||||
SetData 3WZHzYno9M6uHLMiXsNBtBHoN3yAp7ftd3pSNWpuj2jATk1g29nvUccgUu6wuRijv9oBo2Vi1dHKury2DFfDQ1ib
|
||||
SetImmutable XTAj5NNVXRkhKe4DxsXGm2xtxocrwHwkkpEun4ib6h4qs6DX5f2K6gfgQ2jppkTWoC83MyoPgrpvdKes1b72gbJ
|
||||
```
|
||||
|
||||
**Statut desktop : validé.**
|
||||
|
||||
## 5. Metaplex Token Metadata : écart constaté
|
||||
|
||||
Les logs de la même session ne montrent pas une campagne Metaplex spécialisée. Le desktop prépare uniquement une fixture classique avec :
|
||||
|
||||
```text
|
||||
operation = metadata.metaplex_token_metadata.prepare_native_mint_and_ata
|
||||
signature = 5YdSQHZ5T3VV8zefmQS4GVHNXPbvCijiLyHdgwvqcmGMMpobAJcM4HvdeQ7vex9qDqcYtAVUtj4U3bDCeQ2Hfzvv
|
||||
slot = 482188642
|
||||
```
|
||||
|
||||
Aucune séquence qualifiée `Create -> Mint`, collection, Print/Burn, lifecycle pNFT, escrow, maintenance ou Use ne suit cette préparation avant la fin des logs.
|
||||
|
||||
La cause est un écart de câblage desktop : le panneau utilisait encore le workflow générique `scénario -> étape -> intent JSON`, alors que `pre.013` a qualifié des campagnes spécialisées cohérentes et indivisibles.
|
||||
|
||||
## 6. Correctif `pre.014-delta-fix-001`
|
||||
|
||||
Le correctif conserve les scénarios synthétiques pour l’inspection de contrats mais remplace le parcours Devnet principal par 11 campagnes spécialisées :
|
||||
|
||||
1. `Create -> Mint` NFT ;
|
||||
2. `Create -> Mint` SFT ;
|
||||
3. `Create -> Mint` fungible ;
|
||||
4. `Create -> Mint` collection ;
|
||||
5. `Create -> Mint` pNFT ;
|
||||
6. collection `Verify -> Unverify` ;
|
||||
7. `Print -> Burn` ;
|
||||
8. lifecycle pNFT ;
|
||||
9. Token Owned Escrow ;
|
||||
10. maintenance ;
|
||||
11. probe Use.
|
||||
|
||||
Maintenance et Use conservent les opérations `unavailable` comme probes simulation-only ; elles ne sont pas converties en soumissions isolées.
|
||||
|
||||
La carte **Exigences** est également déplacée en bas de la colonne droite, après **Postconditions et preuves**. Le journal reste en pleine largeur sous la grille.
|
||||
|
||||
## 7. Validation de `fix-001`
|
||||
|
||||
Après application de `fix-001` :
|
||||
|
||||
- les 11 campagnes Metaplex sont bien exposées par le nouveau contrat desktop ;
|
||||
- les contrôles statiques `fmt`, `check`, Clippy et audit workspace sont propres ;
|
||||
- `kb-pipeline-demo-scenarios` conserve 105 tests unitaires + 1 CLI + 1 API externe réussis ;
|
||||
- `kb-app-demo-desktop` exécute 144 tests, avec 143 réussites et un échec du test historique qui cherche encore les anciens IDs de contrôles supprimés ;
|
||||
- deux tentatives réelles de `Create -> Mint — NFT` provoquent un arrêt brutal du processus pendant la post-validation du `Create`.
|
||||
|
||||
## 8. Correctif `pre.014-delta-fix-002`
|
||||
|
||||
Après application de `fix-001`, deux essais successifs de `Create -> Mint — NFT` provoquent un arrêt brutal de l'application au même endroit. Le second essai est effectué après purge des logs.
|
||||
|
||||
Le journal réseau prouve que la fixture SPL classique est créée, puis que l'opération Metaplex `Create` est simulée, envoyée et confirmée :
|
||||
|
||||
```text
|
||||
fixture signature : 64kLtKRiCewywr1CdNbcznHZS7PtNnfh5vxzZLte2VoUexkoyGtRdVozMxsATpP97Sp1fjv2fmPwGUj9hM6VFH8d
|
||||
fixture slot : 482323101
|
||||
Create signature : NAXZephC3aPqe8KA4Ly81o56xkhUEEMMLdZKnYEqiifvRGuQmf997nM29EtWZESyC97qu75v4UzyRWt4aqxRN1d
|
||||
Create slot : 482323110
|
||||
```
|
||||
|
||||
Le dernier événement écrit est le lancement de l'hydratation canonique de cette signature puis l'envoi de `getTransaction`. Aucun panic Rust, aucune erreur applicative structurée et aucune erreur JSONL ne sont enregistrés avant la disparition du processus. Le défaut n'est donc pas classé comme un échec Metaplex de la transaction : il appartient à l'intégration desktop/runtime du nouveau dispatch de campagnes.
|
||||
|
||||
`fix-002` :
|
||||
|
||||
- conserve les campagnes réutilisables intactes ;
|
||||
- boxe explicitement le futur du dispatch Metaplex avant l'attente Tauri, afin d'éviter de conserver le gros state machine des onze branches directement dans le futur de commande ;
|
||||
- journalise `campaign_start`, `campaign_completed` et `campaign_failed` ;
|
||||
- réaligne le test frontend historique sur les contrôles de campagne qualifiés introduits par `fix-001`.
|
||||
|
||||
La validation Tauri doit reprendre par `Create -> Mint — NFT`. Si un arrêt brutal subsiste, les nouveaux marqueurs et la dernière étape réseau permettront de distinguer un défaut du runtime desktop d'un défaut d'hydratation HTTP.
|
||||
|
||||
## 9. Validation réelle de `fix-002`
|
||||
|
||||
La validation locale du 9 août 2026 est propre :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-app-demo-desktop 144 tests unitaires, tous OK
|
||||
cargo tauri dev démarrage OK
|
||||
```
|
||||
|
||||
Le bundle de logs du second essai confirme que le boxing du dispatch Metaplex supprime l’arrêt brutal observé avec `fix-001`. Les onze campagnes exposées par le desktop ont toutes un marqueur `campaign_start` suivi d’un marqueur `campaign_completed`, sans `campaign_failed` :
|
||||
|
||||
| Campagne | Exécutions/probes projetés | Statut desktop |
|
||||
|--------------------------------|---------------------------:|---------------------------------------------|
|
||||
| `create_mint_nft` | 2 | terminé |
|
||||
| `create_mint_sft` | 2 | terminé |
|
||||
| `create_mint_fungible` | 2 | terminé |
|
||||
| `create_mint_collection` | 2 | terminé |
|
||||
| `create_mint_programmable_nft` | 2 | terminé |
|
||||
| `collection_verify` | 6 | terminé |
|
||||
| `print_burn` | 4 | terminé |
|
||||
| `pnft_lifecycle` | 8 | terminé |
|
||||
| `escrow` | 7 | terminé |
|
||||
| `maintenance` | 7 | terminé, dont 4 indisponibilités qualifiées |
|
||||
| `use_probe` | 3 | terminé, dont 1 indisponibilité qualifiée |
|
||||
|
||||
Les journaux UI confirment notamment `maintenance : confirmed=3, unavailable=4, evidence=7` et `use_probe : confirmed=2, unavailable=1, evidence=3`. Les fichiers `error*.jsonl` du bundle fourni sont tous vides.
|
||||
|
||||
**Statut desktop Metaplex : validé pour les onze campagnes qualifiées.**
|
||||
|
||||
## 10. Consolidation structurelle `fix-003`
|
||||
|
||||
Le correctif suivant ne change aucune campagne réseau. Il simplifie seulement le desktop :
|
||||
|
||||
- `demo_execution_metadata_metaplex_campaign.rs` est fusionné dans `demo_execution_metadata_metaplex_token_metadata.rs` ;
|
||||
- les commandes Tauri et les contrats TS-RS restent inchangés ;
|
||||
- Metaplex suit désormais le même modèle de module unique que Token-2022 Token Metadata et Solana Program Metadata ;
|
||||
- les trois blocs de résultats deviennent un accordéon Bootstrap commun, sur le modèle de `demo_execution_spl` ;
|
||||
- la carte **Exigences** reste sous l’accordéon dans la colonne droite ;
|
||||
- le journal d’exécution reste pleine largeur sous la grille.
|
||||
|
||||
Après application, la validation requise est locale (`fmt`, `check`, Clippy, audit, 144 tests desktop) puis visuelle dans Tauri pour l’ouverture/fermeture des trois JsonViewer. Aucune nouvelle campagne Devnet n’est requise pour requalifier Metaplex.
|
||||
|
||||
## 11. Clôture de `pre.014`
|
||||
|
||||
La validation finale confirme que `fix-003` ne réintroduit aucune régression :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-app-demo-desktop 144 tests unitaires, tous OK
|
||||
```
|
||||
|
||||
La vérification visuelle Tauri confirme également :
|
||||
|
||||
- les trois accordéons de résultats s’ouvrent et se ferment correctement ;
|
||||
- les JsonViewer restent lisibles dans les accordéons ;
|
||||
- la carte **Exigences** reste sous les résultats dans la colonne droite ;
|
||||
- le journal d’exécution reste en pleine largeur sous la grille ;
|
||||
- les trois domaines Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata restent distincts.
|
||||
|
||||
Les campagnes réseau ayant déjà été qualifiées avant le refactor structurel de `fix-003`, aucun rerun Devnet supplémentaire n’est requis. **Statut de `0.4.8-pre.014` : terminé et validé.**
|
||||
Reference in New Issue
Block a user