khadhroony-bot3/docs/DEVNET_EXECUTION_GUIDE.md

Guide d’exécution Devnet

1. Objet

Ce guide est créé avant la campagne Devnet puis corrigé pendant les essais réels. Il décrit uniquement les scénarios exposés par kb-app-demo-desktop et kb-pipeline-demo-scenarios.

2. Préparation du profil

1. Copier .env.example vers .env et renseigner au minimum KB_POSTGRES_DEVNET_URL.
2. Vérifier que KB_POSTGRES_DEVNET_URL, KB_POSTGRES_MAINNET_URL et KB_POSTGRES_TEST_URL désignent trois bases distinctes.
3. Sélectionner le profil local_devnet ou le profil Devnet explicitement autorisé dans example.config.json.
4. Vérifier que l’envoi mainnet reste désactivé.
5. Vérifier les plafonds de frais, de dépense et les politiques simulation-first.
6. Démarrer l’application avec la configuration de développement attendue.
7. Contrôler dans la fenêtre Configuration que local_devnet utilise bien la base Devnet et non la base Mainnet.

3. Wallet de démonstration

Créer un wallet dédié avec les outils Solana installés localement, conserver le fichier hors du dépôt et vérifier ses permissions privées. Relever la pubkey sans copier la clé privée dans l’interface ou les logs.

Champs à consigner pendant les tests :

• alias du wallet ;
• pubkey ;
• cluster ;
• solde initial ;
• source de financement Devnet ;
• date du test.

4. Financement Devnet

Le financement doit être réalisé avec un faucet Web Devnet. La commande solana airdrop n’est pas considérée comme une procédure valide dans l’environnement de validation. Fournir uniquement la pubkey au faucet, ne jamais transmettre le fichier du wallet ni sa clé privée, puis vérifier le solde via la fenêtre HTTP ou une lecture RPC non mutable.

5. Ordre des tests existants

5.1 Solana Core

• génération d’un destinataire ;
• transfert System en simulation ;
• envoi après confirmation opérateur ;
• confirmation réseau ;
• extraction Core ciblée ;
• Decode replay ciblé ;
• vérification des projections.

5.2 SPL Memo v4

• saisir un texte borné ;
• vérifier le plan et les signers ;
• simuler ;
• envoyer ;
• confirmer ;
• vérifier l’annotation de transaction et l’idempotence du replay.

5.3 SPL Token classique

• préparer mint et comptes contrôlés ;
• exécuter les scénarios non destructifs avant le lifecycle complet ;
• documenter chaque signature et chaque solde brut avant/après ;
• vérifier replay et matérialisation.

5.4 ATA

• dériver l’ATA classique et Token-2022 ;
• simuler la création idempotente ;
• envoyer uniquement après contrôle du payer et du plafond de rent ;
• vérifier la projection lifecycle.

5.5 Token-2022 et registre ElGamal

• utiliser uniquement les scénarios explicitement disponibles dans l’interface ;
• conserver les preuves de préflight, comptes, extensions et signers ;
• distinguer registre ElGamal et programme Token-2022 ;
• vérifier les projections admin, token, fee, metadata et risk attendues.

6. Future fenêtre Metadata

La fenêtre demo_execution_metadata sera ajoutée avec le pipeline metadata général. L’ordre prévu est :

1. SPL Token Metadata incorporé à Token-2022 ;
2. programme Metaplex Token Metadata ;
3. éventuel enrichissement off-chain via kb-offchain-transport, sans couplage au replay canonique.

7. Preuves à conserver par scénario

• profil et cluster ;
• paramètres saisis ;
• plan exact ;
• signers requis ;
• estimation des frais ;
• résultat de simulation ;
• signature d’envoi ;
• confirmation ;
• résumé d’extraction/replay ;
• projections matérialisées ;
• diagnostics et écarts observés.

8. Critères de validation

Un scénario n’est validé que si :

• la simulation réussit ;
• l’envoi est explicitement confirmé ;
• la confirmation réseau correspond à la signature ;
• le replay post-exécution ne produit ni échec fonctionnel ni erreur de traitement ;
• les projections attendues sont présentes et idempotentes ;
• le guide est corrigé lorsque le comportement réel diffère des étapes écrites.