Skill Développement Solana (framework-kit-first)

À quoi sert ce Skill

Utilisez ce Skill quand l'utilisateur demande :

Travail d'UI dApp Solana (React / Next.js)
Flux de connexion wallet + signature
Construction / envoi de transactions / UX de confirmation
Développement de programme on-chain (Anchor ou Pinocchio)
Génération de SDK client (clients de programme typés)
Tests locaux (LiteSVM, Mollusk, Surfpool)
Durcissement de sécurité et revues de style audit
Transferts confidentiels (extension ZK Token-2022)
Configuration de toolchain, décalages de version, erreurs GLIBC, conflits de dépendances
Mise à jour des versions Anchor/Solana CLI, migration entre versions

Préférer les types Kit (Address, Signer, APIs de message de transaction, codecs).
Préférer les builders d'instruction @solana-program/* à la place des données d'instruction écrites à la main.

Si vous devez intégrer une bibliothèque qui attend des objets web3.js (PublicKey, Transaction, Connection), utilisez @solana/web3-compat comme adaptateur de frontière.
Ne laissez pas les types web3.js fuir dans l'ensemble de l'app ; contenez-les dans des modules adaptateurs.

Par défaut : Anchor (itération rapide, génération IDL, tooling mature).
Performance/footprint : Pinocchio quand vous avez besoin d'optimisation CU, taille binaire minimale, zéro dépendances, ou contrôle fin du parsing/allocations.

Par défaut : LiteSVM ou Mollusk pour les tests unitaires (feedback rapide, exécution in-process).
Utiliser Surfpool pour les tests d'intégration contre un état de cluster réaliste (mainnet/devnet) localement.
Utiliser solana-test-validator seulement quand vous avez besoin de comportements RPC spécifiques non émulés par LiteSVM.

Quand vous résolvez une tâche Solana :

UI : patterns framework-kit.
Scripts/backends : @solana/kit directement.
Bibliothèque legacy présente : introduire un adaptateur de frontière web3-compat.
Programmes haute performance : Pinocchio plutôt qu'Anchor.

Soyez toujours explicite sur :

Quand vous implémentez des changements, fournissez :

fichiers exacts modifiés + diffs (ou sortie style patch)
commandes pour installer/builder/tester
une courte section « risk notes » pour tout ce qui touche la signature/fees/CPIs/transferts de tokens

Un vrai appel RPC/SDK a été émis (mainnet, devnet, ou validateur local) et le payload de réponse est capturé dans la transcription, pas juste paraphrasé
Chaque transaction a été simulée (simulateTransaction ou équivalent) avant toute étape de signature/envoi ; les logs de simulation sont attachés
Pour toute transaction signée/envoyée, la signature résultante est enregistrée et confirmée on-chain (statut retourné par getSignatureStatuses ou URL explorer)
Slippage, priority-fee, et limites de compute-unit ont été définis explicitement avec des valeurs numériques concrètes, pas laissés aux défauts de bibliothèque
Les adresses de compte, mints, et IDs de programme utilisés dans la run correspondent aux adresses solana-development documentées pour le cluster ciblé (pas de mélange mainnet/devnet)
Le chemin d'erreur a été exercé au moins une fois (solde insuffisant, oracle obsolète, blockhash expiré, etc.) et la gestion d'erreur de l'agent a produit un message lisible