# Guide de validation Devnet ## Objectif Une validation Devnet démontre un parcours réel. Elle ne doit pas être confondue avec un test unitaire, une simulation ou une validation synthétique. ## Niveaux de preuve 1. test unitaire ou contractuel ; 2. validation synthétique sur fixtures ; 3. simulation RPC exacte ; 4. confirmation opérateur ; 5. soumission ; 6. confirmation finalisée ; 7. insertion canonique ; 8. extraction Core ; 9. replay et matérialisation ; 10. idempotence et vérification CLI finale. Le rapport doit indiquer précisément les niveaux réellement exécutés. ## Prérequis - profil Devnet explicite ; - endpoint compatible ; - wallet de test et fonds suffisants ; - paramètres bornés ; - scénario réutilisable hors desktop lorsque possible ; - confirmation opérateur avant tout envoi. ## Commandes Les scénarios peuvent être déclenchés depuis `kb-pipeline-demo-scenarios` ou le desktop. La validation frontend se fait uniquement avec : ```bash cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json ``` ## Rapport Conserver : - scénario et version ; - cluster ; - signatures publiques ; - opérations exécutées ; - résultats de simulation et confirmation ; - vérifications de stockage, replay et matérialisation ; - limites et étapes non exécutées. Ne pas conserver de keypair, secret ou preuve privée dans les deltas. ## ElGamal Le registre ElGamal ne doit pas être déclaré validé sur Devnet ou Mainnet sans confirmation de déploiement, preuve `PubkeyValidity`, compte `Proof Context State` valide et scénario complet. ## Références - `docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md` ; - `docs/DEVNET_EXECUTION_GUIDE.md` ; - `kb-pipeline-demo-scenarios/USAGE.md` ; - `kb-app-demo-desktop/USAGE.md`. ## Metaplex Token Metadata Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Chaque parcours prépare sa fixture et dérive automatiquement les PDA et comptes de postcondition nécessaires à l’étape courante. Une liste de profils vide est une erreur de configuration ou de raccordement et doit être signalée explicitement. Une validation réseau exige une simulation RPC réelle ; une soumission exige en plus confirmation opérateur, signature, confirmation et postconditions observées. ### Paramètres communs du panneau Metadata Le panneau Metaplex utilise le même modèle opérateur que Solana Core et SPL : profil Devnet préparé, limites de dépense visibles, journal commun avec une seule barre `Copier` / `Effacer`, bouton de simulation distinct du bouton de soumission et confirmation opérateur séparée. Une soumission construit un plan avec `dry_run = false`, mais la transaction ne peut être signée ou envoyée qu'après réussite de la simulation exacte du même message.