# 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.