v0.4.8-pre.014
This commit is contained in:
@@ -0,0 +1,209 @@
|
||||
<!-- file: docs/validation/V0_4_8_PRE_014_DESKTOP_METADATA_VALIDATION_REPORT.md -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Validation desktop Metadata `0.4.8-pre.014`
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce rapport consolide la première validation réelle du panneau `demo_execution_metadata` après l’ouverture de `0.4.8-pre.014`, puis motive le correctif de câblage Metaplex du delta suivant.
|
||||
|
||||
Il ne remplace pas les matrices réseau spécialisées. Il qualifie uniquement l’intégration desktop et la correspondance entre l’UI Tauri et les campagnes réutilisables déjà validées.
|
||||
|
||||
## 2. Contrôles locaux
|
||||
|
||||
Le 8 août 2026, après application du premier delta `pre.014`, les contrôles suivants réussissent :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-pipeline-demo-scenarios 105 unitaires + 1 CLI + 1 API externe
|
||||
kb-app-demo-desktop 139 unitaires
|
||||
cargo tauri dev démarrage OK
|
||||
```
|
||||
|
||||
La validation visuelle confirme :
|
||||
|
||||
- trois accordéons distincts pour Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata ;
|
||||
- synchronisation du profil sélectionné entre les trois domaines ;
|
||||
- journal d’exécution placé sous la grille et utilisant toute la largeur disponible.
|
||||
|
||||
## 3. Token-2022 Token Metadata
|
||||
|
||||
Les logs fournis montrent une campagne desktop complète sur Devnet, sans entrée dans les fichiers `error*.jsonl`.
|
||||
|
||||
| Opération | Signature | Slot |
|
||||
|-------------------|--------------------------------------------------------------------------------------------|------------:|
|
||||
| `Initialize` | `23aXutFc25Ncn4XPSGdaaEzvUpe9s57gYunmMq1asmFRK9xe1tAYVCnV3dePUn2a7qqq51JDsPKp5ep5d1DLypNv` | `482188064` |
|
||||
| `UpdateField` | `Uws9Laene33LxYet4562LKXMkKjAhW5FPweQSnFJv7NG6s4u7LqB7zbppQgQgaNFE52d9UVZKLmjZoK9zb4xdHK` | `482188079` |
|
||||
| `Emit` | `2uNggBbSvvj7Cqdddt1KtFgFhTJ9jsyvobeGUaAU6kPNY9o4hJ6BVHEhpELe1sRSyrMrgbeGLoRiWAMU2UrisMcE` | `482188091` |
|
||||
| `RemoveKey` | `3xUUnjQvWzSkMQPe2VFDyYX14K3STxBzFjzWEawrK28UsoJzXTPYA61nzkL5JvLwCfhNRg7YpBcsSSjhTJqtqNYT` | `482188102` |
|
||||
| `UpdateAuthority` | `2U9zrLL9NusrhpW9Dx15SqZ8c4d6zbcgSyM4hBcewr1Ar7JwLYwvBduLKs4HKEgZP9i5YQQ9cyTC977mjJGLWqXW` | `482188113` |
|
||||
|
||||
Les traces `kb-pipeline` et `kb-lib` montrent le décodage Token-2022, la matérialisation `materializer.metadata.token_2022` et la seconde passe de replay/idempotence. La fixture a été préparée auparavant par la signature `LNwzGfvCgZdumbYXfAecCxU6hfHYGa6XRwC7E71jc4JTDUj5QyVBVV5Sd9KLWmX2t72XfKBiYUEV6WYCvPqC4wd`, slot `482188053`.
|
||||
|
||||
**Statut desktop : validé.**
|
||||
|
||||
## 4. Solana Program Metadata
|
||||
|
||||
La campagne desktop `ProgM6…` traverse les deux parcours complets après préparation des PDA frais `buffer=6bs5XpPsNUqw8FatFJTJu81ZAUBCvxmyxptNyUY4RnDU` et `metadata=7fTTM3KCtFMjxmTaWa6xJ3nSbK9Yi7MdVXP3dSa8ahPB`.
|
||||
|
||||
Les neuf opérations atteignent toutes l’état `Confirmed` dans les contrôles post-exécution :
|
||||
|
||||
```text
|
||||
Buffer : Allocate -> Extend -> Write -> SetAuthority -> Trim -> Close
|
||||
Metadata : Initialize -> SetData -> SetImmutable
|
||||
```
|
||||
|
||||
Signatures observées :
|
||||
|
||||
```text
|
||||
Allocate Je6SLx7wfNqEJ8Huo64r177Sm9bda4uFXUPwuxfZG89jvb1zKMKLnzTJEL5DFHxftMq38FsLNF3TZ14kaWSZ7Hb
|
||||
Extend LYgf8ac4CKYdY2xkw9bCS8J9cvkphWA8ueCUJ5CBKZ11jEdS2NZLykF4jwmSA5AnVYWxzNABeXhGV4d1dFvzMnM
|
||||
Write 4p7XEXeGgWQjJkWTfrBB5rL9XwDadxzoCPreLfaB3fBGACyrPqZYmnBGqVYVgyR9zDZNxuKhimEwMtmiGdJseKa2
|
||||
SetAuthority 5kPi3eBqbq92kV5ZFWPur9afAokGxhgr84PPQh7s5btyQYayC3TDuaH9TCcspxbd4YEYDD4icFYnSWX2Ej9XdLgA
|
||||
Trim 5YG7Yp6x1waZZKoRjb37q7QUNJL5CMEUgu8gs7ehDwHUx1TXvV5BaeUJFT1Pb58z4hSo4woey2qaKQggAzaNtYEG
|
||||
Close 2jyZzegSM2v7LJ15nF3r9zXsLXd7ZDsWsCEWHLXQdoBrLkrbuSuwVrGx1jTqYejw195FVhWHeJQYY6BaN98s5R6
|
||||
Initialize 2kzvpRi8KwRhaQPiwtR8PCQGTuQ3e3kUNSi7EVsMXqJzhQkZanjNwxsL2sGeB8Xs56N22TaaYbS6LJimQpHZWk6J
|
||||
SetData 3WZHzYno9M6uHLMiXsNBtBHoN3yAp7ftd3pSNWpuj2jATk1g29nvUccgUu6wuRijv9oBo2Vi1dHKury2DFfDQ1ib
|
||||
SetImmutable XTAj5NNVXRkhKe4DxsXGm2xtxocrwHwkkpEun4ib6h4qs6DX5f2K6gfgQ2jppkTWoC83MyoPgrpvdKes1b72gbJ
|
||||
```
|
||||
|
||||
**Statut desktop : validé.**
|
||||
|
||||
## 5. Metaplex Token Metadata : écart constaté
|
||||
|
||||
Les logs de la même session ne montrent pas une campagne Metaplex spécialisée. Le desktop prépare uniquement une fixture classique avec :
|
||||
|
||||
```text
|
||||
operation = metadata.metaplex_token_metadata.prepare_native_mint_and_ata
|
||||
signature = 5YdSQHZ5T3VV8zefmQS4GVHNXPbvCijiLyHdgwvqcmGMMpobAJcM4HvdeQ7vex9qDqcYtAVUtj4U3bDCeQ2Hfzvv
|
||||
slot = 482188642
|
||||
```
|
||||
|
||||
Aucune séquence qualifiée `Create -> Mint`, collection, Print/Burn, lifecycle pNFT, escrow, maintenance ou Use ne suit cette préparation avant la fin des logs.
|
||||
|
||||
La cause est un écart de câblage desktop : le panneau utilisait encore le workflow générique `scénario -> étape -> intent JSON`, alors que `pre.013` a qualifié des campagnes spécialisées cohérentes et indivisibles.
|
||||
|
||||
## 6. Correctif `pre.014-delta-fix-001`
|
||||
|
||||
Le correctif conserve les scénarios synthétiques pour l’inspection de contrats mais remplace le parcours Devnet principal par 11 campagnes spécialisées :
|
||||
|
||||
1. `Create -> Mint` NFT ;
|
||||
2. `Create -> Mint` SFT ;
|
||||
3. `Create -> Mint` fungible ;
|
||||
4. `Create -> Mint` collection ;
|
||||
5. `Create -> Mint` pNFT ;
|
||||
6. collection `Verify -> Unverify` ;
|
||||
7. `Print -> Burn` ;
|
||||
8. lifecycle pNFT ;
|
||||
9. Token Owned Escrow ;
|
||||
10. maintenance ;
|
||||
11. probe Use.
|
||||
|
||||
Maintenance et Use conservent les opérations `unavailable` comme probes simulation-only ; elles ne sont pas converties en soumissions isolées.
|
||||
|
||||
La carte **Exigences** est également déplacée en bas de la colonne droite, après **Postconditions et preuves**. Le journal reste en pleine largeur sous la grille.
|
||||
|
||||
## 7. Validation de `fix-001`
|
||||
|
||||
Après application de `fix-001` :
|
||||
|
||||
- les 11 campagnes Metaplex sont bien exposées par le nouveau contrat desktop ;
|
||||
- les contrôles statiques `fmt`, `check`, Clippy et audit workspace sont propres ;
|
||||
- `kb-pipeline-demo-scenarios` conserve 105 tests unitaires + 1 CLI + 1 API externe réussis ;
|
||||
- `kb-app-demo-desktop` exécute 144 tests, avec 143 réussites et un échec du test historique qui cherche encore les anciens IDs de contrôles supprimés ;
|
||||
- deux tentatives réelles de `Create -> Mint — NFT` provoquent un arrêt brutal du processus pendant la post-validation du `Create`.
|
||||
|
||||
## 8. Correctif `pre.014-delta-fix-002`
|
||||
|
||||
Après application de `fix-001`, deux essais successifs de `Create -> Mint — NFT` provoquent un arrêt brutal de l'application au même endroit. Le second essai est effectué après purge des logs.
|
||||
|
||||
Le journal réseau prouve que la fixture SPL classique est créée, puis que l'opération Metaplex `Create` est simulée, envoyée et confirmée :
|
||||
|
||||
```text
|
||||
fixture signature : 64kLtKRiCewywr1CdNbcznHZS7PtNnfh5vxzZLte2VoUexkoyGtRdVozMxsATpP97Sp1fjv2fmPwGUj9hM6VFH8d
|
||||
fixture slot : 482323101
|
||||
Create signature : NAXZephC3aPqe8KA4Ly81o56xkhUEEMMLdZKnYEqiifvRGuQmf997nM29EtWZESyC97qu75v4UzyRWt4aqxRN1d
|
||||
Create slot : 482323110
|
||||
```
|
||||
|
||||
Le dernier événement écrit est le lancement de l'hydratation canonique de cette signature puis l'envoi de `getTransaction`. Aucun panic Rust, aucune erreur applicative structurée et aucune erreur JSONL ne sont enregistrés avant la disparition du processus. Le défaut n'est donc pas classé comme un échec Metaplex de la transaction : il appartient à l'intégration desktop/runtime du nouveau dispatch de campagnes.
|
||||
|
||||
`fix-002` :
|
||||
|
||||
- conserve les campagnes réutilisables intactes ;
|
||||
- boxe explicitement le futur du dispatch Metaplex avant l'attente Tauri, afin d'éviter de conserver le gros state machine des onze branches directement dans le futur de commande ;
|
||||
- journalise `campaign_start`, `campaign_completed` et `campaign_failed` ;
|
||||
- réaligne le test frontend historique sur les contrôles de campagne qualifiés introduits par `fix-001`.
|
||||
|
||||
La validation Tauri doit reprendre par `Create -> Mint — NFT`. Si un arrêt brutal subsiste, les nouveaux marqueurs et la dernière étape réseau permettront de distinguer un défaut du runtime desktop d'un défaut d'hydratation HTTP.
|
||||
|
||||
## 9. Validation réelle de `fix-002`
|
||||
|
||||
La validation locale du 9 août 2026 est propre :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-app-demo-desktop 144 tests unitaires, tous OK
|
||||
cargo tauri dev démarrage OK
|
||||
```
|
||||
|
||||
Le bundle de logs du second essai confirme que le boxing du dispatch Metaplex supprime l’arrêt brutal observé avec `fix-001`. Les onze campagnes exposées par le desktop ont toutes un marqueur `campaign_start` suivi d’un marqueur `campaign_completed`, sans `campaign_failed` :
|
||||
|
||||
| Campagne | Exécutions/probes projetés | Statut desktop |
|
||||
|--------------------------------|---------------------------:|---------------------------------------------|
|
||||
| `create_mint_nft` | 2 | terminé |
|
||||
| `create_mint_sft` | 2 | terminé |
|
||||
| `create_mint_fungible` | 2 | terminé |
|
||||
| `create_mint_collection` | 2 | terminé |
|
||||
| `create_mint_programmable_nft` | 2 | terminé |
|
||||
| `collection_verify` | 6 | terminé |
|
||||
| `print_burn` | 4 | terminé |
|
||||
| `pnft_lifecycle` | 8 | terminé |
|
||||
| `escrow` | 7 | terminé |
|
||||
| `maintenance` | 7 | terminé, dont 4 indisponibilités qualifiées |
|
||||
| `use_probe` | 3 | terminé, dont 1 indisponibilité qualifiée |
|
||||
|
||||
Les journaux UI confirment notamment `maintenance : confirmed=3, unavailable=4, evidence=7` et `use_probe : confirmed=2, unavailable=1, evidence=3`. Les fichiers `error*.jsonl` du bundle fourni sont tous vides.
|
||||
|
||||
**Statut desktop Metaplex : validé pour les onze campagnes qualifiées.**
|
||||
|
||||
## 10. Consolidation structurelle `fix-003`
|
||||
|
||||
Le correctif suivant ne change aucune campagne réseau. Il simplifie seulement le desktop :
|
||||
|
||||
- `demo_execution_metadata_metaplex_campaign.rs` est fusionné dans `demo_execution_metadata_metaplex_token_metadata.rs` ;
|
||||
- les commandes Tauri et les contrats TS-RS restent inchangés ;
|
||||
- Metaplex suit désormais le même modèle de module unique que Token-2022 Token Metadata et Solana Program Metadata ;
|
||||
- les trois blocs de résultats deviennent un accordéon Bootstrap commun, sur le modèle de `demo_execution_spl` ;
|
||||
- la carte **Exigences** reste sous l’accordéon dans la colonne droite ;
|
||||
- le journal d’exécution reste pleine largeur sous la grille.
|
||||
|
||||
Après application, la validation requise est locale (`fmt`, `check`, Clippy, audit, 144 tests desktop) puis visuelle dans Tauri pour l’ouverture/fermeture des trois JsonViewer. Aucune nouvelle campagne Devnet n’est requise pour requalifier Metaplex.
|
||||
|
||||
## 11. Clôture de `pre.014`
|
||||
|
||||
La validation finale confirme que `fix-003` ne réintroduit aucune régression :
|
||||
|
||||
```text
|
||||
cargo fmt --all OK
|
||||
cargo check --workspace OK
|
||||
cargo clippy --all-targets OK, aucun warning
|
||||
scripts/audit_rust_workspace_rules.py clean
|
||||
kb-app-demo-desktop 144 tests unitaires, tous OK
|
||||
```
|
||||
|
||||
La vérification visuelle Tauri confirme également :
|
||||
|
||||
- les trois accordéons de résultats s’ouvrent et se ferment correctement ;
|
||||
- les JsonViewer restent lisibles dans les accordéons ;
|
||||
- la carte **Exigences** reste sous les résultats dans la colonne droite ;
|
||||
- le journal d’exécution reste en pleine largeur sous la grille ;
|
||||
- les trois domaines Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata restent distincts.
|
||||
|
||||
Les campagnes réseau ayant déjà été qualifiées avant le refactor structurel de `fix-003`, aucun rerun Devnet supplémentaire n’est requis. **Statut de `0.4.8-pre.014` : terminé et validé.**
|
||||
Reference in New Issue
Block a user