0.5.1-pre.002

This commit is contained in:
2026-08-09 19:34:08 +02:00
parent 816eee59a9
commit 6a680767ae
767 changed files with 12257 additions and 12195 deletions

View File

@@ -0,0 +1,324 @@
<!-- file: ks-pipeline-demo-scenarios/CHANGELOG.md -->
<!-- version: 74 -->
# CHANGELOG — ks-pipeline-demo-scenarios
## `0.5.1-pre.002`
- renomme `kb-pipeline-demo-scenarios` en `ks-pipeline-demo-scenarios`, sa bibliothèque en `ks_pipeline_demo_scenarios` et son CLI en `ks-pipeline-demo-scenarios-cli` ;
- renomme le fichier source du CLI et les adaptateurs desktop qui consomment les scénarios ;
- aligne le target racine et les targets de fixtures propres à cette crate sans changer les scénarios qualifiés.
## `0.5.0-pre.003`
### Documentation
- clarifie que les fixtures, séquences et qualifications réseau réutilisables appartiennent à cette crate lorsquelles sont consommées par les tests, le CLI ou le desktop ;
- prépare `0.5.4` pour centraliser les dispatchs, compositions decoder/materializer et critères de complétion encore réutilisables depuis `kb-app-demo-desktop`, sans rouvrir les preuves réseau déjà qualifiées.
## `0.4.8-pre.015`
- `pre.015-delta-fix-001` réconcilie lUSAGE avec la preuve Devnet Solana Program Metadata déjà acquise : les neuf opérations sont `confirmed` depuis `pre.010`, et `Close` conserve sa preuve spécifique `account_absence` ; aucune nouvelle campagne réseau nest ouverte.
## `0.4.8-pre.013`
- `pre.013-delta-fix-037` consolide la clôture Metaplex après validation locale complète de `fix-036` : `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets` sans warning, audit workspace clean et 105 tests unitaires + 1 CLI + 1 API externe réussissent. Les guides actifs cessent de présenter `Verify/Unverify`, le lifecycle pNFT ou Token Owned Escrow comme `not_run`, la campagne maintenance finale est documentée, et le TODO retire les tâches `pre.013` terminées. La matrice fonctionnelle reste inchangée à 15 `confirmed`, 5 `unavailable`, 0 `not_run`.
- `pre.013-delta-fix-036` ferme la matrice Devnet des 20 opérations courantes : `Update` est confirmé sur NFT par `4hxxBnsCA1JBJPNHgXRDeq1W7rXbFj2yySscWJKxU1VTMDcPzPfoWy7QzANHSDsbQfxxcwuAQNDLqEukgsug6qoZ` au slot `482162413`, avec simulation au slot `482162408`, replay, matérialisation, idempotence et transition `primary_sale_happened false -> true`; `Resize`, `Migrate`, `Collect` et `CloseAccounts` sont classés `unavailable` après probes Devnet exacts `Custom(201)`, `Custom(75)`, `Custom(7)` et `Custom(188)` sans soumission. La matrice finale compte 15 `confirmed`, 5 `unavailable`, 0 `not_run`; le warning Clippy `if_same_then_else` du test de matrice est supprimé en fusionnant les branches NFT identiques.
- `pre.013-delta-fix-035` corrige le parseur des refus runtime de la campagne maintenance : `simulation.error` contient déjà le JSON RPC sous forme de chaîne, et sa double sérialisation empêchait `fix-034` de reconnaître le `Custom(201)` pourtant observé. Le probe parse désormais structurellement `InstructionError[1].Custom`; le test de contrat existant couvre les codes `201`, `75`, `7` et `188`. La matrice reste à 14 `confirmed`, 2 `unavailable` et 4 `not_run`.
- `pre.013-delta-fix-034` enregistre le premier run de maintenance : `Update` franchit confirmation et postcondition `primary_sale_happened false -> true`, puis `Resize` atteint le handler courant et la simulation est refusée avec `AlreadyResized`, `Custom(201)`, `14643` CU consommées et aucune soumission. Comme les comptes créés aujourdhui sont déjà au layout cible et quun succès exigerait un compte legacy sous-dimensionné contrôlé, `Resize` passe à `unavailable`; la matrice devient 14 `confirmed`, 2 `unavailable` et 4 `not_run`. La campagne corrigée soumet uniquement `Update` et traite désormais `Resize`, `Migrate`, `Collect` et `CloseAccounts` comme probes simulation-only attendus respectivement en `201`, `75`, `7` et `188`.
- `pre.013-delta-fix-033` qualifie définitivement Token Owned Escrow : `CreateEscrowAccount` (`Yy7NEvme3obuiGRBbBjpuk3dv4aPMPBQ2ns7KmbY4K5EtyAimaaM8qN5SQzEqr9SPbRu1VDCFkNpAjnRGW4JYuj`, slot `482147206`), `TransferOutOfEscrow` (`4yJcSvnZJqihfZTE7nxN3o7H7zBCacpdZdwNQ1ueWQMmQZxR7KRb99C7rfrXX2AyezfSStMdqqTYL3oEWgwRhFi3`, slot `482147252`) et `CloseEscrowAccount` (`3GuwmGf9JEK7rHE3tudnxskvruyML9AGVXQimxii3uHdXqNEF4ScpmDXwhU3y2eaUnTbBPPhVkhRfLwJr9jbGJBo`, slot `482147267`) terminent simulation, confirmation, hydratation canonique, extraction Core, replay, matérialisation, postconditions stateful et idempotence ; la matrice passe à 14 `confirmed`, 1 `unavailable` et 5 `not_run`.
- prépare la campagne finale de maintenance sur un NFT frais : `Update` doit retourner `primary_sale_happened false -> true`, `Resize` doit confirmer sans altérer la possession du NFT, tandis que `Migrate`, `Collect` et `CloseAccounts` sont uniquement simulés et doivent respectivement exposer les refus runtime `Removed(75)`, `UpdateAuthorityIncorrect(7)` et `InvalidCloseAuthority(188)` sans aucune soumission.
- ajoute trois tests au scénario maintenance et conserve les probes réservés fail-closed : la campagne nessaie pas dusurper `FEE_AUTHORITY` ni `OWNERLESS_CLOSE_AUTHORITY`.
- `pre.013-delta-fix-032` enregistre le premier run Devnet escrow de `fix-031` : `CreateEscrowAccount` atteint bien le handler (`IX: Create Escrow Account`) mais la simulation est refusée avec `MissingRequiredSignature`, 17 268 CU consommées et aucune soumission. La cause est le placeholder `program_id` ajouté par le builder générique à l`authority=None` terminale ; les trois opérations escrow restent non promues pendant le correctif.
- `pre.013-delta-fix-031` enregistre le rerun `fix-030` du probe `Use` : le test termine `ok`, la simulation Devnet au slot `482133665` est refusée avec `InstructionError[0]=InvalidInstructionData`, quatre logs sont conservés et aucune soumission nest effectuée ; tous les autres checks et tests annoncés restent sans régression.
- prépare une campagne Devnet Token Owned Escrow strictement bornée : NFT parent frais, token attribut fungible frais, `CreateEscrowAccount`, création de lATA SPL classique détenu par le PDA escrow, dépôt contrôlé dune unité brute, `TransferOutOfEscrow` avec fermeture de lATA vidé, puis `CloseEscrowAccount` avec disparition du compte escrow.
- ajoute des postconditions stateful `TokenOwnedEscrow`, des preuves pipeline/idempotence pour les trois opérations Metaplex et maintient la matrice à 11 `confirmed`, 1 `unavailable` et 8 `not_run` tant que cette campagne na pas été exécutée sur Devnet.
- `pre.013-delta-fix-030` classe `Use` comme `unavailable` après le probe Devnet réel : l'instruction courante de discriminant 51 est simulée mais rejetée par Token Metadata avec `InstructionError[0]=InvalidInstructionData`, `Program log: Error: InvalidInstructionData`, `12085` compute units consommées et aucune soumission ; la matrice passe à 11 `confirmed`, 1 `unavailable` et 8 `not_run`.
- le probe `Use` peut désormais retourner cette simulation négative comme preuve et terminer `ok` en mode `submit=false`; le contrat de soumission reste simulation-first strict et ne signe jamais une simulation échouée.
- `pre.013-delta-fix-029` qualifie définitivement le cycle pNFT : `Delegate(StakingV1)`, `Lock`, `Unlock`, `Revoke(StakingV1)`, `Delegate(TransferV1)` et `Transfer` terminent tous simulation, confirmation, hydratation canonique, extraction Core, replay, matérialisation et idempotence ; les cinq opérations canoniques `Delegate`, `Revoke`, `Lock`, `Unlock`, `Transfer` passent à `confirmed` sur `programmable_nft`, portant la matrice à 11/20 opérations confirmées.
- prépare un probe Devnet borné pour `Use` sur un NFT classique frais avec `Uses::Multiple { remaining: 2, total: 2 }` : le probe simule dabord linstruction courante et distingue explicitement succès confirmé et indisponibilité runtime ; aucune promotion nest faite tant que la réponse Devnet nest pas observée.
- `pre.013-delta-fix-028` enregistre le rerun `fix-027` : la campagne pNFT franchit désormais `Delegate(Staking) -> Lock -> Unlock -> Revoke(Staking) -> Delegate(Transfer) -> Transfer` jusquà la postcondition finale du token account source ; le transfert est confirmé et son TokenRecord destination est `Unlocked` sans delegate, mais la campagne exigeait à tort que lATA source vide reste `Frozen` alors que le handler Metaplex courant thaw la source, transfère, puis freeze uniquement la destination ;
- corrige la postcondition finale en exigeant source `amount=0, state=Initialized` et destination `amount=1, state=Frozen`, et ajoute ces états à `METAPLEX_PNFT_LIFECYCLE_STATE` ; aucune opération lifecycle nest encore promue avant un rerun complet émettant les six signatures/slots et le bundle evidence final.
- `pre.013-delta-fix-027` enregistre le rerun `fix-026` : le workspace est entièrement propre (`ks-lib` 706/706, `ks-pipeline` 107/107, scénarios 96/96, desktop 135/135) et `Delegate(StakingV1)` franchit désormais confirmation, hydratation canonique, extraction Core, replay, matérialisation et idempotence avant quune postcondition de campagne ne lise à tort `delegate=None` dans la projection JSON brute du `TokenRecord` ; la campagne reste non qualifiée jusquau rerun avec projection canonique.
- `pre.013-delta-fix-026` enregistre le rerun `fix-025` : `Create -> Mint` franchit désormais entièrement sa préparation pNFT, puis `Delegate(StakingV1)` est réellement confirmé par `4S2uDrVU6ci59eKeGtGeXoUCbsUr4WxzSa7uYhmBxLtjKfNwpBkZRqm59V9cfbD99oE9AugMYppiQqnMbV2Hy1p7` au slot `482106293` avec hydratation canonique et extraction Core réussies ;
- le replay échoue ensuite dans `ks-lib` avant matérialisation parce que `Delegate.authority` et le fee payer sont le même wallet : Core replay expose donc le privilège writable global sur la position authority, alors que lAccountMeta officiel de cette position est seulement signer ;
- prépare le correctif de la même frontière pour `Delegate/Revoke` et pour `Lock/Unlock`, où `token_owner` est également le fee payer dans la campagne ; les cinq opérations lifecycle restent `not_run` jusquà un rerun complet.
- `pre.013-delta-fix-025` enregistre la première tentative réseau du cycle pNFT après correction du harness : `Create` est réellement confirmé par `PNkQAnykFoHVsREkhDbTW9eccyJoQvQbRZ2MJ4FsFRXyXint9fj6FT9PW45W5R3yi9HJ2aiSZXssH6B6pmyCcEz` au slot `482096529`, puis la campagne sarrête pendant sa post-validation stateful sur la Master Edition `HmCuW752ukBChVTbXtKJphUwJTJDdSycrgs6SrU2nT4B` du mint `DtBji9AYCqLRB48LFEFir427Kwy4Ehie6Pc8S87aQ6Rb` ;
- le défaut est dans `ks-lib` : le trailer officiel de 2 octets dune Master Edition compacte avait été introduit par `fix-021` comme padding nul, ce qui rejetait précisément le byte `ProgrammableNonFungible(4)` écrit par le programme courant ; aucune des cinq opérations lifecycle na encore été atteinte ni promue.
- `pre.013-delta-fix-024` corrige uniquement le harness `#[cfg(test)]` de la campagne pNFT préparée par `fix-023` : il réutilise le chargement de configuration, la surcharge PostgreSQL, la construction `PostgresStoreOptions`, le pool HTTP et le wallet directory déjà éprouvés par les autres campagnes Metaplex ;
- aligne l'émission `METAPLEX_PNFT_LIFECYCLE_EVIDENCE` sur les champs réels de `DevnetMetaplexTokenMetadataExecutionSummary` (`genesis_hash`, `simulation_context_slot`, `readiness.message_hash`, `fee.fee_lamports`) au lieu de champs inexistants du résultat brut de simulation ;
- enregistre que `cargo check --workspace` de `fix-023` était vert parce que le défaut restait sous `#[cfg(test)]`, tandis que `clippy --all-targets` et `cargo test -p ks-pipeline-demo-scenarios` compilaient ce harness et échouaient avant toute transaction pNFT ; la matrice reste à 6 opérations `confirmed` et 14 `not_run`.
- `pre.013-delta-fix-023` qualifie définitivement `Print` et `Burn` sur Devnet : `Print` est confirmé par `REHAxUZrSdKDj8F8k27Amrg7hwuJFhVfstjc9xjn2XGfTX38fH4tFwPeNrF5zeMN5pc21PpUPSgaKXMMfTFd7TE` au slot `482087799`, puis `Burn` par `4cNUxGGSWifuAtqdPJAtM3Cjpi4JATitRDqrvEAe85NLpMWcgWmC27bsfjNUmK6sEBDovNPtkPV3wDH1LpfGbhd1` au slot `482087818`; les deux étapes terminent hydratation canonique, extraction Core, replay, matérialisation et idempotence ;
- promeut `Print` et `Burn` à `confirmed` sur la famille NFT dans la matrice Devnet v3, qui passe à 6 opérations `confirmed` et 14 `not_run` ;
- prépare la campagne spécialisée pNFT `Delegate(Staking) -> Lock -> Unlock -> Revoke(Staking) -> Delegate(Transfer) -> Transfer` sur une fixture `programmable_nft` fraîche, avec signataire delegate supplémentaire, propriétaire destination frais, Token Records source/destination et ATA gelées validés à chaque transition ;
- conserve `Delegate`, `Revoke`, `Lock`, `Unlock` et `Transfer` à `not_run` jusquau rerun Devnet complet de cette nouvelle campagne.
- `pre.013-delta-fix-022` corrige la frontière `Future + Send` du runner Metaplex : les références `Signer + Sync` restent publiques, mais leur effacement vers `&dyn Signer` est désormais confiné à un helper synchrone de signature et ne traverse plus aucun `await` ;
- aligne la postcondition `Burn` sur le comportement courant de `MetadataV1` : l'absence reste valide, et un compte résiduel n'est accepté que comme tombstone fee exact `owner=Token Metadata`, non exécutable, lamports positifs, `space=1`, `data=[0x00]` ; les comptes token, Edition et Edition Marker doivent toujours être absents ;
- enregistre que le rerun `fix-021` atteint `Burn` et termine sa validation d'exécution avant cette seule garde sémantique, sans promouvoir `Print`/`Burn` tant que le bundle `METAPLEX_PRINT_BURN_*` complet n'est pas émis.
- `pre.013-delta-fix-021` enregistre la deuxième tentative `Print -> Burn` : `Print` est effectivement confirmé sur Devnet avec la signature `2199PTvKyTAfnGRHVaaCceW4u8phdJSu5ULkceD9uJeQyjjenEupK9osRZu1Pzx2NuQaJnAwngSAXMvr5oNtf5y6` au slot `482068400`, puis la campagne sarrête sur la lecture stateful du compte `Edition` avant hydratation/replay/matérialisation ; `Burn` nest pas atteint et la matrice conserve `Print`/`Burn` à `not_run` ;
- borne la voie multi-signataires publique à `Signer + Sync` tout en conservant la déclaration explicite, lunicité et la présence réelle de chaque signataire ; la validation suivante montrera que l'effacement local vers `Vec<&dyn Signer>` doit encore être confiné pour rendre effectivement le futur Tauri `Send` ;
- utilise `TemporaryWallet::as_sync_signer()` pour le keypair `edition_mint` et corrige le warning Clippy `cloned_ref_to_slice_refs` avec `std::slice::from_ref`.
- `pre.013-delta-fix-020` conserve la première tentative réseau `Print -> Burn` comme preuve de simulation négative : `Print` sarrête avant soumission avec `MetadataError::NotEnoughTokens` (`0x20`) parce que `fix-019` précréait lATA dédition vide alors que le chemin courant exige `amount=1` pour un compte token déjà existant ; aucune ligne `Print`/`Burn` nest promue ;
- corrige la fixture en conservant seulement le keypair `edition_mint` frais et en exigeant que le mint et son ATA soient tous deux absents avant `Print`, afin de laisser le programme courant créer le mint, créer lATA et frapper lunique token imprimé ;
- vérifie explicitement que lATA du master contient exactement un token avant `Print`, conserve les deux absences fraîches dans le résumé de campagne et supprime le re-export `NativeFixturePreparationEvidence` devenu inutilisé ;
- `pre.013-delta-fix-019` enregistre la campagne collection `Verify -> Unverify` entièrement confirmée : `Verify` signature `39JwUoxF2WWYWvEEWzFxSmKZVwoqXD1wH78sgGaoXv2vZKYUsXDNNnKikeuyQcfCqDftEMHSKFDHnTeSQ3bRpFcJ` slot `481936730`, puis `Unverify` signature `4Kfv42BGZtuBEwqTie5RWwdQ772hyxKiU9d3F3gfRnwVNrxCs2iZMvwL17Rwmuyr3XCVoHdaJVgaqCwv8y7bKoZY` slot `481936742`; les postconditions prouvent `verified false -> true -> false` et taille parent `0 -> 1 -> 0`, avec replay, matérialisation et idempotence complets ;
- promeut `Verify` et `Unverify` à `confirmed` sur la famille `collection` dans la matrice Devnet v3 ; létat réseau devient 4 opérations `confirmed` et 16 `not_run` ;
- ajoute un runner Devnet `Print -> Burn` sur un master NFT `PrintSupply::Limited(1)`, un mint dédition frais, lEdition PDA et lEdition Marker de lédition 1 ; `Print` doit prouver master supply `0 -> 1`, création Metadata/Edition/marker, mint imprimé supply `0 -> 1` et ATA amount `1`, puis `Burn` doit prouver supply imprimée `1 -> 0`, master supply `1 -> 0` et fermeture du token account, de lEdition et de lEdition Marker devenu vide, ainsi que fermeture sémantique de Metadata ;
- ajoute une voie explicite `execute_devnet_metaplex_token_metadata_with_signers` : les signataires supplémentaires doivent être déclarés dans `additional_authorized_signers`, effectivement fournis, uniques et bornés ; lAPI historique reste profil-wallet-only ;
- prépare les fixtures NFT imprimables avec `PrintSupply::Limited(1)` sans modifier les cinq profils `Create -> Mint` déjà qualifiés, et conserve `Print`/`Burn` à `not_run` jusquau test Devnet opt-in complet.
- `pre.013-delta-fix-018` conserve la première tentative collection comme preuve partielle : `Verify` est confirmé avec la signature `2kR1VeWdCW3FcKRZdNuKMMc3kGUmWRBXxXX8W1NNi2rhWfZYTg9zsDvJHx7WvebgUfc2K382J14i66E2qPEnjsqR` au slot `481931061`, mais le replay échoue avant matérialisation parce que le décodeur refusait le privilège writable global de l'autorité fee payer ; aucune promotion de matrice n'est effectuée avant rerun complet ;
- `pre.013-delta-fix-017` ferme la qualification multi-famille `Create -> Mint` : le rerun pNFT confirme `Create` au slot `481921980` puis `Mint` au slot `481921994`, avec Token Record présent, supply/amount `0 -> 1` et ATA `Initialized(1) -> Frozen(2)` ; la matrice v3 contient désormais cinq bundles `nft`, `sft`, `fungible`, `collection` et `programmable_nft` pour `Create` et `Mint` ;
- ajoute un runner Devnet réutilisable de collection parent-membre : Collection NFT parent `size=0`, membre NFT initialement `verified=false`, puis `Verify(CollectionV1)` et `Unverify(CollectionV1)` avec postconditions fermées `verified false -> true -> false` et taille `0 -> 1 -> 0` ;
- permet aux fixtures `Create` de déclarer un `collection_mint` initialement non vérifié sans modifier les cinq profils de base ;
- verrouille le format stateful du parent sur la sérialisation SDK réelle `collection_details.V1.size` et ajoute une régression empêchant un retour accidentel à une clé camelCase inexistante ;
- retire `SetCollectionSize` du parcours synthétique courant de collection : la taille est une postcondition stateful dérivée du programme, lopération obsolète nest pas utilisée pour fabriquer la preuve ;
- conserve `Verify` et `Unverify` à `not_run` tant que le nouveau test Devnet opt-in na pas produit signatures, slots et evidence machine-readable.
- `pre.013-delta-fix-016` corrige la postcondition SPL de la variante pNFT : après un `Mint` programmable confirmé, lATA classique est légitimement `Frozen` (`AccountState=2`) tandis que le Token Record Metaplex porte létat programmable ; NFT/SFT/fungible/collection continuent dexiger `Initialized` (`AccountState=1`) ;
- la première tentative pNFT confirme déjà `Mint` avec la signature `Gkg5A6ehuSzkU1N318kYoRHm5RdxV2yBRpaK9Gwyt6vN1ToYwAS6Vzpk2rQYWS9NJz1rnUpypLCn7DqWFzQzxFc` au slot `481913765`, amount `1`, owner et mint exacts, mais reste non promue car la campagne échoue ensuite sur lancienne attente `state=1` ;
- `DevnetMetaplexCreateMintTokenState` et `METAPLEX_CREATE_MINT_EVIDENCE` conservent désormais létat SPL brut avant/après `Mint`, afin que la preuve pNFT encode explicitement `Initialized(1) -> Frozen(2)` en plus de la transition supply/amount.
- `pre.013-delta-fix-015` enregistre la campagne collection `Create -> Mint` entièrement confirmée : `Create` signature `3jpxyWuxQVyBtbvqDnV1oahLyxCXMw1zQQZBGCKgQSfn2TNcBaUdfvJ6kFa8zL3XJLMpM6tahQTnu8AUsTkYc3Dy` slot `481911942`, puis `Mint` signature `4WEciqZA5vmtrh1ZeSbqcgVnezUy7qT6B6utySfkg7dbAmhH6SMwwY862zGbzPW3nBVFzMjFVGPEhnTt6TcAiEe2` slot `481911955`; les deux étapes terminent le pipeline de preuve complet avec deux snapshots stateful et supply/amount `0 -> 1`; la matrice v3 contient désormais les bundles `nft`, `sft`, `fungible` et `collection` pour `Create`/`Mint`, et le test de matrice nest plus figé sur les deux premières familles ;
- `pre.013-delta-fix-014` enregistre la campagne fungible `Create -> Mint` entièrement confirmée : `Create` signature `3J1Ebq9DVkupVFQmqQ84QaNeztwMuRwbtXj7CiyUWwZPj4KCAJpKLAbPvpYss5cdiY33foXXScWWZE98H7tvbZed` slot `481910724`, puis `Mint` signature `2GKiY9foLmioYtUHttA2D6nCSmsftRL1JDKxENHmCnb5w38FGSxwBiRNMfF7mH8htv3G45irmge6DVtr6VN359j2` slot `481910734`; chaque étape matérialise une ligne et `Mint` fait passer supply/amount de `0` à `1_000_000_000` sur un mint à 9 décimales ; la matrice v3 conserve désormais trois bundles `nft`, `sft` et `fungible` pour `Create` et `Mint`, tandis que collection et pNFT restent à exécuter ;
- `pre.013-delta-fix-013` enregistre la campagne SFT `Create -> Mint` entièrement confirmée : `Create` signature `2s81m6k9HYDLmCy7oXKaqBvtb62iyX4bJmij2f2VjHuoRQBBA6YqRuAsjyaM7JCaJXasbU3WCfiko91cZcDLLdxV` slot `481908028`, puis `Mint` signature `4pAemhEJewuLAeqLkqwzPvVmsCRbkyLiN6uAUWBA5RMsofaEDt5Xr8YGiBEvLWQM7Qvxnd81mmCHpandmfmWuyAm` slot `481908039` ; chaque étape matérialise une ligne et `Mint` fait passer supply/amount de `0` à `10` ;
- fait évoluer la matrice Devnet en version 3 afin de stocker une preuve complète distincte par famille au lieu dagréger plusieurs signatures, slots et message hashes dans une seule liste dévidence ; `Create` et `Mint` restent les deux seules opérations `confirmed`, désormais observées sur `nft` et `sft`, tandis que les 18 autres opérations restent `not_run` ;
- `pre.013-delta-fix-012` enregistre la première campagne NFT `Create -> Mint` entièrement confirmée : `Create` signature `okwkuQFp7yVguYW7GEY9Chv6ochM8TWBEeCGV1gu5Waku9wQvMfrKjkig6JxXBwpKoFTECignzJ8HFf8dLtpsvS` slot `481904731`, puis `Mint` signature `3hSizfdvezyFpfhqX4Za4wmhdMHhSPAisFvYjFAxpRzYcUXhryxCzc9qpwod3Yjm6GmijXTGjjDUuVksfpBzLwz1` slot `481904744` ; chaque étape produit une matérialisation et `Mint` fait passer supply/amount de `0` à `1` ;
- promeut `Create` et `Mint` à `confirmed` sur la famille NFT dans la matrice Devnet v2, conserve les 18 autres opérations à `not_run` et exige désormais des preuves observées complètes pour toute ligne `confirmed` ;
- conserve le slot RPC de simulation dans `DevnetMetaplexTokenMetadataExecutionSummary` et imprime une ligne `METAPLEX_CREATE_MINT_EVIDENCE` machine-readable avec genesis hash, slot de simulation, message hash, fee, confirmation et état du pipeline pour les futures campagnes SFT/fungible/collection/pNFT ;
- `pre.013-delta-fix-011` corrige la postcondition SPL de la campagne `Create -> Mint` : lorsquune famille demande une Master Edition, `Create` transfère légitimement les mint/freeze authorities vers le PDA Master Edition ; SFT et fungible conservent lautorité opérateur ;
- supprime le helper `read_token_account` devenu inutilisé et élimine le warning `dead_code` observé après `fix-010` ;
- conserve signature + slot dans toute erreur SPL postérieure à un `Create` ou `Mint` déjà confirmé afin quune preuve pipeline complète ne soit plus perdue par une postcondition ultérieure ;
- corrige linterprétation de la tentative précédente : le mismatch dautorité nétait pas une preuve de fixture stale. `fix-010` reste un durcissement fresh-only valide, mais le chemin de campagne montre que lerreur était atteinte après `Create`. La tentative suivant `fix-010` franchit même `validate_confirmed_execution("create", ...)`, donc replay, matérialisation et idempotence ont réussi avant la postcondition SPL ; signature et slot nayant pas été imprimés, la matrice reste néanmoins `not_run`.
- `pre.013-delta-fix-010` rend la fixture `Create -> Mint` strictement fraîche : le mint keypair est créé avec `TemporaryWalletStore::create` au lieu de `load_or_create`, son adresse doit être absente de Devnet avant préparation, puis le mint et lATA sont relus à `minContextSlot` égal au slot confirmé de la transaction native ;
- `fix-010` a initialement été motivé par un mismatch dautorité `3RJXuBF6xB3j47EeAHEBbcwvV66rJrkhmJvYNr36jz8x` contre lopérateur `J12WA6c42oqpWkLu1dFa4pCegkQJPpxabwc3RRCMSUuH` ; le réaudit de `fix-011` corrige cette interprétation : la postcondition était exécutée après `Create` et observait le transfert normal des autorités vers le PDA Master Edition ;
- `pre.013-delta-fix-009` enregistre la troisième tentative NFT : `Create` est confirmée sur Devnet avec la signature `51MXdFFFNY7UTS23cmfCQBfrDKC99uk5Trtw2gkptvEug9aWJ2R1cE9Ta5QHbe4kS1NYgRUSSMmmdbqdhyxxnR4Y` au slot `481882374`, puis la post-validation échoue uniquement au replay instructionnel ;
- relie cet échec au contrat trop strict du décodeur `Create`/`Mint`, qui confondait flags positionnels et privilèges globaux de transaction, et ajoute un diagnostic compact des compteurs `DecodeReplaySummary` lorsquun replay reste incomplet ;
- conserve `Create` et `Mint` à `not_run` tant que replay, matérialisation et idempotence ne sont pas tous démontrés.
- `pre.013-delta-fix-008` corrige la seconde tentative NFT `Create -> Mint` : les snapshots Metaplex utilisaient encore la borne pipeline historique de `1 MiB`, alors que le transport refuse une lecture complète `getAccountInfo` au-delà de `65536` octets ;
- utilise désormais la borne stateful commune du transport dans tous les snapshots `Create -> Mint` et verrouille cette valeur par test ;
- enrichit une éventuelle erreur post-exécution restante avec la signature et le slot déjà confirmés afin de ne plus perdre l'identité d'une transaction ayant atteint la post-validation ;
- conserve les 20 opérations à `not_run` jusqu'à une campagne terminée avec preuves exploitables.
- `pre.013-delta-fix-007` réorganise la crate par domaines stables (`metadata/solana_program`, `metadata/metaplex_token_metadata`, `spl/associated_token_account`, `spl/memo`, `spl/token`, `spl/token_2022` et `spl/token_2022/metadata`) sans modifier les exports publics de crate-root ;
- supprime les noms de modules racine historiques et incohérents `metadata_solana_program_*`, `solana_metaplex_token_metadata_*`, `solana_token_2022_*` et `token_2022_*` au profit d'une arborescence correspondant aux domaines du workspace ;
- corrige le warning Clippy `cloned_ref_to_slice_refs` du test de borne `minContextSlot` avec `std::slice::from_ref` ;
- durcit la sélection des preuves de matérialisation Metaplex : les lignes sont désormais retenues par l'identité du matérialiseur `MtMetadataMetaplexTokenMetadataMaterializer` et non par une chaîne de nom de décodeur ;
- enrichit l'erreur `Create -> Mint` avec les booléens post-exécution, les nombres de lignes/snapshots et les diagnostics accumulés afin qu'une nouvelle tentative Devnet distingue immédiatement hydratation, extraction, replay ou matérialisation manquante ;
- conserve `Create` et `Mint` à `not_run` : la première tentative NFT de `fix-006` a atteint la post-validation mais a été interrompue par `metaplex_create_mint_post_execution_incomplete` avant émission d'une preuve exploitable ;
- `pre.013-delta-fix-006` ajoute une campagne Devnet réutilisable et bornée `Create -> Mint` exécutée une famille à la fois (`nft`, `sft`, `fungible`, `collection` ou `programmable_nft`) ;
- lie désormais toutes les lectures Metaplex postcondition au slot de confirmation de la transaction via `minContextSlot`, afin que `after_state` ne puisse pas provenir dun contexte antérieur ;
- exige pour `Create` et `Mint` simulation réussie, confirmation, hydratation canonique, extraction Core, replay, matérialisation, seconde passe idempotente et snapshots Metaplex attendus ;
- relit en plus le mint SPL classique et lATA au slot confirmé : supply et amount doivent rester nuls après `Create`, puis devenir exactement `mint_amount_raw` après `Mint` ;
- exige la présence du master edition pour NFT/collection/pNFT et du token record après `Mint` pour pNFT, sans précréer ces preuves dans la fixture ;
- conserve les 20 opérations de la matrice réseau à `not_run` jusquà lexécution réelle de la nouvelle campagne ;
- `pre.013-delta-fix-005` prépare désormais, dans la même transaction native, le mint SPL classique et lATA canonique de lopérateur, tout en conservant une supply nulle avant lopération Metaplex `Mint` ;
- ajoute au résumé de fixture lATA, le token record pNFT éventuel, le montant brut par famille et un JSON `Mint` typé prêt à exécuter après `Create` ;
- vérifie après confirmation le layout exact du mint et de lATA classique, notamment mint, owner, amount=0, état initialisé et taille 165 octets ;
- dérive le token-record PDA uniquement pour pNFT et verrouille hors réseau les montants `Mint` : NFT/collection/pNFT=1, SFT=10 et fungible=1_000_000_000 à 9 décimales ;
- conserve les 20 opérations Metaplex à `not_run` : ce correctif prépare les préconditions token accounts/supply mais ne transforme aucune fixture en preuve Devnet ;
- `pre.013-delta-fix-002` rend les fixtures `Create` réellement cohérentes avec les cinq familles Devnet : NFT, SFT et collection restent à 0 décimale, tandis que le mint fongible est préparé à 9 décimales ;
- déplace la sélection du `TokenStandard`, de `collection_details`, de `master_edition` et de `print_supply` depuis ladaptateur desktop vers la fixture réutilisable afin que CLI, tests et futures campagnes consomment le même contrat ;
- vérifie hors réseau que les cinq JSON `Create` se désérialisent vers `ExMetaplexTokenMetadataOperation::Create` et que seules les familles NFT, collection et pNFT demandent une master edition ;
- `pre.013-delta-fix-001` corrige le test Devnet opt-in pour la signature actuelle de `PostgresStoreOptions::new(database_url, max_connections, connect_timeout_ms, auto_initialize_schema)` et conserve le timeout de cinq secondes sous forme `5_000` ms ;
- réaudite Metaplex Token Metadata contre lIDL historique de 58 instructions, la matrice dexécution et la surface SDK actuelle : 20 opérations courantes, 15 obsolètes exécutables sous approbation explicite, 22 remplacées en décodage uniquement et une frontière Bubblegum ;
- rouvre `METAPLEX_TOKEN_METADATA_DEVNET_EXECUTION_MATRIX.json` sous `0.4.8-pre.013` sans inventer de preuve réseau : les 20 opérations courantes restent initialement `not_run` ;
- corrige le runner Devnet Metaplex afin dexécuter réellement la post-validation déjà déclarée par sa policy : hydratation canonique, extraction Core, replay, matérialisation et seconde passe didempotence ;
- expose dans le résumé les rapports de backfill, extraction, replay, idempotence, les matérialisations instructionnelles et le diagnostic agrégé ;
- borne les retries de post-validation à 20 et exige PostgreSQL dans le test Devnet opt-in dès quune exécution réelle est demandée ;
- conserve comme travail restant de la même prerelease les fixtures spécialisées et les preuves réseau des opérations autres que `Create` et `UpdateAsUpdateAuthorityV2`.
## `0.4.8-pre.012`
- corrige le delta initial en déclarant explicitement `bs58.workspace = true`, utilisé directement par les fixtures et gardes Token-2022 de la crate ;
- confirme sur Devnet les cinq opérations Token Metadata de la campagne avec cinq signatures, cinq slots et des postconditions `Confirmed` ;
- conserve pour `Emit` un `returnData` complet de 202 octets validé contre le snapshot TLV autoritatif ;
- promeut les cinq scénarios de `SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` à `confirmed` avec leurs preuves réelles ;
- clôt les TODO opérateur de `pre.012` après `cargo fmt`, `cargo check --workspace`, `cargo clippy --all-targets`, audit workspace, tests de crate et `cargo test --workspace` réussis ;
- ajoute une fixture native de mint Token-2022 avec `MetadataPointer` auto-référent initialisé avant `InitializeMint2` ;
- préfinance le mint pour les réallocations du TLV Token Metadata atteintes par la campagne ;
- ajoute une campagne Devnet ordonnée `Initialize → UpdateField → Emit → RemoveKey → UpdateAuthority` avec simulation, soumission autorisée, confirmation, hydratation, replay, matérialisation et postconditions stateful ;
- étend le préflight générique Token-2022 aux opérations Token Metadata et nexige aucune matérialisation instructionnelle pour `Emit` ;
- ajoute une matrice réseau conservative à cinq scénarios, initialement intégralement `not_run` ;
- ajoute un test Devnet opt-in avec sortie structurée des signatures, slots, postconditions et octets de `returnData`.
## `0.4.8-pre.011`
- adapte la fixture synthétique de simulation au nouveau champ optionnel `return_data` du contrat commun ;
- promeut les neuf lignes Solana Program Metadata à `confirmed` avec les preuves des deux campagnes Devnet finales de `pre.010`.
## 0.4.8-pre.009 — scénarios Devnet Solana Program Metadata
- déplace `SetAuthority` du compte Metadata non canonique vers le Buffer non canonique, conformément au processeur officiel qui refuse cette opération sur les metadata non canoniques ;
- réconcilie lordre des neuf étapes, la fixture, la matrice Devnet et les tests de campagne ;
- ajoute une régression garantissant que `SetAuthority` ne cible jamais le compte Metadata non canonique de la fixture ;
- réutilise lunique cible canonique `ks-pipeline-demo-scenarios` pour les logs de fixture et supprime la seconde constante incompatible avec la convention de logging de la crate ;
- corrige les derniers diagnostics Clippy des tests : `str::len()` direct pour les seeds UTF-8 et `return` explicite dans la closure de statut de validation ;
- corrige les tests de réconciliation des opérations : comparaison de références `&str` et durée de vie de linventaire de scénarios ;
- documente la crate du test dAPI publique externe afin de conserver `missing_docs` propre ;
- ajoute deux parcours ordonnés couvrant exactement les neuf opérations stables de `ProgM6…` ;
- prépare deux PDA non canoniques préfinancés, un `Buffer` et un compte `Metadata`, à partir du wallet persistant du profil Devnet ;
- ajoute un runner simulation-first avec préflight stateful, `ExSafetyChecker`, signature, soumission, confirmation, lectures avant/après et matérialisation des snapshots ;
- ajoute une campagne confirmée réutilisable qui exécute les neuf étapes sans déplacer lorchestration dans le desktop ;
- distingue la preuve `materialized_snapshot` de la preuve terminale `account_absence` après `Close` ;
- ajoute une matrice conservative dont tous les statuts réseau restent `not_run` avant exécution réelle ;
- conserve `ks-pipeline` indépendant de cette crate et ne modifie pas encore `demo_execution_metadata`.
## 0.4.7-pre.016
- généralise README et USAGE autour des groupes fonctionnels ;
- nettoie le TODO et conserve les fixtures Devnet spécialisées comme dette explicite ;
- qualifie séparément builders disponibles et preuves réseau observées.
## 0.4.7-pre.015
- étend le parcours NFT Devnet à une troisième étape `UpdateAsUpdateAuthorityV2` qui rend les metadata immutables ;
- distingue lédition maître créée par `Create` des futures fixtures dédition imprimée ;
- conserve `Print` et `Burn` comme étapes ultérieures tant que leurs comptes SPL et édition ne sont pas préparés de bout en bout.
## 0.4.7-pre.014
- Expose cinq parcours Metaplex Devnet préparables : NFT, SFT, fungible, collection parent et pNFT sans rule set.
- Conserver un cycle borné `Create -> UpdateAsUpdateAuthorityV2` pour chaque famille avant d'étendre les opérations spécialisées.
## 0.4.7-pre.013-fix-014
- crée un nouveau mint natif pour chaque nouvelle préparation `Create`, afin de ne jamais réutiliser un PDA metadata déjà créé ;
- limite linventaire Devnet visible au parcours NFT `create -> update` réellement préparé de bout en bout ;
- conserve les cinq parcours synthétiques comme matrice cible sans les présenter comme exécutables sur Devnet.
## 0.4.7-pre.013-fix-013
- retire lappel résiduel à `ExSplTokenExecutor` dans la préparation native du mint Metaplex ;
- construit directement linstruction officielle `spl_token_interface::instruction::initialize_mint2` ;
- ajoute cette instruction au plan composite `SystemCreateAccount + InitializeMint2` sans falsifier les exigences de post-validation de lexécuteur SPL ;
- ajoute les dépendances directes `solana-instruction` et `spl-token-interface` à la crate de scénarios ;
- conserve la simulation exacte, les deux signatures, la confirmation et la relecture on-chain du mint.
## 0.4.7-pre.013-fix-012
- aligne la fixture Rust native sur les APIs publiques réelles du workspace ;
- évalue le `ExApiPreparedExecutionPlan` avec `evaluate_prepared_plan` ;
- conserve `MdSignature` pour lenvoi et la confirmation, puis retourne sa valeur chaîne ;
- convertit la clé du mint en `MdPubkey` pour `getAccountInfo` ;
- supprime lavertissement du paramètre de rent conservé dans le contrat de politique.
## 0.4.7-pre.013-fix-011
- remplace la préparation Metaplex fondée sur `solana-keygen`, `solana` et `spl-token` par une transaction Rust native ;
- crée le mint par `SystemCreateAccount` puis `SPL Token InitializeMint2` dans un même message simulé, signé et confirmé ;
- utilise explicitement le wallet du profil comme mint authority et freeze authority ;
- conserve le keypair du mint dans `ks-wallet` sans exposer ni déléguer ses secrets à une CLI externe.
## 0.4.7-pre.013-fix-010
- adapte la création de la fixture NFT à la CLI `spl-token` installée, qui ne prend pas en charge `create-token --freeze-authority` ;
- crée le mint avec `--enable-freeze`, puis transfère explicitement les autorités `freeze` et `mint` au wallet du profil ;
- versionne la fixture en `create-mint-profile-authority-v4.json` afin de ne pas réutiliser un mint incomplet issu du fix précédent.
## 0.4.7-pre.013-fix-009
- remplace linventaire Metaplex plat par cinq parcours cohérents avec fixture, état initial, état attendu et cibles de matérialisation ;
- ajoute la matérialisation optionnelle des snapshots confirmés ;
- crée la fixture NFT `v3` avec mint authority et freeze authority détenues par le wallet du profil ;
- interdit une matérialisation demandée sans lecture de postcondition.
## 0.4.7-pre.013-fix-007
- fournit explicitement le Program ID SPL Token classique dans le modèle et la fixture `Create` NFT ;
- ajoute des assertions empêchant le retour de `spl_token_program: null` pour ce parcours ;
- conserve `PrintSupply::Zero` et les PDA dérivés depuis le mint préparé.
## 0.4.7-pre.013-fix-006
- corrige le modèle et la fixture `Create` NFT avec `PrintSupply::Zero` ;
- ajoute un test garantissant que le modèle JSON nommé ne réintroduit pas un `print_supply` absent.
## 0.4.7-pre.013-fix-003
- Ajout du guide intégré, du journal dexécution et de titres explicites pour les résultats JSON Metaplex.
- Ajout dun préparateur idempotent de fixture `Create` : mint SPL classique Devnet, PDA metadata et master edition dérivés, intent JSON prêt à simuler.
## 0.4.7-pre.012-fix-003
- ajout explicite de la dépendance workspace `mpl-token-metadata` requise par les modèles et constructeurs de scénarios ;
- alignement du test de placeholder sur le code stable `config` réellement exposé par `ks_core::Error::config` ;
- validation locale : formatage, workspace check, clippy et audits propres ; 53 tests de bibliothèque réussis avant correction de lassertion, un seul test échouant sur le code attendu.
## 0.4.7-pre.012-fix-002
- rejet explicite des placeholders `...` dans le JSON dopération Metaplex ;
- inventaire public des vingt opérations courantes acceptées par les campagnes automatiques ;
- modèles JSON structurés pour `Create`, `Update`, `Verify` et `Unverify` ;
- constructeurs nommés pour les parcours créateur `Verify` et `Unverify` ;
- documentation corrigée afin de ne plus présenter un placeholder comme une commande exécutable.
## 0.4.7-pre.012 — couverture du runner Devnet Metaplex
- passage de la matrice Devnet à `0.4.7-pre.012` ;
- fermeture du statut `implemented` pour les 20 opérations courantes ;
- ajout dun constructeur de requête depuis le JSON typé `ExMetaplexTokenMetadataOperation` ;
- ajout dun test Devnet opt-in piloté par variables denvironnement pour simuler ou soumettre nimporte quelle opération courante ;
- maintien des statuts réseau à `not_run` tant quaucune exécution locale na fourni les preuves attendues.
- correction du contrat stateful partagé afin que les lectures préflight et postcondition soient désérialisables depuis les variables JSON du test Devnet opt-in.
## 0.4.7-pre.011 — réouverture des campagnes Devnet Metaplex
### Exécution Devnet
- ajout dun exécuteur Metaplex Devnet réel, simulation-first et limité aux opérations non dépréciées ;
- contrôle du genesis hash Devnet, du wallet de profil, des signers et des plafonds de coût ;
- ajout des lectures stateful avant/après, du préflight, de la simulation RPC exacte, de la soumission contrôlée et de la confirmation ;
- ajout dune matrice fermée des 20 opérations courantes, avec `Create`, `Update`, `Verify` et `Unverify` attribuées au premier lot `pre.011` ;
- conservation de tous les statuts réseau à `not_run` tant quaucune preuve locale na été observée.
### Documentation
- réorganisation des quatre documents de crate ;
- ajout des lots `pre.011` et `pre.012` au TODO pour couvrir les 20 opérations courantes sur Devnet ;
- clarification du rôle ciblé du CLI et du maintien des scénarios UI dans le desktop.
## 0.4.7-pre.010 — corpus de validation croisée
- ajout dun corpus fermé couvrant outer/CPI, succès/échec, cinq familles dactifs et neuf classes derreur ;
- ajout de contrats distincts de preuve réseau pour simulation, soumission et postcondition ;
- refus de toute promotion réseau fondée uniquement sur des preuves synthétiques.
## 0.4.7-pre.009
- ajout de linventaire Metaplex Devnet simulation et de son test de couverture.
## 0.4.7-pre.008
- ajout des scénarios synthétiques NFT, SFT, token fongible, collection et pNFT ;
- ajout de la matrice de validation Devnet/Testnet ;
- conservation du CLI sans commande Metaplex non justifiée.
## 0.4.6
- alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;
- clôture des tâches de migration applicables et report explicite des évolutions ultérieures dans le TODO.
## 0.1.0-pre.075
- ajout du guide opérateur Devnet `0.4.6` distinguant les scénarios de validation des composants réutilisables ;
## 0.1.0-pre.073
- ajout du guide transversal [`docs/guides/DEVNET_VALIDATION.md`](../docs/guides/DEVNET_VALIDATION.md) ;
## 0.1.0-pre.072
- reclassement du TODO selon les blocants avant `0.4.6`, les travaux `0.4.7`, les versions ultérieures et les dépendances conditionnelles.
## 0.1.0-pre.070
- enrichissement du `USAGE.md` avec plusieurs exemples couvrant les principales familles dAPI publiques ;
- ajout du contrat documentaire de la crate mixte ;
- inventaire des scénarios publics et du binaire CLI ;
- documentation des tests Devnet comme références dexécution réelle ;
- classement des travaux dautonomie CLI, fixtures et Metaplex dans le TODO.
## 0.1.0-pre.062
- extraction des scénarios de démonstration hors du desktop ;
- conservation du nom de bibliothèque `ks_pipeline_demo_scenarios` ;
- création du binaire explicite `ks-pipeline-demo-scenarios-cli` avec `autobins = false` ;
- migration des scénarios System Transfer, Memo v4, ATA, SPL Token et Token-2022 ;
- validation connue de 39 tests de bibliothèque et 1 test de binaire.