Sasedev/khadhroony-bot3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.4.8-pre.012

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-07 09:54:53 +02:00
parent dcc1d382d9
commit f5efce576b
16 changed files with 1901 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/audits/V0_4_8_PRE_011_TOKEN_2022_METADATA_COMPLETENESS_AUDIT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/audits/V0_4_8_PRE_011_TOKEN_2022_METADATA_COMPLETENESS_AUDIT.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Audit `0.4.8-pre.011` — complétude Token-2022 Token Metadata
@@ -55,8 +55,10 @@ cargo test --workspace 1 285 tests, 0 échec, doc-test
Le `cargo clean` préalable a supprimé les artefacts obsolètes qui empêchaient Cargo de reconstruire le fichier `executor.rs` extrait depuis l’archive. La recompilation complète a ensuite exécuté le test direct `token_metadata_operations_share_matrix_family` et le test général de parité de matrice avec succès.
`fix-005` ne modifie aucun code de production et ajoute deux tests unitaires. La première reprise locale a confirmé que tout le workspace compilait, passait Clippy et les audits, mais ces deux nouveaux tests échouaient uniquement parce qu’ils attendaient les noms courts `update_token_metadata_authority` et `emit_token_metadata` au lieu des codes canoniques `spl.token_2022.update_token_metadata_authority` et `spl.token_2022.emit_token_metadata`. `fix-006` corrige ces deux assertions sans modifier le comportement de production. Le nombre attendu de tests unitaires `kb-lib` reste 695.
`fix-005` ne modifie aucun code de production et ajoute deux tests unitaires. La première reprise locale a confirmé que tout le workspace compilait, passait Clippy et les audits, mais ces deux nouveaux tests échouaient uniquement parce qu’ils attendaient les noms courts `update_token_metadata_authority` et `emit_token_metadata` au lieu des codes canoniques `spl.token_2022.update_token_metadata_authority` et `spl.token_2022.emit_token_metadata`. `fix-006` corrige ces deux assertions sans modifier le comportement de production.
La reprise finale de `fix-006` a ensuite réussi `cargo check --workspace`, `cargo clippy --all-targets`, `python3 scripts/audit_rust_workspace_rules.py` et `cargo test --workspace`. La suite unitaire `kb-lib` compte **695 tests réussis, 0 échec**. `pre.011` est donc clôturée sans réserve fonctionnelle.
## Frontières maintenues
Les fixtures, soumissions Devnet, confirmations et preuves réseau restent dans `pre.012`. Le sous-panneau desktop Token-2022 reste dans `pre.013`. Aucune résolution off-chain n’est ajoutée par cette phase.
Les fixtures, soumissions Devnet, confirmations et preuves réseau Token-2022 restent dans `pre.012`. Le réaudit Metaplex et ses compléments Devnet sont insérés en `pre.013`, ce qui décale la finalisation desktop metadata en `pre.014`. Aucune résolution off-chain n’est ajoutée par cette phase.

72
docs/audits/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_CAMPAIGN_AUDIT.md Normal file
View File

