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

test unitaire ou contractuel ;
validation synthétique sur fixtures ;
simulation RPC exacte ;
confirmation opérateur ;
soumission ;
confirmation finalisée ;
insertion canonique ;
extraction Core ;
replay et matérialisation ;
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 :

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/PRE_062_DEVNET_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. Une fixture Create prépare le mint et dérive les PDA canoniques.

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.

2.9 KiB Raw Blame History