v0.4.8-pre.012

docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md

@@ -1,11 +1,11 @@
 <!-- file: docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md -->
-<!-- version: 23 -->
+<!-- version: 25 -->
 
 # 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`. 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` 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.
 
 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.
 
@@ -324,7 +324,7 @@ Travaux parallèles intégrés : les fonctions de matérialisation Metaplex exis
 - `Extend` et `Trim` sont désormais observées et validées sur Devnet ;
 - preuve brute et rapport conservés sous `docs/validation/evidence/v0.4.8/pre.010/devnet/` et `docs/validation/V0_4_8_PRE_010_SOLANA_PROGRAM_METADATA_DEVNET_VALIDATION_REPORT.md`.
 
-### `0.4.8-pre.011` — complétude Token-2022 Token Metadata — terminée, validation fonctionnelle acquise
+### `0.4.8-pre.011` — complétude Token-2022 Token Metadata — terminée et validée
 
 - fermeture des écarts d’intents/builders/exécution confirmés pour `UpdateAuthority` et `Emit`, après réaudit des cinq instructions `Initialize`, `UpdateField`, `RemoveKey`, `UpdateAuthority` et `Emit` ;
 - conservation des snapshots dédiés `metadata/token_2022/` pour `TokenMetadata`, `TokenGroup` et `TokenGroupMember` ;
@@ -332,28 +332,46 @@ Travaux parallèles intégrés : les fonctions de matérialisation Metaplex exis
 - maintien de `InitializeMetadataPointer` et `UpdateMetadataPointer` dans le matérialiseur d’administration qui en possède déjà les faits ;
 - tests synthétiques et stateful.
 
-Résultat durable : les cinq instructions de `spl-token-metadata-interface` disposent désormais d’intents et de builders exacts. `UpdateAuthority` accepte une nouvelle autorité nullable ; `Emit` valide une plage maximale de 1 024 octets, refuse une plage ouverte avec `start` sans `end`, conserve le `returnData` de simulation et décode uniquement les réponses complètes. La postcondition stateful vérifie l’autorité finale depuis le snapshot TLV autoritatif. Les interfaces Token Group restent possédées par le même matérialiseur spécialisé, tandis que Metadata Pointer reste au matérialiseur d’administration. `pre.011-fix-001` active l’implémentation TS-RS de `serde_json::Value` via `serde-json-impl` et ferme la plage `Emit` ouverte ; `pre.011-fix-002` aligne la fixture de `kb-pipeline` sur `ExApiExecutionBlockhashKind::Latest` ; `pre.011-fix-004` remplace `fix-003`, rattache `UpdateAuthority` et `Emit` à l’entrée `token_metadata` et ajoute un test direct de cette projection. Après nettoyage intégral du cache Cargo, `cargo test -p kb-lib` réussit avec 693 tests unitaires et toutes les APIs externes, puis `cargo test --workspace` réussit avec 1 285 tests et tous les doc-tests. `pre.011-fix-005` clôt la documentation et ajoute les régressions directes pour l’autorité `None`, l’émission complète et la plage maximale de 1 024 octets. Leur première reprise a révélé uniquement deux attentes de nommage incorrectes dans les tests eux-mêmes : les plans exposent les codes canoniques préfixés `spl.token_2022.*`. `pre.011-fix-006` corrige ces deux assertions sans toucher au code de production ; sa validation ciblée constitue le dernier contrôle avant de commencer `pre.012`.
+Résultat durable : les cinq instructions de `spl-token-metadata-interface` disposent désormais d’intents et de builders exacts. `UpdateAuthority` accepte une nouvelle autorité nullable ; `Emit` valide une plage maximale de 1 024 octets, refuse une plage ouverte avec `start` sans `end`, conserve le `returnData` de simulation et décode uniquement les réponses complètes. La postcondition stateful vérifie l’autorité finale depuis le snapshot TLV autoritatif. Les interfaces Token Group restent possédées par le même matérialiseur spécialisé, tandis que Metadata Pointer reste au matérialiseur d’administration. `pre.011-fix-001` active l’implémentation TS-RS de `serde_json::Value` via `serde-json-impl` et ferme la plage `Emit` ouverte ; `pre.011-fix-002` aligne la fixture de `kb-pipeline` sur `ExApiExecutionBlockhashKind::Latest` ; `pre.011-fix-004` remplace `fix-003`, rattache `UpdateAuthority` et `Emit` à l’entrée `token_metadata` et ajoute un test direct de cette projection. `pre.011-fix-005` ajoute les régressions directes pour l’autorité `None`, l’émission complète et la plage maximale de 1 024 octets ; `pre.011-fix-006` corrige uniquement leurs attentes de nommage afin d’utiliser les codes canoniques préfixés `spl.token_2022.*`. La reprise finale réussit avec `cargo check --workspace`, `cargo clippy --all-targets`, l’audit workspace et `cargo test --workspace` ; `kb-lib` compte alors 695 tests unitaires réussis sans échec. `pre.011` est clôturée.
 
