v0.4.7-pre.016

This commit is contained in:
2026-08-05 11:29:43 +02:00
parent 40d831f84d
commit 1d1f57ae78
42 changed files with 493 additions and 1203 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: olddocs/archivekbot3/docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
<!-- version: 11 -->
<!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
<!-- version: 14 -->
# Plan `0.4.7` — achèvement de Metaplex Token Metadata
@@ -304,7 +304,7 @@ Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipelin
- envoi et postcondition uniquement avec fixture contrôlée ;
- statut réseau exact consigné par opération.
**Recommandation : Option B.** La version peut clôturer avec certaines opérations validées synthétiquement seulement, à condition que ce statut soit explicite et que leur exécution publique soit limitée en conséquence.
**Décision révisée : validation Devnet obligatoire pour la surface courante.** Les niveaux de preuve restent distincts, mais `0.4.7` ne peut plus être clôturée tant que les opérations `executable_current` n'ont pas été exercées sur Devnet par des scénarios réels. Les opérations `executable_deprecated` restent hors campagne réseau obligatoire et ne sont exécutées que dans une campagne séparée, volontaire et explicitement approuvée. Une impossibilité réseau démontrée doit être documentée opération par opération et ne peut pas être remplacée par une preuve synthétique.
## 7. Ordonnancement proposé par prerelease
@@ -484,7 +484,65 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
- matrice, tests, rapports et runtime alignés ;
- écarts résiduels fermés ou reportés explicitement.
### `0.4.7-pre.011` — clôture
### `0.4.7-pre.011` — infrastructure et premières campagnes Devnet réelles
**Dépendance** : exécuteur, pipeline, fixtures synthétiques et desktop stabilisés.
**Travaux**
- rouvrir la version après le rejet de la clôture prématurée ;
- produire une liste machine-readable fermée des 20 opérations `executable_current` ;
- définir pour chacune la fixture, les autorités, les fonds, les comptes préexistants, les effets attendus et la stratégie de nettoyage ;
- ajouter les primitives réutilisables de préparation de fixtures Devnet dans `kb-pipeline-demo-scenarios` ;
- exécuter réellement sur Devnet un premier lot cohérent couvrant au minimum création, mise à jour, vérification et révocation de vérification ;
- enregistrer endpoint/cluster, signature, slot, logs de simulation, résultat de soumission, états avant/après et postconditions ;
- interdire qu'un résultat synthétique puisse satisfaire un contrat de preuve réseau.
**Acceptation**
- le profil et la base Devnet sont chargés et vérifiés ;
- chaque scénario du premier lot effectue au minimum une simulation RPC réelle ;
- les scénarios mutateurs retenus effectuent une soumission réelle après garde-fou explicite ;
- les preuves sont persistées dans des résultats structurés et réutilisables ;
- aucune opération dépréciée n'est exécutée automatiquement.
### `0.4.7-pre.012` — couverture Devnet des opérations courantes restantes
**Travaux**
- compléter les campagnes automatisées pour toutes les opérations `executable_current` restantes ;
- couvrir les familles metadata, collections/créateurs, délégations, programmable NFT, éditions, uses, escrow et maintenance de comptes lorsque leurs préconditions sont disponibles ;
- créer ou réutiliser des fixtures NFT, SFT, fungible, collection et pNFT ;
- tester les échecs attendus : mauvaise autorité, mauvais PDA, owner invalide, rule set incohérent, comptes manquants et plafond de dépense ;
- conserver simulation-only par défaut, avec soumission activée uniquement par une option explicite de campagne ;
- consigner toute impossibilité Devnet démontrée avec cause externe précise, tentative reproductible et preuve associée.
**Acceptation**
- les 20 opérations `executable_current` ont chacune un scénario Devnet réel ;
- chaque opération possède une simulation RPC observée ou une impossibilité réseau démontrée et documentée ;
- chaque opération mutatrice réalisable possède au moins une soumission confirmée et une postcondition stateful observée ;
- les résultats ne dépendent pas du desktop et utilisent exclusivement les APIs généralistes de `kb-pipeline`.
### `0.4.7-pre.013` — démonstrations desktop Devnet et validation croisée finale
**Travaux**
- raccorder le panneau Metadata aux scénarios réseau réutilisables, sans déplacer leur logique métier dans Tauri ;
- conserver les scénarios UI dans `kb-app-demo-desktop` et les tests automatisés parallèles dans `kb-pipeline-demo-scenarios` ;
- afficher profil, cluster, base, wallet, fixture, mode simulation/soumission, signature, slot, logs et postconditions ;
- permettre l'exécution manuelle des opérations courantes retenues depuis le desktop avec confirmation opérateur ;
- comparer les résultats automatisés et desktop sur les mêmes contrats de preuve ;
- exécuter les validations croisées outer/CPI, succès/échec et replay PostgreSQL idempotent.
**Acceptation**
- le mode Devnet déclenche réellement les appels RPC et ne se limite jamais à changer un JSON frontend ;
- les scénarios desktop et automatisés produisent des preuves compatibles ;
- les 20 opérations courantes ont un statut réseau final exact ;
- les opérations dépréciées restent clairement séparées et désactivées par défaut.
### `0.4.7-pre.014` — clôture
**Travaux**
@@ -493,13 +551,14 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
- documentation générale et des crates ;
- nettoyage des TODO, outils temporaires et références obsolètes ;
- archivage du présent plan et des rapports devenus historiques ;
- prompt `0.4.8` avec prerelease initiale de planification et prerelease finale de clôture ;
- préparation seulement à ce stade du prompt `0.4.8`, avec prerelease initiale de planification et prerelease finale de clôture ;
- livraison finale.
**Acceptation**
- commandes de validation finales réussies ;
- code, matrices, registres, bindings et documentation alignés ;
- preuves Devnet des opérations courantes alignées avec code, matrices, registres, bindings et documentation ;
- aucun cas `executable_current` laissé avec un statut réseau ambigu ;
- archive finale conforme aux règles du workspace.
## 8. Dépendances et ordre critique
@@ -513,8 +572,9 @@ Lordre critique est :
5. pipeline stateful ;
6. fixtures et validations automatisées Devnet/Testnet ;
7. scénarios UI desktop ;
8. validation croisée ;
9. clôture.
8. campagnes Devnet réelles automatisées ;
9. démonstrations desktop Devnet et validation croisée finale ;
10. clôture.
Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou lenvoi dune opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce quun builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
@@ -573,7 +633,7 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
4. rule sets programmables fail-closed ;
5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
6. séquence de prereleases `pre.002` à `pre.011` décrite ci-dessus.
6. séquence de prereleases `pre.002` à `pre.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
## État de `0.4.7-pre.007`
@@ -601,3 +661,20 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
- affichage des exigences de préflight, simulation-first et postconditions ;
- scénario sélectionné restauré à la réouverture ;
- aucune logique métier dupliquée et aucune soumission automatique.
## État de `0.4.7-pre.011`
- matrice fermée des 20 opérations courantes ;
- runner Devnet réel générique avec simulation RPC, soumission contrôlée, confirmation et lectures stateful avant/après ;
- premier lot attribué à `Create`, `Update`, `Verify` et `Unverify` ;
- preuves réseau encore `not_run` jusquaux exécutions locales et à la validation des postconditions métier ;
- opérations dépréciées refusées dans les campagnes automatiques.
## État de `0.4.7-pre.012`
- le runner RPC réutilisable accepte les 20 opérations `executable_current` ;
- la matrice ne contient plus aucune opération au statut `planned` ;
- un test opt-in permet de fournir lintent typé et les lectures stateful par JSON ;
- les statuts réseau restent `not_run` jusquaux campagnes locales avec fixtures ;
- la préparation des fixtures et la collecte des preuves observées restent obligatoires avant `pre.013`.

View File

@@ -0,0 +1,82 @@
<!-- file: docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md -->
<!-- version: 2 -->
# Rapport de validation Devnet — `0.1.0-pre.062`
## Portée
Ce rapport clôt la campagne Devnet exécutée sur une base PostgreSQL propre, sans réinitialisation entre les scénarios.
- profil : `local_devnet` ;
- RPC : `https://api.devnet.solana.com` ;
- genesis hash : `EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG` ;
- wallet opérateur : `J12WA6c42oqpWkLu1dFa4pCegkQJPpxabwc3RRCMSUuH` ;
- preuves locales : `/tmp/devnet-validation/pre.062-clean` ;
- CLI observées : `solana-cli 4.0.2`, `solana-keygen 4.0.2`, `spl-token-cli 5.5.0` ;
- PostgreSQL : 13 tables sur 13 disponibles.
## Scénarios validés
| Code | Surface | Opération | Signature | Slot | Statut |
|-------|---------------------|------------------|--------------------------------------------------------------------------------------------|------------:|----------|
| S01 | Solana Core | System Transfer | preuve locale de campagne | — | validé |
| S02 | SPL Memo v4 | Memo v4 | `3LJN8URRqvCJcjKMEpHmdVcJXsQHFMDc5cUiSCE4MkCsieqtPDXB39ReyzZ3oGh9WGTTaVT4ew5NPju8AWCzsUAk` | `479794063` | finalisé |
| S03A | ATA classique | CreateIdempotent | `5ugba9K7NHN8vUsDnxhBGM37n3UsBsaX56B1ccrH3j64BbSgYcrxT1fsV5Z98waeyquYyxi46w4AENgrdhPucedn` | `479803680` | finalisé |
| S03B | ATA Token-2022 | CreateIdempotent | `4Cv8p6bB2iqc1qRJDxhVgjGtriPx1Ji3F7AirqXPRUmCLVLCDhtQPLTipWgigGVSDTLSsrvz3mZtnNPe5GQwuUWG` | `479805232` | finalisé |
| S04 | SPL Token classique | TransferChecked | `4ghND4BHUxVhCgRfKbZgtLHKV1f3VrF3XVXqSjCawT4dX2qEAHsRTKsDvHod9xKeNQE7HrHCZmPY4D9e8XENY7XT` | `479828478` | finalisé |
| S05.1 | Token-2022 | MintToChecked | `3hdeszJNUdopzVNiBUSXLb7GYbuRJgQjVmXo9Rc6UUguWcuS3DcxeDGaVTxCsuuTA2uM5f6cKbJRkmYobU2FdkPX` | `479925764` | finalisé |
| S05.2 | Token-2022 | TransferChecked | `5nx6eGR44AexrgSutBo8CvrpdDVCwgA3YcPrXomnBwPpKqBB3WcbZuNxy8H6AryKj3d4dF5kszKsvUYGx5qSzNPY` | `479926573` | finalisé |
| S05.3 | Token-2022 | ApproveChecked | `2QLSCz3FqimxPqxFSGyiJtHJAJoFAoRxTsQPnageetGYZcMdtH3CprByPV4ho33xGAn1wTERkwJ56JQcBbSabYYn` | `479926994` | finalisé |
| S05.4 | Token-2022 | Revoke | `3WjYXTMH8h7WAhpG641UHFGC3PfSYKZBHrnQuFJxsJ1agDq8BS7BfmKzXB1ciF3LKtLndRog4HiDybJ41EmTDgwC` | `479927342` | finalisé |
| S05.5 | Token-2022 | BurnChecked | `4qRMULuArbjfnbqqqgpbs1AdVHA5XLZkxSA1h8M3BnkTjRCXNA7rDbGhNhMBc2GCoYeYyKmfT1YCPxySfYp67Rhz` | `479927657` | finalisé |
| S05.6 | Token-2022 | FreezeAccount | `4E5GuHkRQjRJNCnr1WgMk9c4XYEu2qpH1KibrQcj1dK5wa1x9Jh3RTCxqYh63EZtbMB9JeK9F5SMcP6TqQm1pT4R` | `479927943` | finalisé |
| S05.7 | Token-2022 | ThawAccount | `37D9d14hHpkBSj8WbKc4wtKssNhMzfTrXUANwvt8xZ3VypSZe43MxtEm2u7RHkdBhUVfms7vsuE5gjAfmREAXMJ2` | `479928232` | finalisé |
| S05.8 | Token-2022 | CloseAccount | `3rarADrqnYkmGBFsNYCABE2WCKoE9KcP7d2bsqZDCn7pjLwHFKnjw7w3h1hMa3aWodXfcZz7DDCqgzvMamuS4AHP` | `479928489` | finalisé |
## Invariants vérifiés
Pour les scénarios applicatifs S02 à S05 concernés, les sorties ont confirmé selon la surface :
- simulation exacte réussie ;
- confirmation réseau ;
- insertion canonique ;
- extraction Core ;
- replay de décodage sans échec ;
- matérialisation attendue ;
- second replay idempotent ;
- séparation correcte entre SPL Token classique, ATA et Token-2022.
La fixture Token-2022 est générée par une commande idempotente :
```bash
cargo run -p kb-pipeline-demo-scenarios --bin kb-pipeline-demo-scenarios-cli -- prepare-token-2022-fixture --rpc-url "$KB_DEVNET_RPC_URL" --wallet "$KB_DEVNET_WALLET" --wallet-dir "$PWD/wallets/temporary/local_devnet" --decimals 9
```
Le second passage a retourné `fixture_written=false`, sans recréer les comptes.
## Surface reportée
Le registre ElGamal nest pas validé dans `pre.062`.
Motifs :
- absence dun générateur de compte de contexte de preuve `PubkeyValidity` ;
- panneau desktop Registry non raccordé à un handler et à une commande Tauri complète.
Le code existant ne doit pas être présenté comme validé Devnet avant une campagne dédiée.
## État avant commit
La prerelease est commitable lorsque les commandes suivantes restent propres dans le workspace utilisateur :
```bash
cargo fmt --all
cargo check --workspace
cargo test -p kb-pipeline-demo-scenarios
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
```
Le user a confirmé Clippy et laudit après ajout manuel de deux `return` manquants dans des closures `or_else`. Ces corrections locales doivent être incluses dans le commit.
La refonte générale de `README.md`, `ROADMAP.md`, `CHANGELOG.md` et des documents historiques est volontairement reportée à la phase suivante ; ce rapport ne prétend pas la remplacer.