@@ -0,0 +1,72 @@
<!-- file: docs/audits/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_CAMPAIGN_AUDIT.md -->
<!-- version: 2 -->
# Audit `0.4.8-pre.012` — campagne Devnet Token-2022 Token Metadata
## Statut
**Terminée et validée sur Devnet.**
Le delta initial omettait la dépendance directe `bs58` dans `kb-pipeline-demo-scenarios/Cargo.toml`, alors que deux modules de la crate l'utilisent directement. `pre.012-delta-fix-001` déclare `bs58.workspace = true` et enregistre les preuves de la campagne réelle exécutée le 7 août 2026.
`pre.011` avait fermé la complétude fonctionnelle des cinq instructions de `spl-token-metadata-interface`. `pre.012` confirme désormais leur orchestration réseau de bout en bout sur Token-2022 Devnet.
## Contrat couvert
La campagne couvre exactement, dans cet ordre :
1. `Initialize` ;
2. `UpdateField` ;
3. `Emit` ;
4. `RemoveKey` ;
5. `UpdateAuthority`.
La fixture crée un mint Token-2022 frais, initialise `MetadataPointer` avant `InitializeMint2`, pointe le metadata pointer sur le mint lui-même et préfinance le compte pour les réallocations TLV atteintes par la campagne.
## Fixture Devnet observée
```text
mint=EHrx1evxgXLEgjb1sgc5dVTktXX1LiovXR9YFsZS3d4k
preparation_signature=2yYciRNoTTNSGuuaBFE6925FPjSj4fXp8usSkpLhgEPuhQMJYdsEzkAzxBdjDhpPHCT3db9bLz9Ud4BU5QSQZzQ5
initial_authority=J12WA6c42oqpWkLu1dFa4pCegkQJPpxabwc3RRCMSUuH
final_authority=3RVXUmVvY7quUUEVsDKh5EcenVygwv3mo1iagPa4Pmq7
```
La préparation stateful impose que `metadata_pointer` soit présent, auto-référent et détenu par l'autorité attendue, tandis que `token_metadata` doit être absent avant `Initialize`.
## Résultats réseau
| Étape | Signature | Slot | Postcondition | Matérialisations | `returnData` |
|--------------------------------|--------------------------------------------------------------------------------------------|----------:|---------------|-----------------------------------------:|-------------:|
| `InitializeTokenMetadata` | `48kzJR5VW1ZYSRkVrg6qyNmuHdAUu7NXcnzaNsSmH7SSmRXK1X6RQdCeeSQi6LhrrkgRFRGVnxkwXPtkiqG6EgnY` | 481804441 | `Confirmed` | 1 | 0 |
| `UpdateTokenMetadataField` | `JrdB9EqePS1FVWLo55w1Vhv2eTCTfCpXZgMvPCocW3m3iu4nk3BFBBRHoe2Nbcpq1rmnZoFrhnag5fG2WwmJrYs` | 481804454 | `Confirmed` | 1 | 0 |
| `EmitTokenMetadata` | `3TKdBCJhM1VEZ9ti6EYR9gSLJnH5ni6FjW4kvoqwdYK1u14jdY6hS8hf2VGeLi21PbX5CWiyzjthJZERK5KHroWH` | 481804464 | `Confirmed` | 1 observée, non requise par la politique | 202 |
| `RemoveTokenMetadataKey` | `3kDBV7pDFgoCQVJ9DYYuxvHFbCJzyA6J2rLg6ndGCETEhhFBZ1ipRQ52X2hZfwNPfdJwEFFBmbyMU6kFGnVXJNrm` | 481804473 | `Confirmed` | 1 | 0 |
| `UpdateTokenMetadataAuthority` | `5aBpQsm6mAHA5xSN5tZ1ubALbfghGa7JScjXn9NGhg9agzEdjXydH6jgmn6UmxinGHmMvtqaGRLk9dgjmmz4HpU2` | 481804482 | `Confirmed` | 1 | 0 |
Le runner n'accepte une étape qu'après simulation réussie, confirmation, hydratation canonique, extraction Core, replay Token-2022, seconde passe d'idempotence propre et postcondition stateful confirmée. Les mutations exigent en plus une matérialisation instructionnelle. `Emit` n'en exige pas ; sa preuve spécialisée est le `returnData`, décodé ici sur 202 octets et comparé au snapshot TLV autoritatif.
## Matrice
`test-fixtures/contract-matrices/SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json` conserve exactement les cinq scénarios de la campagne. `pre.012-delta-fix-001` les promeut tous à `confirmed` et enregistre pour chacun toutes les catégories de preuve requises.
Le test de matrice est mis à jour pour exiger cet état confirmé et vérifier que chaque catégorie requise possède une preuve observée.
## Validation locale
Les contrôles opérateur réussissent :
```text
cargo fmt --all réussi
cargo check --workspace réussi
cargo clippy --all-targets réussi
python3 scripts/audit_rust_workspace_rules.py clean
cargo test -p kb-pipeline-demo-scenarios 69 + 1 + 1 tests réussis
cargo test --workspace réussi
```
Le workspace complet de `pre.012` termine ses 34 suites de tests avec 1 294 tests réussis au total et aucun échec.
## Conclusion
`0.4.8-pre.012` est clôturée : les cinq instructions Token-2022 Token Metadata prévues sont confirmées sur Devnet avec preuves de simulation, transaction, replay et postcondition. La phase suivante est `0.4.8-pre.013`, consacrée au réaudit et à la complétude Metaplex Token Metadata et de ses campagnes Devnet.

