367 lines
47 KiB
Markdown
367 lines
47 KiB
Markdown
<!-- file: ks-pipeline-demo-scenarios/CHANGELOG.md -->
|
||
<!-- version: 81 -->
|
||
|
||
# CHANGELOG — ks-pipeline-demo-scenarios
|
||
|
||
## `0.5.2-pre.006-delta-fix-006`
|
||
|
||
- corrige le wrapper pNFT legacy : il reprend son paramètre `workspace_root` historique et construit le wallet temporaire uniquement dans ce wrapper, tandis que la variante `_with_wallet` conserve le signer explicite ;
|
||
- retire l'initialisation du champ inexistant `wallet` dans `PreparedToken2022Execution`, le signer restant fourni explicitement par l'appelant lors de la signature après simulation.
|
||
|
||
## `0.5.2-pre.006-delta-fix-005`
|
||
|
||
- introduit `DevnetExecutionWallet` comme capacité de signature commune aux wallets temporaires et aux `.kswallet` authentifiés, sans accès aux bytes privés ;
|
||
- résout explicitement `wallet_alias` vers un `.kswallet` déverrouillé et interdit toujours tout fallback silencieux vers le JSON temporaire ;
|
||
- sépare les chemins persistants et temporaires dans les scénarios/fixtures, puis branche System, Memo, ATA, SPL Token, Token-2022, Solana Program Metadata et Token-2022 Metadata sur un signer explicitement résolu ;
|
||
- propage le même signer persistant à toutes les campagnes Metaplex du desktop, y compris les parcours multi-signers ; les mints, delegates et destinations réellement jetables restent des keypairs temporaires distinctes.
|
||
|
||
## `0.5.2-pre.006`
|
||
|
||
- ajoute l'inspection et l'unlock explicites du wallet natif sélectionné par `profile.wallet.wallet_alias`, avec `WalletPassword` fourni uniquement au runtime ;
|
||
- renomme le chemin historique en `load_profile_temporary_wallet` et interdit qu'un alias persistant configuré retombe silencieusement sur le wallet temporaire ;
|
||
- refuse les fichiers `.kswallet` dans le workflow CLI Token-2022 fondé sur `solana-keygen` / `spl-token`, exige explicitement un export `SolanaCliJson` et ne révèle plus le chemin complet d’un wallet absent ;
|
||
- ajoute des tests de sélection persistante, unlock, refus de fallback et rejet du conteneur natif dans le workflow CLI.
|
||
|
||
## `0.5.1-pre.007`
|
||
|
||
- supprime la composition par défaut dédiée aux scénarios et charge directement les defaults partagés de `ks-config` ;
|
||
- conserve `KS_DEVNET_CONFIG_PATH` comme override facultatif vers une composition explicite ;
|
||
- lit désormais les autorisations de soumission Devnet depuis `ExecutionConfig` plutôt que depuis le contrat wallet.
|
||
|
||
## `0.5.1-pre.006`
|
||
|
||
- remplace la dépendance runtime au document applicatif monolithique par `config/ks-pipeline-demo-scenarios.default.config.json` pour les scénarios Devnet opt-in ;
|
||
- résout la composition par `ks-config`, puis conserve le contrat `AppConfig/ProfileConfig` runtime existant afin de ne pas requalifier les scénarios réseau ;
|
||
- aligne les fixtures unitaires sur les snapshots runtime sous `test-fixtures/config/` plutôt que sur une configuration source de binaire.
|
||
|
||
## `0.5.1-pre.005`
|
||
|
||
- aligne les scénarios et fixtures sur `config/app.config.json` comme document général par défaut ;
|
||
- conserve `KS_DEVNET_CONFIG_PATH` comme override du document applicatif des scénarios, sans dépendre du document logging.
|
||
|
||
## `0.5.1-pre.004`
|
||
|
||
- migre les paramètres d'environnement des scénarios réutilisables vers `KS_*` et les DSN de test vers `KS_SECRET_*` ;
|
||
- consolide les fixtures Token-2022 exposées au desktop sous `KS_PUBLIC_*`, sans conserver les anciens aliases `TOKEN_2022_*` / `KB_*` ;
|
||
- aligne le CLI, les campagnes Devnet, le rendu `fixture.env` et le guide d'utilisation sans rejouer ni requalifier les scénarios réseau.
|
||
|
||
## `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 lorsqu’elles 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 l’USAGE 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 n’est 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 aujourd’hui sont déjà au layout cible et qu’un 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 n’essaie pas d’usurper `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 n’est 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 l’ATA SPL classique détenu par le PDA escrow, dépôt contrôlé d’une unité brute, `TransferOutOfEscrow` avec fermeture de l’ATA 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 n’a 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 d’abord l’instruction courante et distingue explicitement succès confirmé et indisponibilité runtime ; aucune promotion n’est faite tant que la réponse Devnet n’est 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 l’ATA 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 n’est 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 qu’une postcondition de campagne ne lise à tort `delegate=None` dans la projection JSON brute du `TokenRecord` ; la campagne reste non qualifiée jusqu’au 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 l’AccountMeta 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 s’arrê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 d’une 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 n’a 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` jusqu’au 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 s’arrête sur la lecture stateful du compte `Edition` avant hydratation/replay/matérialisation ; `Burn` n’est 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, l’unicité 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` s’arrête avant soumission avec `MetadataError::NotEnoughTokens` (`0x20`) parce que `fix-019` précréait l’ATA d’édition vide alors que le chemin courant exige `amount=1` pour un compte token déjà existant ; aucune ligne `Print`/`Burn` n’est 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 l’ATA et frapper l’unique token imprimé ;
|
||
- vérifie explicitement que l’ATA 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, l’Edition PDA et l’Edition 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 l’Edition et de l’Edition 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 ; l’API 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` jusqu’au 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, l’opération obsolète n’est pas utilisée pour fabriquer la preuve ;
|
||
- conserve `Verify` et `Unverify` à `not_run` tant que le nouveau test Devnet opt-in n’a 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é, l’ATA classique est légitimement `Frozen` (`AccountState=2`) tandis que le Token Record Metaplex porte l’état programmable ; NFT/SFT/fungible/collection continuent d’exiger `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 l’ancienne 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 n’est 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 d’agré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` : lorsqu’une famille demande une Master Edition, `Create` transfère légitimement les mint/freeze authorities vers le PDA Master Edition ; SFT et fungible conservent l’autorité 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 qu’une preuve pipeline complète ne soit plus perdue par une postcondition ultérieure ;
|
||
- corrige l’interprétation de la tentative précédente : le mismatch d’autorité n’était pas une preuve de fixture stale. `fix-010` reste un durcissement fresh-only valide, mais le chemin de campagne montre que l’erreur é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 n’ayant 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 l’ATA sont relus à `minContextSlot` égal au slot confirmé de la transaction native ;
|
||
- `fix-010` a initialement été motivé par un mismatch d’autorité `3RJXuBF6xB3j47EeAHEBbcwvV66rJrkhmJvYNr36jz8x` contre l’opé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` lorsqu’un 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 d’un 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 l’ATA 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’à l’exé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 l’ATA canonique de l’opérateur, tout en conservant une supply nulle avant l’opération Metaplex `Mint` ;
|
||
- ajoute au résumé de fixture l’ATA, 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 l’ATA 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 l’adaptateur 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 l’IDL historique de 58 instructions, la matrice d’exé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 d’exécuter réellement la post-validation déjà déclarée par sa policy : hydratation canonique, extraction Core, replay, matérialisation et seconde passe d’idempotence ;
|
||
- 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 qu’une 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 n’exige 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 l’ordre 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 l’unique 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 l’inventaire de scénarios ;
|
||
- documente la crate du test d’API 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 l’orchestration 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 l’inventaire 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 l’appel résiduel à `ExSplTokenExecutor` dans la préparation native du mint Metaplex ;
|
||
- construit directement l’instruction officielle `spl_token_interface::instruction::initialize_mint2` ;
|
||
- ajoute cette instruction au plan composite `SystemCreateAccount + InitializeMint2` sans falsifier les exigences de post-validation de l’exé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 l’envoi et la confirmation, puis retourne sa valeur chaîne ;
|
||
- convertit la clé du mint en `MdPubkey` pour `getAccountInfo` ;
|
||
- supprime l’avertissement 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 l’inventaire 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 d’exécution et de titres explicites pour les résultats JSON Metaplex.
|
||
- Ajout d’un 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 l’assertion, un seul test échouant sur le code attendu.
|
||
|
||
## 0.4.7-pre.012-fix-002
|
||
|
||
- rejet explicite des placeholders `...` dans le JSON d’opé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 d’un constructeur de requête depuis le JSON typé `ExMetaplexTokenMetadataOperation` ;
|
||
- ajout d’un test Devnet opt-in piloté par variables d’environnement pour simuler ou soumettre n’importe quelle opération courante ;
|
||
- maintien des statuts réseau à `not_run` tant qu’aucune exécution locale n’a 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 d’un 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 d’une 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 qu’aucune preuve locale n’a é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 d’un corpus fermé couvrant outer/CPI, succès/échec, cinq familles d’actifs et neuf classes d’erreur ;
|
||
- 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 l’inventaire 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 d’API 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 d’exécution réelle ;
|
||
- classement des travaux d’autonomie 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.
|