View File

@@ -0,0 +1,94 @@
<!-- file: docs/validation/V0_4_7_PRE_002_METAPLEX_COVERAGE_AND_FACT_OWNERSHIP.md -->
<!-- version: 2 -->
# `0.4.7-pre.002` — couverture Metaplex et propriété des faits
## Résultat corrigé
Le contrat couvre les 58 discriminants `0..57` sans trou. La classification a été corrigée pendant `pre.003` après confrontation avec les recommandations de dépréciation officielles de Metaplex : une instruction encore décodable dans lIDL historique nest pas nécessairement légitime à reconstruire.
- `decode_only_bridge_boundary` : 1 ;
- `decode_only_obsolete` : 15 ;
- `decode_only_replaced` : 22 ;
- `executable_current` : 20.
Les 20 opérations courantes doivent toutes posséder un intent et un builder à la fin de `pre.006`. Les instructions remplacées ou obsolètes restent décodées et peuvent produire les faits stables prouvés, mais leur reconstruction est interdite.
## Contrat par instruction
| Disc. | Instruction | Statut | Exécution | Cible | Signers IDL |
|------:|-------------------------------------------------------------|-------------------------------|------------------------------------|-----------|---------------------------------------------------------------------------------------------------------|
| 0 | `CreateMetadataAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
| 1 | `UpdateMetadataAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority |
| 2 | `DeprecatedCreateMasterEdition` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority, printingMintAuthority, mintAuthority, payer, oneTimePrintingAuthorizationMintAuthority |
| 3 | `DeprecatedMintNewEditionFromMasterEditionViaPrintingToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | mintAuthority, burnAuthority, payer |
| 4 | `UpdatePrimarySaleHappenedViaToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner |
| 5 | `DeprecatedSetReservationList` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | resource |
| 6 | `DeprecatedCreateReservationList` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | payer, updateAuthority |
| 7 | `SignMetadata` | `decode_only_replaced` | `forbidden_replaced` | `—` | creator |
| 8 | `DeprecatedMintPrintingTokensViaToken` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | burnAuthority |
| 9 | `DeprecatedMintPrintingTokens` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority |
| 10 | `CreateMasterEdition` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, mintAuthority, payer |
| 11 | `MintNewEditionFromMasterEditionViaToken` | `decode_only_replaced` | `forbidden_replaced` | `—` | newMintAuthority, payer, tokenAccountOwner |
| 12 | `ConvertMasterEditionV1ToV2` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | aucun |
| 13 | `MintNewEditionFromMasterEditionViaVaultProxy` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | newMintAuthority, payer, vaultAuthority |
| 14 | `PuffMetadata` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | aucun |
| 15 | `UpdateMetadataAccountV2` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority |
| 16 | `CreateMetadataAccountV2` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
| 17 | `CreateMasterEditionV3` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, mintAuthority, payer |
| 18 | `VerifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
| 19 | `Utilize` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | useAuthority |
| 20 | `ApproveUseAuthority` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner, payer |
| 21 | `RevokeUseAuthority` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | owner |
| 22 | `UnverifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority |
| 23 | `ApproveCollectionAuthority` | `decode_only_replaced` | `forbidden_replaced` | `—` | updateAuthority, payer |
| 24 | `RevokeCollectionAuthority` | `decode_only_replaced` | `forbidden_replaced` | `—` | revokeAuthority |
| 25 | `SetAndVerifyCollection` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
| 26 | `FreezeDelegatedAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | delegate |
| 27 | `ThawDelegatedAccount` | `decode_only_replaced` | `forbidden_replaced` | `—` | delegate |
| 28 | `RemoveCreatorVerification` | `decode_only_replaced` | `forbidden_replaced` | `—` | creator |
| 29 | `BurnNft` | `decode_only_replaced` | `forbidden_replaced` | `—` | owner |
| 30 | `VerifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
| 31 | `UnverifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
| 32 | `SetAndVerifySizedCollectionItem` | `decode_only_replaced` | `forbidden_replaced` | `—` | collectionAuthority, payer |
| 33 | `CreateMetadataAccountV3` | `decode_only_replaced` | `forbidden_replaced` | `—` | mintAuthority, payer |
| 34 | `SetCollectionSize` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | collectionAuthority |
| 35 | `SetTokenStandard` | `decode_only_obsolete` | `forbidden_obsolete` | `—` | updateAuthority |
| 36 | `BubblegumSetCollectionSize` | `decode_only_bridge_boundary` | `forbidden_cross_program_boundary` | `—` | collectionAuthority, bubblegumSigner |
| 37 | `BurnEditionNft` | `decode_only_replaced` | `forbidden_replaced` | `—` | owner |
| 38 | `CreateEscrowAccount` | `executable_current` | `required` | `pre.006` | payer, authority |
| 39 | `CloseEscrowAccount` | `executable_current` | `required` | `pre.006` | payer |
| 40 | `TransferOutOfEscrow` | `executable_current` | `required` | `pre.006` | payer, authority |
| 41 | `Burn` | `executable_current` | `required` | `pre.005` | authority |
| 42 | `Create` | `executable_current` | `required` | `pre.003` | authority, payer |
| 43 | `Mint` | `executable_current` | `required` | `pre.006` | authority, payer |
| 44 | `Delegate` | `executable_current` | `required` | `pre.005` | authority, payer |
| 45 | `Revoke` | `executable_current` | `required` | `pre.005` | authority, payer |
| 46 | `Lock` | `executable_current` | `required` | `pre.005` | authority, payer |
| 47 | `Unlock` | `executable_current` | `required` | `pre.005` | authority, payer |
| 48 | `Migrate` | `executable_current` | `required` | `pre.006` | payer, authority |
| 49 | `Transfer` | `executable_current` | `required` | `pre.005` | authority, payer |
| 50 | `Update` | `executable_current` | `required` | `pre.003` | authority, payer |
| 51 | `Use` | `executable_current` | `required` | `pre.006` | authority, payer |
| 52 | `Verify` | `executable_current` | `required` | `pre.004` | authority |
| 53 | `Unverify` | `executable_current` | `required` | `pre.004` | authority |
| 54 | `Collect` | `executable_current` | `required` | `pre.006` | authority |
| 55 | `Print` | `executable_current` | `required` | `pre.006` | editionMintAuthority, payer |
| 56 | `Resize` | `executable_current` | `required` | `pre.006` | authority |
| 57 | `CloseAccounts` | `executable_current` | `required` | `pre.005` | authority |
## Propriété des faits
La matrice contient 26 faits à propriétaire unique. Les domaines Metaplex et Token-2022 embedded restent séparés.
## Validations exécutées par lopérateur pour `pre.002`
```text
cargo fmt --all OK
cargo check --workspace OK
cargo clippy --all-targets OK
python3 scripts/audit_rust_workspace_rules.py clean
cargo test -p kb-lib 627 + 4 tests OK
```
La classification corrigée et le code de `pre.003` doivent être revalidés avant acceptation.

View File

@@ -0,0 +1,58 @@
<!-- file: docs/validation/V0_4_7_PRE_003_METAPLEX_EXECUTOR_FOUNDATIONS.md -->
<!-- version: 3 -->
# `0.4.7-pre.003` — fondations de lexécuteur Metaplex
## Portée
Cette prerelease remplace la frontière réservée de lexécuteur Metaplex Token Metadata par une surface typée initiale comprenant :
- `Create`, discriminant `42`, avec `CreateArgs::V1` ;
- `Update`, discriminant `50`, avec `UpdateArgs::AsUpdateAuthorityV2` ;
- `PuffMetadata`, discriminant `14`, exécutable dépréciée ;
- `SetTokenStandard`, discriminant `35`, exécutable dépréciée.
Les autres variantes du wrapper `Update` restent planifiées selon leurs domaines dautorité. Les anciennes instructions create/update remplacées restent decode-only et pointent vers leur wrapper canonique final.
## Contrats introduits
- intents typés et codes dopération stables ;
- `#[deprecated]` sur les variantes Rust obsolètes ;
- approbation opérateur runtime obligatoire pour toute opération dépréciée ;
- builders officiels `mpl-token-metadata 5.1.x` ;
- validation des PDA metadata et edition ;
- comptes et signers exacts dérivés de linstruction construite ;
- simulation obligatoire et dry-run imposé pour cette première tranche ;
- plafonds positifs de frais et de dépense ;
- paire complète obligatoire pour les comptes Token Authorization Rules ;
- autorisation explicite de chaque signer requis ;
- erreurs fail-closed avant production du plan préparé.
## Classification corrigée
- 20 instructions courantes et constructibles ;
- 15 instructions obsolètes mais constructibles, classées `executable_deprecated` ;
- 22 instructions remplacées par leur version canonique finale ;
- 1 frontière Bubblegum.
`pre.003` implémente les deux opérations courantes de sa tranche et les deux opérations obsolètes qui lui sont affectées. Les autres opérations dépréciées sont réparties jusquà `pre.006`.
## Validation attendue
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-lib
```
Cargo nest pas disponible dans lenvironnement de préparation. Les validations Rust doivent être exécutées par lopérateur avant acceptation.
## Correctif de conformité `fix-002`
- la dépendance directe `solana-program` introduite par `pre.003` est retirée ;
- les contrats internes reposent sur `solana_instruction::Instruction` et `solana_pubkey::Pubkey` ;
- les types historiques internes de `mpl-token-metadata 5.1.1` sont laissés à linférence puis convertis immédiatement, sans fuite dans lAPI de `kb-lib` ;
- tous les usages de lopérateur `?` introduits dans le builder et le dispatcher Metaplex sont remplacés par une propagation explicite des erreurs ;
- les TODO de réaudit des exécuteurs Solana Core/SPL et de lorchestration pipeline sont enregistrés pour une version ultérieure à déterminer.

View File

@@ -0,0 +1,23 @@
<!-- file: docs/validation/V0_4_7_PRE_004_METAPLEX_COLLECTIONS_CREATORS_AUTHORITIES.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.004` — collections, créateurs et autorités
## Surface livrée
- wrappers courants `Verify` et `Unverify` ;
- variantes `CreatorV1` et `CollectionV1` ;
- opération dépréciée `SetCollectionSize` avec approbation explicite ;
- validation des combinaisons de comptes et des PDA collection metadata/master edition ;
- anciennes instructions remplacées conservées en decode-only.
## Validation de préparation
- audit Rust général : à exécuter ;
- audit des exports : à exécuter ;
- `cargo fmt --all` : à exécuter localement ;
- `cargo check --workspace` : à exécuter localement ;
- `cargo clippy --all-targets` : à exécuter localement ;
- `cargo test -p kb-lib` : à exécuter localement.
Aucune validation réseau n'est déclarée dans cette prerelease.

