khadhroony-solana-project/prompts/005-V0_2_1_START_PROMPT.md

Prompt de démarrage 0.2.1 — ouverture des capacités Solana N2

Contexte de reprise

La base attendue est la release stable v0.1.4 de khadhroony-solana-project. Les fondations ksp-core-lib, ksp-logging-lib, ksp-config-lib et la première application de référence ksp-app-config-desk sont alors stabilisées.

0.2.x ouvre les capacités Solana N2. Les candidats déjà retenus par l’architecture sont notamment :

• ksp-wallet-lib puis une application wallet spécialisée ;
• ksp-onchain-transport-lib ;
• ksp-interface-lib pour les contrats wire/réexports/réimplémentations compatibles ;
• plus tard ksp-program-api / ksp-program-lib puis la chaîne d’exécution.

Wallet, transport on-chain et Interface sont partiellement indépendants. Ne pas supposer leur ordre sans le réévaluer.

Première mission : 0.2.1-pre.001

La première prerelease est une tranche de brainstorming, audit et planification, pas une grosse implémentation.

Elle doit :

1. partir de la base stable v0.1.4 et relire ROADMAP.md, docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md, les règles N1/N2 et les décisions d’architecture ;
2. inventorier les besoins réels et dépendances pour Wallet, transport on-chain et Interface/wire ;
3. sélectionner un seul premier périmètre fonctionnel borné pour 0.2.1 ;
4. justifier cet ordre par les premiers scénarios d’usage et les dépendances réelles, pas par symétrie avec bot2/bot3 ;
5. définir les contrats publics minimaux, hors-périmètre, risques, dépendances externes, tests et critères de clôture ;
6. produire le plan détaillé docs/plans/007-V0_2_1_..._PLAN.md avec une prévision souple des prereleases ;
7. ne commencer le développement fonctionnel qu’après validation de ce plan.

Contraintes architecturales à préserver

• Rust 2024, unsafe interdit, pas de unwrap/expect/panic ni opérateur ? selon les règles KSP ;
• dépendances externes communes sous [workspace.dependencies] puis .workspace = true ;
• ksp-config-lib reste seul propriétaire de Config, .env, environnement et persistence Config ;
• ksp-logging-lib reste seule façade/propriétaire du runtime tracing ;
• les applications Tauri restent minces et suivent le modèle validé par Config Desk ;
• cargo tauri build -c ... reste la dernière opération de validation Tauri ;
• les executables KSP ne dépendent pas directement des crates Solana/protocoles au-delà des exceptions bas niveau explicitement autorisées ;
• ksp-interface-lib possède les interfaces/wires Solana/SPL/Metaplex nécessaires lorsqu’un réexport contrôlé ou une réimplémentation compatible est préférable à une dépendance métier directe ;
• les APIs publiques extensibles utilisent les crates *-api prévues par l’architecture ;
• les demos/scénarios restent spécialisés et ne dupliquent pas la logique des bibliothèques.

Points à réexaminer explicitement

Wallet

Évaluer format KSP, stockage/chiffrement, import/export, pubkey/signature, séparation secret/public, profils/réseaux et frontière avec Config. Ne pas déplacer les secrets wallet dans Config par commodité.

Transport on-chain

Évaluer RPC HTTP/WS, providers, timeouts/retry/backoff, subscriptions, modèles de réponse homogènes, séparation transport/store et configuration des endpoints. Aucun Store n’est introduit dans 0.2.1 sauf décision explicite de replanification.

Interface/wire

Réévaluer la politique de réexport/réimplémentation pour les interfaces Solana/SPL/Metaplex déjà identifiées. La crate doit éviter les doublons de versions et permettre aux crates KSP supérieures de ne pas dépendre directement des bibliothèques métier externes.

Discipline de session

• pre.001 : réflexion + plan ;
• prereleases suivantes : tranches bornées ;
• dernière prerelease : validations finales, documentation, nettoyage, changelog et prompt suivant ;
• un défaut livré reçoit un fix.NNN, il n’est pas réécrit silencieusement ;
• tous les deltas 0.2.1 sont commités.

Commencer la session par l’audit/brainstorming de 0.2.1-pre.001 et proposer la sélection du premier périmètre N2 avant toute modification fonctionnelle.