-### `0.4.8-pre.012` — campagne Devnet Token-2022 Token Metadata
+### `0.4.8-pre.012` — campagne Devnet Token-2022 Token Metadata — terminée et validée
 
-- fixture mint ;
-- simulations, soumissions sûres, confirmations, postconditions, replay et matérialisation.
+- préparer nativement un mint Token-2022 frais dont `MetadataPointer` est initialisé avant `InitializeMint2` et pointe vers le mint lui-même ;
+- préfinancer le mint pour la taille maximale atteinte par la campagne afin que les réallocations du TLV `TokenMetadata` restent rent-exempt ;
+- exécuter dans l’ordre `Initialize`, `UpdateField`, `Emit`, `RemoveKey`, puis `UpdateAuthority` ;
+- conserver simulation, signature, confirmation, hydratation canonique, extraction Core, replay, matérialisation instructionnelle et seconde passe d’idempotence ;
+- pour `Emit`, conserver et décoder le `returnData` sans exiger une matérialisation instructionnelle obligatoire ;
+- relire le mint après chaque transaction et vérifier la postcondition depuis le snapshot TLV autoritatif ;
+- promouvoir `SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` uniquement après réception des preuves réseau réelles ;
+- conserver un test Devnet opt-in nécessitant une confirmation opérateur explicite avant toute dépense.
 
-### `0.4.8-pre.013` — finalisation desktop metadata
+Résultat durable : la campagne réelle du 7 août 2026 confirme les cinq scénarios sur Devnet. Les cinq transactions possèdent une signature, un slot et une postcondition `Confirmed` ; `Emit` fournit 202 octets de `returnData` validés contre le snapshot TLV autoritatif. La matrice réseau est entièrement `confirmed`. `pre.012-delta-fix-001` corrige en outre l'omission de la dépendance directe `bs58` dans `kb-pipeline-demo-scenarios`, puis met à jour le test de matrice et les documents de preuve. Les contrôles `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, l'audit workspace, les tests de la crate et `cargo test --workspace` réussissent. `pre.012` est clôturée.
 
-- compléter le sous-panneau Token-2022 après les travaux de `pre.011` et `pre.012` ;
+### `0.4.8-pre.013` — réaudit et complétude Metaplex Token Metadata et campagnes Devnet
+
+- réauditer la couverture actuelle de Metaplex Token Metadata : opérations courantes, formes historiques/dépréciées, comptes, builders, exécuteur, préflight, postconditions, matérialisation et matrices ;
+- compléter uniquement les écarts réellement constatés, sans rouvrir artificiellement les surfaces déjà exactes ;
+- reprendre les campagnes Devnet existantes et vérifier leurs fixtures pour NFT, SFT, token fongible, collection et pNFT ;
+- compléter les fixtures spécialisées encore nécessaires, notamment éditions imprimées/burn, collection parent-membre et parcours pNFT avec token records, delegates ou rule sets lorsque le contrat l’exige ;
+- exécuter ou qualifier chaque opération réseau avec simulation, signature, confirmation, lectures stateful, replay, matérialisation et postcondition ;
+- ne jamais promouvoir une preuve synthétique ou une simple disponibilité de builder en preuve Devnet confirmée ;
+- produire ou mettre à jour les matrices et rapports Metaplex avant la finalisation desktop.
+
+### `0.4.8-pre.014` — finalisation desktop metadata
+
+- 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 ;
 - 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.
 
-### `0.4.8-pre.014` — stockage, matrices et réconciliation transversale
+### `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.
 
-### `0.4.8-pre.015` — clôture obligatoire
+### `0.4.8-pre.016` — clôture obligatoire
 
 Réservée à :