View File

@@ -0,0 +1,26 @@
<!-- file: docs/validation/V0_4_7_PRE_006_METAPLEX_EXECUTOR_CLOSURE.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.006` — fermeture de lexécuteur Metaplex
## Résultat contractuel
- 58 discriminants classés sans état ouvert ;
- 20 opérations courantes avec intent et builder ;
- 15 opérations obsolètes officiellement constructibles avec `#[deprecated]` et approbation opérateur explicite ;
- 22 versions remplacées conservées en decode-only avec remplacement canonique ;
- 1 frontière Bubblegum sans builder Metaplex ;
- aucune opération officiellement constructible reportée après `pre.006`.
## Construction
Les opérations restantes utilisent le contrat de comptes positionnels de lIDL archivée et les types darguments Borsh officiels de `mpl-token-metadata 5.1.1`. Les signers et flags writable sont conservés exactement dans les `AccountMeta`.
## Contrôles de préparation
- matrice JSON lisible et fermée ;
- audit Rust général propre ;
- audit de complétude des exports propre ;
- absence de `?`, `unwrap`, `expect` et `panic!` dans la surface Metaplex ajoutée.
Les commandes Cargo doivent être exécutées sur le workspace opérateur avant validation définitive de la prerelease.

View File

@@ -0,0 +1,21 @@
<!-- file: docs/validation/V0_4_7_PRE_007_METAPLEX_PIPELINE_GENERALISTE.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.007` — pipeline généraliste Metaplex
## Contrats introduits
- lectures RPC `confirmed` bornées pour metadata, edition et token record ;
- validation owner, taille, contexte, PDA et décodage délégué à `kb-lib` ;
- préflight des plans Metaplex, corrélation bornée et approbation des opérations dépréciées ;
- orchestration liée au hash exact de simulation ;
- résolution complète des signers et blocage du send en dry-run ;
- postconditions `confirmed`, `contradicted` et `not_applicable` sans succès inventé.
## Frontière
`kb-pipeline` reste généraliste et ne dépend pas de `kb-pipeline-demo-scenarios`. Les fixtures et campagnes Devnet/Testnet sont reportées à `pre.008`.
## Validation de préparation
Les audits statiques doivent être exécutés dans lenvironnement de préparation. Les commandes Cargo doivent être exécutées sur le workspace local, car `cargo` nest pas disponible ici.

View File

@@ -0,0 +1,30 @@
<!-- file: docs/validation/V0_4_7_PRE_008_METAPLEX_SYNTHETIC_AND_NETWORK_VALIDATION.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.008` — scénarios Metaplex
## Couverture
- NFT ;
- SFT ;
- token fongible ;
- collection ;
- programmable NFT.
## Contrats
Les scénarios synthétiques sont déterministes et simulation-safe. La matrice réseau distingue `not_run`, `synthetic_validated`, `simulated`, `submitted`, `confirmed`, `unavailable` et `failed`. Aucun statut réseau nest déclaré sans preuve observée.
## CLI
Aucune nouvelle commande nest ajoutée : le CLI reste destiné à la préparation Token-2022 tant quune fixture Metaplex dédiée nest pas nécessaire.
## Validation locale à exécuter
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-pipeline-demo-scenarios
```

View File

@@ -0,0 +1,37 @@
<!-- file: docs/validation/V0_4_7_PRE_009_METAPLEX_DESKTOP.md -->
<!-- version: 3 -->
# Validation `0.4.7-pre.009` — desktop Metaplex Token Metadata
## Périmètre
La prerelease ajoute la fenêtre Tauri `demo_execution_metadata` et adapte les inventaires synthétiques et Devnet de `kb-pipeline-demo-scenarios`.
## État constaté après `fix-001`
Le panneau changeait uniquement les contrats JSON affichés. Il ne chargeait aucun profil Devnet, ne préparait aucune base PostgreSQL et n'appelait aucune commande de simulation ou de soumission Metaplex. La présence de scénarios marqués `network_simulation` ne constituait donc pas une validation réseau.
## Correction `fix-002`
- ajout du choix d'un profil Devnet compatible ;
- réutilisation de la commande commune `demo_execution_solana_core_options` pour charger les profils ;
- réutilisation de `demo_execution_devnet_prepare_profile` pour vérifier ou initialiser réellement la base PostgreSQL du profil ;
- affichage du rapport de préparation de la base avec le JSON viewer commun ;
- ajout explicite de `networkExecutionPerformed: false` et `networkEvidenceCollected: false` dans les résultats tant qu'aucune transaction Metaplex n'est simulée ;
- suppression de toute présentation des contrats Devnet comme preuve de simulation réseau ;
- conservation des scénarios synthétiques de démonstration.
## Limite restante
`fix-002` corrige le faux raccordement Devnet et restaure le chargement du profil et de la base. Il n'ajoute pas encore l'orchestration complète d'une transaction Metaplex Devnet. `pre.009` ne peut donc pas être déclarée validée sur réseau tant que le desktop n'appelle pas un scénario d'exécution réel produisant au minimum une simulation RPC, un slot et les postconditions correspondantes.
## Validation locale
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-app-demo-desktop
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
```