40
docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md
View File

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

83
docs/validation/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_VALIDATION_REPORT.md Normal file
View File

@@ -0,0 +1,83 @@
<!-- file: docs/validation/V0_4_8_PRE_012_TOKEN_2022_METADATA_DEVNET_VALIDATION_REPORT.md -->
<!-- version: 1 -->
# Validation Devnet `0.4.8-pre.012` — Token-2022 Token Metadata
## Statut
**Préparée, non exécutée.**
Aucune signature, aucun slot et aucune postcondition réseau ne sont préremplis dans ce rapport. La preuve synthétique ou la seule réussite des tests locaux ne doit pas être présentée comme une validation Devnet confirmée.
## Périmètre réseau
Program ID :
```text
TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
```
Campagne ordonnée :
1. `InitializeTokenMetadata` ;
2. `UpdateTokenMetadataField` ;
3. `EmitTokenMetadata` ;
4. `RemoveTokenMetadataKey` ;
5. `UpdateTokenMetadataAuthority`.
La préparation crée un mint Token-2022 frais avec `MetadataPointer` auto-référent, préfinancé pour les réallocations de metadata atteintes pendant la campagne.
## Matrice initiale
| Scénario | Statut initial | Preuve réseau |
|----------------------------------------|----------------|---------------|
| `token_2022_metadata_initialize` | `not_run` | aucune |
| `token_2022_metadata_update_field` | `not_run` | aucune |
| `token_2022_metadata_emit` | `not_run` | aucune |
| `token_2022_metadata_remove_key` | `not_run` | aucune |
| `token_2022_metadata_update_authority` | `not_run` | aucune |
Source machine-readable : `test-fixtures/contract-matrices/SPL_TOKEN_2022_METADATA_DEVNET_VALIDATION_MATRIX.json`.
## Commande opérateur
Après les validations locales de compilation :
```bash
KB_DEVNET_TOKEN_2022_METADATA_CAMPAIGN_TEST=1 \
KB_DEVNET_TOKEN_2022_METADATA_OPERATOR_CONFIRMED=1 \
KB_POSTGRES_TEST_URL='postgresql://…' \
cargo test -p kb-pipeline-demo-scenarios optional_devnet_token_2022_metadata_campaign_from_env -- --nocapture
```
`KB_DEVNET_PROFILE` permet de sélectionner un profil précis ; `KB_DEVNET_CONFIG_PATH` permet de remplacer le fichier de configuration par défaut.
## Preuves à enregistrer
Pour les quatre mutations :
- simulation réussie ;
- signature ;
- confirmation et slot ;
- hydratation canonique ;
- extraction Core ;
- replay Token-2022 ;
- matérialisation instructionnelle Token Metadata ;
- postcondition stateful ;
- seconde passe d'idempotence.
Pour `Emit` :
- simulation réussie ;
- `returnData` et longueur décodée ;
- signature ;
- confirmation et slot ;
- hydratation canonique ;
- extraction Core ;
- replay Token-2022 ;
- postcondition stateful comparée au contenu décodé ;
- seconde passe d'idempotence.
## Résultat attendu
La campagne est considérée validée uniquement si les cinq étapes sont confirmées et si leurs postconditions sont `Confirmed`. Après exécution, ce rapport et la matrice doivent être mis à jour avec les preuves réellement observées ; aucune valeur ne doit être reconstruite ou inventée.