4.3 KiB
Validation fonctionnelle — Metadata on-chain et clôture 0.4.8
Périmètre
La version 0.4.8 ferme trois domaines Metadata on-chain strictement séparés :
- Solana Program Metadata
ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S; - Token-2022 Token Metadata via
spl-token-metadata-interface; - Metaplex Token Metadata
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.
Elle couvre les contrats on-chain, décodeurs, matérialisateurs, exécuteurs lorsque applicables, orchestration stateful, scénarios réutilisables et validation desktop.
Qualification réseau
Solana Program Metadata
Les neuf opérations stables sont confirmed sur Devnet avec simulation, soumission, confirmation, lectures stateful, replay canonique et matérialisation.
Token-2022 Token Metadata
Les cinq opérations de l’interface sont confirmed sur Devnet :
Initialize;UpdateField;Emit;RemoveKey;UpdateAuthority.
Metaplex Token Metadata
La matrice Devnet courante des vingt opérations est close :
- 15
confirmed; - 5
unavailable; - 0
not_run.
Les cinq opérations indisponibles restent explicitement bornées par les observations runtime documentées pendant 0.4.8-pre.013 ; elles ne sont jamais promues depuis une validation synthétique.
Desktop Metadata
kb-app-demo-desktop sépare les trois domaines Metadata et appelle les scénarios réutilisables de ks-pipeline-demo-scenarios.
La validation finale couvre notamment :
- synchronisation du profil Devnet ;
- campagnes spécialisées Metaplex ;
- campagne Token-2022 Token Metadata ;
- campagne Solana Program Metadata ;
- JsonViewer pour les résultats structurés ;
- accordéons de préflight, simulation/confirmation et postconditions/preuves ;
- carte des exigences dans la colonne de résultats ;
- journal d’exécution sur toute la largeur.
Conformité finale du workspace
La campagne finale du 9 août 2026 est conforme :
cargo fmt --allréussi ;cargo check --workspaceréussi ;cargo clippy --all-targetsréussi sans warning ;python3 scripts/audit_rust_workspace_rules.py: audit Rust général propre, export completeness à zéro candidat et audit Khadhroony propre ;cargo test --workspaceréussi sur toutes les crates, tous les tests d’intégration et toutes les doctests.
Les principales cibles unitaires observées comprennent :
kb-app-demo-desktop: 144 tests ;ks-config: 46 tests ;ks-core: 2 tests ;ks-lib: 706 tests, plus 9 tests d’intégration ;ks-logging: 17 tests ;ks-onchain-transport: 118 tests ;ks-pipeline: 109 tests, plus 3 tests d’intégration Metadata ;ks-pipeline-demo-scenarios: 105 tests bibliothèque, 1 test CLI et 1 test API externe ;ks-program-ids: 6 tests ;ks-store: 84 tests ;ks-wallet: 6 tests.
Build desktop de release
La validation frontend n’est pas exécutée par un npm run build autonome.
La commande de release utilisée est :
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
Tauri déclenche le beforeBuildCommand, qui exécute TypeScript puis Vite. La configuration validée utilise :
root: 'frontend'etbuild.outDir: '../../dist'côté Vite ;frontendDist: '../dist'côté Tauri.
Ces deux chemins convergent vers le même répertoire dist à la racine du workspace.
Le build de release a produit avec succès :
Khadhroony Bot3 Demo Desktop_0.4.8_amd64.deb;Khadhroony Bot3 Demo Desktop-0.4.8-1.x86_64.rpm;Khadhroony Bot3 Demo Desktop_0.4.8_amd64.AppImage.
Limites et reports
- aucun fetch HTTP/IPFS/Arweave n’est intégré au replay canonique ;
- la couverture généraliste différée — programmes/interfaces SPL non prioritaires, compléments Metaplex et autres Program IDs non bloquants pour la séquence trading prioritaire — est reportée à
0.15.x; kb-offchain-transportest reportée à0.16.x+après repriorisation du ROADMAP ;- le registre ElGamal reste sans preuve réseau réelle disponible.
Traçabilité
Les audits, rapports de prerelease et le plan de travail 0.4.8 sont archivés sous olddocs/archivekbot3/. Ils conservent la chronologie détaillée mais ne sont plus normatifs.
Statut
Version fonctionnelle 0.4.8 clôturée et validée.