View File

@@ -0,0 +1,72 @@
<!-- file: docs/validation/V0_4_7_PRE_010_METAPLEX_CROSS_VALIDATION.md -->
<!-- version: 2 -->
# Validation `0.4.7-pre.010` — corpus croisé Metaplex Token Metadata
## Objet
Cette prerelease ferme le corpus de validation croisée sans ajouter une nouvelle capacité dexécution. Elle vérifie lalignement entre décodeur, matérialisation, exécuteur, pipeline, scénarios réutilisables et desktop.
## Corpus machine-readable
`test-fixtures/contract-matrices/METAPLEX_TOKEN_METADATA_CROSS_VALIDATION_MATRIX.json` contient 19 cas :
- chemins outer et CPI ;
- transactions réussies et échouées ;
- NFT, SFT, token fongible, collection et programmable NFT ;
- mauvais Program ID, owner, PDA et comptes ;
- payload tronqué, suffixe interdit et discriminant inconnu ;
- conflit Metaplex/metadata Token-2022 ;
- contrats séparés de simulation, soumission et postcondition Devnet.
## Exactitude des preuves réseau
Les trois cas réseau restent `not_run` sans preuve. Le validateur interdit de les promouvoir avec le statut `synthetic_validated` et exige toutes les catégories de preuves prévues avant `simulated`, `submitted` ou `confirmed`.
Le panneau desktop `pre.009-fix-002` charge le profil et prépare la base Devnet, mais nexécute pas encore une transaction Metaplex. Cette préparation nest donc pas comptée comme validation réseau.
## Validation locale exécutée le 2 août 2026
Les commandes suivantes ont été exécutées sur le workspace local `0.4.7-pre.10` :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-pipeline-demo-scenarios
cargo test -p kb-lib
cargo test -p kb-pipeline
cargo test -p kb-app-demo-desktop
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
```
Résultats observés :
- `cargo fmt --all` : succès ;
- `cargo check --workspace` : succès sur les onze crates ;
- `cargo clippy --all-targets` : succès ;
- audit Rust général : propre ;
- complétude des exports : `0 candidate(s)` ;
- audit Khadhroony : propre ;
- `kb-pipeline-demo-scenarios` : 47 tests de bibliothèque et 1 test du binaire réussis ;
- `kb-lib` : 641 tests unitaires et 4 tests dintégration réussis ;
- `kb-pipeline` : 92 tests réussis ;
- `kb-app-demo-desktop` : 120 tests réussis ;
- lancement Tauri : application démarrée et panneau Metadata ouvert.
## Archive dobservation `mainnet_research`
Larchive `mainnet_research.v0.4.7-pre.010-01.zip` prouve les éléments suivants :
- démarrage du desktop avec le profil actif `mainnet_research` ;
- chargement de trois profils configurés ;
- initialisation ou vérification des treize tables PostgreSQL attendues ;
- ouverture de la fenêtre `demo_execution_metadata` ;
- absence derreur applicative ou Rust dans les journaux fournis.
Cette archive ne contient toutefois aucune signature, aucun slot de simulation Metaplex, aucun log `simulateTransaction` et aucune preuve de postcondition réseau. Elle valide donc le démarrage applicatif, le profil et la préparation PostgreSQL, mais pas une simulation ou une soumission Metaplex sur Mainnet.
## Statut de `pre.010`
La validation locale du code et des contrats est réussie. Les trois cas de preuve réseau de la matrice restent `not_run` jusquà production des artefacts réseau exigés. Cette absence de preuve nempêche pas la validation de la prerelease de consolidation, mais interdit toute déclaration de validation réseau Metaplex.

View File

@@ -0,0 +1,25 @@
<!-- file: docs/validation/V0_4_7_PRE_011_DEVNET_REOPENING.md -->
<!-- version: 1 -->
# `0.4.7-pre.011` — réouverture pour validation Devnet
## Décision
La clôture préparée dans le delta initial `pre.011` est rejetée. La présence d'un profil Devnet et l'affichage de résultats structurés ne constituent pas une exécution réseau.
## Exigence de sortie
Les 20 opérations classées `executable_current` dans la matrice Metaplex doivent disposer d'un scénario Devnet réel dans `kb-pipeline-demo-scenarios`. Chaque scénario doit produire des preuves RPC vérifiables. Les opérations réalisables avec une fixture contrôlée doivent également produire une soumission confirmée et une postcondition stateful.
Les opérations `executable_deprecated` ne font pas partie de la campagne obligatoire. Elles restent désactivées par défaut et nécessitent une approbation explicite.
## Nouvelle séquence
- `pre.011` : infrastructure et premier lot Devnet ;
- `pre.012` : couverture des opérations courantes restantes ;
- `pre.013` : démonstrations desktop Devnet et validation croisée finale ;
- `pre.014` : clôture.
## Documents réactivés
Le plan `0.4.7`, le prompt de session et les rapports de prerelease redeviennent actifs. Le rapport de clôture et le prompt `0.4.8` préparés prématurément doivent être supprimés jusqu'à la vraie clôture.

View File

@@ -0,0 +1,31 @@
<!-- file: docs/validation/V0_4_7_PRE_011_DOCUMENTATION_REORGANIZATION.md -->
<!-- version: 1 -->
# `0.4.7-pre.011` — réorganisation documentaire
## Objet
Corriger les documents désordonnés après la réouverture de `0.4.7` et replacer chaque information dans le document qui en est propriétaire.
## Règles appliquées
- `README.md` décrit le périmètre, les responsabilités, la surface et les limites durables ;
- `USAGE.md` documente les APIs et parcours réellement utilisables ;
- `TODO.md` ne contient que des tâches ouvertes, vérifiables et supprimables ;
- `CHANGELOG.md` retrace les changements effectivement intégrés ;
- `ROADMAP.md` reste limité aux versions fonctionnelles, sans journal de prerelease.
## Corrections
- retrait des entrées fonctionnelles `0.4.7` prématurées des changelogs de crates ;
- regroupement des correctifs `pre.009` dans lentrée de prerelease correspondante ;
- suppression des tâches terminées des TODO ;
- suppression de la tâche erronée demandant de déplacer les scénarios UI hors du desktop ;
- déplacement des campagnes réseau vers les TODO de `kb-pipeline-demo-scenarios` et du desktop ;
- ajout dune section dutilisation Metaplex dans `kb-lib/USAGE.md` ;
- remplacement des sections Metadata incomplètes du guide desktop par le comportement réellement disponible ;
- mise à jour des README pour refléter la clôture repoussée à `pre.014`.
## Statut
Ce correctif est documentaire. Il ne déclare aucune simulation, soumission ou postcondition Metaplex Devnet supplémentaire.

View File

@@ -0,0 +1,43 @@
<!-- file: docs/validation/V0_4_7_PRE_011_METAPLEX_DEVNET_INFRASTRUCTURE.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.011` — infrastructure Devnet Metaplex
## Périmètre livré
- exécuteur Devnet réel pour un intent Metaplex courant ;
- refus systématique des opérations dépréciées dans les campagnes automatiques ;
- contrôle du cluster par genesis hash ;
- chargement du wallet persistant du profil ;
- lectures stateful bornées avant simulation et après confirmation ;
- préflight lié au plan exact ;
- compilation de la transaction, estimation des frais et simulation RPC exacte ;
- soumission uniquement après option et confirmation opérateur explicites ;
- confirmation de transaction et collecte des états après exécution ;
- matrice fermée des 20 opérations courantes.
## Premier lot
Les opérations suivantes sont attribuées à `pre.011` :
- `create` ;
- `update` ;
- `verify` ;
- `unverify`.
Linfrastructure est implémentée, mais aucune preuve réseau nest déclarée dans ce livrable. Les quatre opérations restent `not_run` jusquà lexécution locale avec des fixtures Devnet valides.
## Limites connues
Le runner utilise uniquement le wallet du profil. Un scénario exigeant un autre signer doit préparer sa fixture afin que toutes les autorités requises correspondent à ce wallet, ou introduire ultérieurement un contrat borné de signers supplémentaires.
La présence détats avant/après ne constitue pas à elle seule une postcondition réussie. Chaque scénario doit encore comparer les champs métier attendus et reporter le résultat dans sa preuve.
## Validations de préparation
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
```
Laudit Khadhroony ne peut pas vérifier la résolution épinglée de `wincode`, car la copie archivée ne contient pas `Cargo.lock`. Les commandes Cargo et les appels Devnet doivent être exécutés dans le workspace local avant validation de la prerelease.

View File

@@ -0,0 +1,54 @@
<!-- file: docs/validation/V0_4_7_PRE_012_METAPLEX_DEVNET_RUNNER_COVERAGE.md -->
<!-- version: 4 -->
# Validation `0.4.7-pre.012` — couverture du runner Devnet Metaplex
## Résultat
La matrice Devnet couvre exactement les 20 opérations `executable_current`. Les quatre opérations du premier lot restent attribuées à `pre.011` et les seize restantes à `pre.012`. Toutes portent désormais `runnerStatus: implemented`.
## Accès aux campagnes
`DevnetMetaplexTokenMetadataExecutionRequest::from_operation_json` désérialise une opération typée, rejette les opérations dépréciées et produit une requête simulation-only. Le test opt-in `optional_devnet_current_operation_from_env` permet une simulation RPC réelle ou une soumission explicitement confirmée.
## Correctif de compilation
Le contrat `MetaplexTokenMetadataStatefulReadRequest` dérive désormais `Deserialize` et `Serialize`. Les listes JSON fournies par `KB_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` et `KB_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` peuvent donc être chargées par le test opt-in. Un test de round-trip JSON protège ce contrat.
## Statut réseau
Aucune preuve réseau nest inventée dans ce livrable. Les 20 opérations restent `not_run` jusquà exécution locale avec fixtures, endpoint Devnet, wallet et préconditions compatibles.
## Validations à exécuter localement
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-pipeline-demo-scenarios
```
## Correctif ergonomique `fix-002`
Le placeholder `{"operation":"..."}` n'est plus présenté comme exécutable et est rejeté avec une erreur dédiée. La crate expose désormais :
- l'inventaire des vingt opérations courantes ;
- des modèles JSON pour `Create`, `Update`, `Verify` et `Unverify` ;
- des constructeurs nommés pour `Verify` et `Unverify` créateur ;
- des tests vérifiant la validité JSON des modèles et le caractère conservateur des requêtes nommées.
Les modèles utilisent des valeurs entre chevrons qui doivent être remplacées par des comptes Devnet réels. Ils ne constituent pas une preuve réseau.
## Correctif de dépendance et dassertion `fix-003`
La crate déclare désormais explicitement `mpl-token-metadata.workspace = true`, nécessaire aux types utilisés directement par les modèles de campagnes. Le test de rejet du placeholder attend le code stable `config`, conformément au contrat de `kb_core::Error::config`.
Validations opérateur observées avant ce correctif :
- `cargo fmt --all` : réussi ;
- `cargo check --workspace` : réussi ;
- `cargo clippy --all-targets` : réussi ;
- audit général, exports et règles Khadhroony : propres ;
- `cargo test -p kb-pipeline-demo-scenarios` : 53 tests réussis et un seul échec limité à lassertion `configuration_error` au lieu de `config`.

