69 lines
4.2 KiB
Markdown
69 lines
4.2 KiB
Markdown
<!-- 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.
|