v0.1.4-pre.019

prompts/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/000-README.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Prompts KSP
 
@@ -25,3 +25,4 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
 - [`002-V0_1_2_START_PROMPT.md`](002-V0_1_2_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.2 — Logging foundation` après publication stable de `0.1.1`.
 - [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
 - [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.
+- [`005-V0_2_1_START_PROMPT.md`](005-V0_2_1_START_PROMPT.md) — prompt de reprise préparé à la clôture de `0.1.4`; il ouvre `0.2.1-pre.001` par un brainstorming visant à sélectionner le premier périmètre N2 borné.

prompts/005-V0_2_1_START_PROMPT.md

@@ -0,0 +1,68 @@
+<!-- file: prompts/005-V0_2_1_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# 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.