View File

@@ -0,0 +1,125 @@
<!-- file: docs/validation/V0_4_7_PRE_013_METAPLEX_DESKTOP_DEVNET_EXECUTION.md -->
<!-- version: 8 -->
# Validation `0.4.7-pre.013` — exécution Metadata Devnet desktop
## Périmètre
- adaptateurs Tauri minces vers `kb-pipeline-demo-scenarios` ;
- inventaire des 20 opérations courantes ;
- modèles JSON typés disponibles pour les parcours nommés ;
- simulation RPC Devnet réelle par défaut ;
- soumission uniquement avec `submit` et `operatorConfirmed` ;
- affichage distinct du plan, du préflight, de la simulation et des preuves stateful ;
- maintien des scénarios synthétiques.
## Contrats de sécurité
- profil obligatoirement classé Devnet ;
- opérations dépréciées rejetées par le runner réutilisable ;
- intent et lectures stateful désérialisés côté Rust ;
- une campagne Devnet déjà active bloque une seconde exécution ;
- aucune preuve réseau nest produite par les scénarios synthétiques.
## Correctif `pre.013-fix-001`
- correction de la conversion de `MdSignature` vers la chaîne UI en lisant explicitement la valeur du newtype ;
- aucun changement du contrat réseau, du runner ou des DTO ;
- compilation et validations locales à rejouer après application.
## Validation locale attendue
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test -p kb-app-demo-desktop
cargo test -p kb-pipeline-demo-scenarios
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
```
La validation manuelle doit remplacer les placeholders par des comptes Devnet réels, lancer une simulation puis, pour un parcours maîtrisé, une soumission explicitement confirmée. Les signatures, slots et postconditions doivent être conservés comme preuves avant la clôture.
## Correctif guide, fixture Create et profils Devnet
- ajout du guide intégré et du journal dexécution dans le panneau Metadata ;
- ajout des titres des blocs JSON ;
- ajout du préparateur de fixture `Create` avec mint SPL classique et PDA dérivés ;
- ajout des dépendances directes `mpl-token-metadata` et `solana-pubkey` dans `kb-pipeline-demo-scenarios` ;
- chargement des profils via une commande Metadata dédiée ;
- préparation automatique du profil sélectionné, comme dans les panneaux Solana Core et SPL ;
- diagnostic explicite lorsquaucun profil Devnet compatible nest retourné.
## Correctif dinitialisation frontend
- les listes de profils, contrats et opérations restaient vides parce que linitialisation `DOMContentLoaded` échouait avant les appels Tauri ;
- le TypeScript attendait `clearMetadataLogButton` et `metadataExecutionLogOutput`, absents du HTML ;
- les deux contrôles sont ajoutés au panneau ;
- un test de contrat vérifie désormais la présence de tous les identifiants nécessaires au chargement initial.
## Correctif fix-005
- suppression de la duplication des contrôles Copier/Effacer du journal ;
- ajout dun panneau de paramètres communs Devnet avec limites du profil ;
- séparation des boutons Simuler et Soumettre ;
- autorisation de construire un plan de soumission avec `dry_run = false`, la simulation exacte restant obligatoire avant signature et envoi ;
- maintien du refus de soumission sans confirmation opérateur.
## Correctif `pre.013-fix-006` — print supply NFT
La campagne Devnet a atteint le programme Metaplex et exécuté linstruction `Create` en simulation réelle. Le programme a refusé le modèle avec lerreur `Print supply is required for non-fungibles` (`Custom(166)`) parce que `print_supply` était `null`.
Le modèle nommé et le préparateur de fixture utilisent désormais `PrintSupply::Zero`, sérialisé sous la forme JSON `"Zero"`, pour le scénario `NonFungible`. Un test empêche la régression. La simulation et la soumission doivent être rejouées après application ; aucune soumission réussie nest déclarée dans ce rapport.
## Correctif `pre.013-fix-007` — programme SPL Token requis
La simulation réelle suivante a dépassé la validation de `PrintSupply::Zero`, puis le programme Metaplex a refusé linstruction avec `Missing SPL token program` (`Custom(149)`). Le transport RPC, la compilation du message, lestimation des frais et lappel `simulateTransaction` ont donc été confirmés ; aucune soumission na eu lieu.
Le modèle nommé et le préparateur de fixture `Create` renseignent désormais explicitement le programme SPL Token classique canonique :
```text
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
```
Les tests vérifient conjointement `print_supply = "Zero"` et ce Program ID. La campagne doit être rejouée en simulation avant toute soumission.
## Correctif `fix-008` — préconditions réseau par opération
- la fixture `Create` utilise un nouveau mint versionné créé avec freeze authority active ;
- owner, layout classique, décimales, supply, mint authority et freeze authority sont vérifiés avant génération de lintent ;
- une opération sans modèle nommé efface lintent courant et bloque simulation/soumission, au lieu de réutiliser le JSON précédent ;
- les requirements Metaplex sont documentés dans `kb-lib/USAGE.md` et `kb-pipeline/USAGE.md` ;
- les simulations observées avant ce correctif ont toutes échoué et ne sont pas déclarées validées.
## Correctif 009 — parcours cohérents et matérialisation optionnelle
La validation desktop nutilise plus implicitement une opération isolée sans contexte de fixture. Linventaire expose cinq parcours : NFT classique, SFT, fungible, collection parent/membre et pNFT. Chaque parcours précise la fixture, létat initial, létat terminal, les opérations applicables et les projections attendues.
La matérialisation est désormais une option opérateur indépendante. Après confirmation, elle exige des lectures de postcondition, décode les comptes Metaplex bornés et produit les projections canoniques correspondantes. Elle ne télécharge pas les URI off-chain.
La fixture NFT a été versionnée en `create-mint-profile-authority-v3.json` afin de ne pas réutiliser le mint déjà soumis. La mint authority et la freeze authority doivent être le wallet du profil, tandis que le keypair du mint ne sert quà signer la création du compte mint.
## Correctif `0.4.7-pre.013-fix-010` — compatibilité de la CLI `spl-token`
La CLI locale utilisée pour les validations ne prend pas en charge loption `create-token --freeze-authority`. Le préparateur utilise donc le parcours compatible suivant :
1. création du mint classique à `0` décimale avec `--enable-freeze` ;
2. transfert explicite de lautorité `freeze` depuis le keypair du mint vers le wallet du profil ;
3. transfert explicite de lautorité `mint` vers le même wallet ;
4. relecture du compte et validation stricte des deux autorités avant génération de lintent Metaplex.
La fixture est versionnée en `create-mint-profile-authority-v4.json` afin de ne pas réutiliser un mint absent ou partiellement préparé par le correctif précédent.
### 0.4.7-pre.13 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 `kb-wallet` sans exposer ni déléguer ses secrets à une CLI externe.
## Correctif fonctionnel fix-014
Le panneau nexpose plus les cinq parcours Devnet comme sils étaient tous préparables. Le premier parcours réellement exécutable est le NFT classique `create -> update`. La préparation détape génère conjointement lintent, les lectures avant confirmation et les lectures après confirmation utilisées par la matérialisation. Les parcours collection, SFT, fungible et pNFT restent présents dans la matrice synthétique cible et devront être activés seulement après ajout de leurs fixtures complètes.

View File

@@ -0,0 +1,42 @@
<!-- file: docs/validation/V0_4_7_PRE_014_METAPLEX_COHERENT_DEVNET_JOURNEYS.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.014` — parcours Metaplex Devnet cohérents
## Objet
Cette prérelease étend le runner Metadata depuis le seul parcours NFT vers cinq parcours Devnet préparables : NFT, SFT, fungible, collection parent et pNFT sans rule set.
Chaque parcours expose d'abord un cycle borné et comparable :
1. création native d'un mint SPL classique par le workspace ;
2. préparation contextuelle de `Create` ;
3. simulation exacte ;
4. soumission et confirmation explicites ;
5. relecture et matérialisation optionnelle des comptes applicables ;
6. préparation de `UpdateAsUpdateAuthorityV2` depuis l'état créé ;
7. simulation, soumission, confirmation et postconditions.
## Familles et contrats Create
| Parcours | `token_standard` | Edition relue | Particularité |
|------------|---------------------------|--------------:|-----------------------------------------|
| NFT | `NonFungible` | oui | `print_supply = Zero` |
| SFT | `FungibleAsset` | non | `decimals = 0`, pas de master edition |
| Fungible | `Fungible` | non | `decimals = 0`, pas de master edition |
| Collection | `NonFungible` | oui | `collection_details = V1(size=0)` |
| pNFT | `ProgrammableNonFungible` | oui | aucun rule set pour ce premier parcours |
## Limite volontaire
Cette prérelease ne déclare pas encore validées les opérations spécialisées `mint`, `verify`, `unverify`, `delegate`, `lock`, `unlock`, `transfer`, `revoke`, `burn`, `resize` et apparentées. Elles doivent être ajoutées comme étapes dépendantes d'un contexte confirmé, pas comme modèles JSON isolés.
## Validation attendue
- `cargo fmt --all` ;
- `cargo check --workspace` ;
- `cargo clippy --all-targets` ;
- `python3 scripts/audit_rust_workspace_rules.py` ;
- `cargo test -p kb-pipeline-demo-scenarios` ;
- `cargo test -p kb-app-demo-desktop` ;
- pour chaque parcours : préparer `Create`, simuler, soumettre, confirmer, puis préparer et valider `Update`.

View File

@@ -0,0 +1,34 @@
<!-- file: docs/validation/V0_4_7_PRE_015_METAPLEX_NFT_LIFECYCLE.md -->
<!-- version: 1 -->
# Validation `0.4.7-pre.015` — cycle NFT classique
## Portée
Cette prérelease prolonge le parcours Devnet NFT classique validé en `pre.014`.
Le parcours exécutable devient :
1. création native du mint SPL classique ;
2. `Create` Metaplex avec metadata et master edition ;
3. `UpdateAsUpdateAuthorityV2` pour enregistrer la vente primaire ;
4. `UpdateAsUpdateAuthorityV2` avec `is_mutable = false`.
La master edition nest pas une étape séparée : elle est créée par le wrapper `Create` lorsque `master_edition` et `print_supply = Zero` sont fournis.
## Validation attendue
Pour chaque étape :
- préparation contextuelle ;
- simulation exacte réussie ;
- soumission explicitement confirmée ;
- confirmation Devnet ;
- relecture du PDA metadata ;
- matérialisation optionnelle du snapshot confirmé.
Après la dernière étape, une nouvelle mise à jour doit être refusée par Metaplex puisque les metadata sont immutables.
## Hors portée de cette prérelease
`Print` et `Burn` exigent encore des fixtures supplémentaires : token account du master, mint et token account de lédition, edition marker et comptes de burn. Ils restent à implémenter dans la prérelease suivante et ne sont pas déclarés validés ici.

View File

@@ -1,4 +1,4 @@
<!-- file: olddocs/archivekbot3/prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
<!-- file: prompts/027_v0_4_7_metaplex_token_metadata_completion.md -->
<!-- version: 2 -->
# Prompt de session — `0.4.7` Achèvement de Metaplex Token Metadata