khadhroony-solana-project/prompts/011-V0_2_6_START_PROMPT.md

Prompt de démarrage 0.2.6 — Wallet Desk

1. Contexte de reprise

La base attendue est la release stable :

v0.2.5

0.2.1–0.2.4 ont stabilisé le transport HTTP Solana complet :

52/52 méthodes HTTP courantes typées
14/14 méthodes historiques Deprecated conservées pour compliance
getBalance disponible depuis la foundation
Config -> Transport autorisé
Transport -X-> Config

0.2.5 stabilise ksp-wallet-lib et .kspwallet V1 :

format autonome documenté hors Rust
VIEW / OWNER indépendants
Pubkey/alias/notes cachés wallet verrouillé
create/open/inspect in-memory et fichier
Argon2id + XChaCha20-Poly1305 + Ed25519 state authentication
signature Solana OWNER sans getter secret
alias/notes administration
rotations OWNER/VIEW
révocation forte VIEW
create/import no-clobber
remplacement administratif capability-bound
Solana CLI JSON + keypair Base58 import/export
interop et adversarial/security audit validés

Le Wallet reste indépendant de Config, Transport, Tauri, Store et execution policy. solana-keypair reste encapsulée dans Wallet ; les applications consomment les contrats KSP publics.

La release à ouvrir est :

0.2.6 — ksp-app-wallet-desk

La première tranche est 0.2.6-pre.001 et commence par audit de l'état actuel + brainstorming UX/Config/bridge + sizing avant implémentation UI lourde.

2. Mission

Créer :

crates/ksp-app-wallet-desk

comme application Tauri spécialisée et mince qui valide réellement la composition :

ksp-config-lib
+ Config composite
+ ksp-wallet-lib
+ ksp-onchain-transport-lib HTTP
+ ksp-logging-lib

La première version doit au minimum permettre à un utilisateur de :

sélectionner/créer un .kspwallet
inspecter son état verrouillé sans fuite d'identité
ouvrir avec VIEW ou OWNER
voir Pubkey + alias + notes après autorisation
interroger le solde de la Pubkey via le transport HTTP configuré
verrouiller/fermer la capability courante

Le release planning doit également évaluer la surface UI raisonnable pour :

import Solana CLI JSON / Base58
export OWNER explicite
mutation alias/notes
rotation OWNER
rotation VIEW
strong disable/recreate VIEW

Ces capacités appartiennent déjà à Wallet ; l'application ne doit jamais les réimplémenter. pre.001 décide leur découpage exact après sizing, mais ne réduit pas le MVP en dessous de l'ouverture VIEW/OWNER + identité autorisée + balance réseau.

3. Frontières architecturales

Direction autorisée :

ksp-app-wallet-desk
    -> ksp-config-lib
    -> ksp-wallet-lib
    -> ksp-onchain-transport-lib
    -> ksp-core-lib lorsque types/erreurs partagés nécessaires
    -> ksp-logging-lib
    -> Tauri / frontend dependencies

Interdictions :

ksp-wallet-lib -X-> Config/Transport/Tauri
ksp-app-wallet-desk -X-> cryptographie Wallet directe
ksp-app-wallet-desk -X-> solana-keypair direct
ksp-app-wallet-desk -X-> solana-signer direct
ksp-app-wallet-desk -X-> solana-signature direct
ksp-app-wallet-desk -X-> client RPC Solana alternatif
ksp-app-wallet-desk -X-> tracing direct hors adapter Tauri explicitement nécessaire
frontend -X-> secret key material
frontend -X-> localStorage/sessionStorage pour passwords

L'application compose les couches ; elle ne déplace aucune logique métier ou cryptographique dans les commands Tauri ou TypeScript.

4. Config et composition

0.2.6-pre.001 doit réauditer la surface Config existante avant de créer un document.

Le besoin attendu est un document standard Wallet minimal, probablement autour d'un global non secret :

wallets_directory

avec un fallback Config du type :

${KSP_WALLETS_DIRECTORY:-wallets}

mais le shape final doit être décidé par l'audit et validé par JSON Schema. Les règles existantes restent :

• Config est l'unique propriétaire des variables d'environnement KSP ;
• aucun password OWNER/VIEW ni keypair ne doit entrer dans Config ;
• une valeur globale reste hors profils lorsqu'elle ne varie pas par profil ;
• le document standard est enregistré sous un file_id logique cfg.std.* ;
• le composite propre à l'application utilise cfg.composite.ksp-app-wallet-desk ;
• les compositions référencent des file_id, jamais des filenames physiques ;
• les overrides CLI cfgpath/schemapath/file mappings restent ceux de Config.

Le composite Wallet Desk doit sélectionner au minimum les composants nécessaires parmi :

logging
wallet
transport

Le nom exact des component_id, filenames et profils doit être fixé par pre.001/la tranche Config correspondante, pas inventé dans le frontend.

5. Wallet lifecycle dans l'application

Le runtime Rust doit posséder les handles WalletView / WalletOwner. Le frontend ne reçoit que des DTO sûrs.

États UI conceptuels :

aucun wallet sélectionné
wallet sélectionné mais verrouillé
VIEW ouvert
OWNER ouvert
opération privilégiée en cours

Projection verrouillée autorisée :

format_version
view_enabled
filename/path affichable selon policy UI décidée

Projection après unlock :

capability
Pubkey
alias
notes
balance/rpc status lorsque demandé

Les handles OWNER/VIEW ne doivent pas être sérialisés ou copiés dans le frontend.

Le lock explicite doit supprimer le handle Rust possédé par l'application et purger les projections frontend protégées.

6. Passwords et secrets

Les passwords OWNER/VIEW sont des entrées éphémères :

UI input
-> invoke Tauri
-> wrapper OwnerPassword/ViewPassword côté Rust
-> utilisation Wallet
-> drop/zeroization selon contrat Wallet

Interdictions :

• ne jamais écrire un password dans Config, .env, logs, Debug, localStorage ou sessionStorage ;
• ne jamais retourner un password dans un DTO ;
• ne jamais exposer la keypair ou les 64 octets secret au frontend pour signer ;
• ne jamais journaliser le contenu d'un export secret ;
• ne pas conserver inutilement les passwords en état TypeScript après l'invocation.

Les exports OWNER sont des opérations explicitement privilégiées et doivent utiliser une UX de confirmation intégrée.

7. Balance réseau

Le cas réseau minimal est :

Wallet VIEW/OWNER ouvert
-> ksp_core_lib::Pubkey
-> HttpTransportPool::getBalance
-> DTO balance sûr
-> UI

Wallet ne dépend pas de Transport. L'application possède la composition et choisit le profil Transport via Config.

Le balance refresh doit :

• fonctionner avec VIEW comme avec OWNER ;
• rester explicitement déclenchable/rafraîchissable ;
• distinguer erreur Wallet, erreur Config et erreur Transport sans recopier des payloads secrets ;
• ne pas inventer de cache réseau dans Wallet ;
• préserver les règles de redaction URL/credentials de Transport.

8. UI/UX à auditer en pre.001

Évaluer au minimum les vues/flows suivants :

Dashboard / status runtime
Wallet inventory ou sélection fichier
Locked wallet inspection
Create wallet
Import wallet
Unlock VIEW
Unlock OWNER
Wallet details : Pubkey / alias / notes
Balance / transport profile / refresh
Metadata administration OWNER
Credentials/security : rotate OWNER/VIEW, disable/recreate VIEW
Export OWNER
Logging diagnostics contrôlés

Le sizing décide si tous ces flows tiennent dans 0.2.6 sans dégrader la qualité. Une tranche supplémentaire est préférable à une UI qui contourne les contracts Wallet.

Les interactions destructives ou privilégiées utilisent des modals Bootstrap intégrés, pas window.alert, window.confirm ou window.prompt.

9. Référence Tauri existante

ksp-app-config-desk est le template principal à réauditer avant création :

frontend/
frontend/ts/
frontend/sass/
frontend/ts/bindings/
Vite
Bootstrap
SimpleBar si utile
TS-RS pour DTO applicatifs
splash + main window
Tauri capabilities explicites

Ne pas copier aveuglément les dépendances inutiles. Réutiliser les patterns éprouvés et supprimer ce qui n'a pas de besoin Wallet Desk réel.

Le port de développement doit être réservé distinctement de Config Desk après audit des ports déjà utilisés.

Le build frontend standalone npm run check reste un type-check/lint/test, pas un production build. Le build production final est déclenché par Tauri via beforeBuildCommand.

10. Logging

L'application doit rester dans l'écosystème tracing KSP :

ksp-logging-lib
+ tauri-plugin-tracing
+ @fltsci/tauri-plugin-tracing

Ne pas utiliser tauri-plugin-log.

Le bridge frontend -> Rust doit reprendre/refondre le pattern validé de Config Desk. Toutes les interactions UI importantes doivent être instrumentées à debug ou trace sans secret : clics, navigation, sélection wallet, refresh balance, unlock result, mutations, modals, changements d'état et remplacements DOM pertinents.

Les fichiers logs restent uniques par lancement selon la politique KSP existante.

11. DTOs Tauri

Les commands Tauri doivent exposer des DTOs applicatifs sûrs, pas les types internes Wallet complexes lorsque cela élargit la surface inutilement.

DTOs à auditer :

WalletInventoryEntryDto
LockedWalletDto
WalletAuthorizedDto
WalletBalanceDto
WalletCreateRequestDto
WalletImportRequestDto
WalletUnlockRequestDto
WalletMetadataMutationDto
WalletSecurityStatusDto
WalletOperationResultDto

Les noms sont indicatifs ; pre.001 doit les rationaliser. Les DTOs ne contiennent jamais de secret key material.

TS-RS reste une frontière applicative Tauri. Ne pas ajouter des dérivations TS-RS dans ksp-wallet-lib uniquement pour cette app.

12. Inventory et chemins Wallet

Wallet core reçoit toujours un chemin explicite. Si Wallet Desk affiche un inventaire de fichiers sous un répertoire configuré, cette énumération est une responsabilité de composition/application, pas une raison d'ajouter Config ou directory discovery dans ksp-wallet-lib.

L'audit doit fixer :

• extension .kspwallet filtrée ;
• symlinks et fichiers non réguliers ;
• traversal/path escape ;
• comportement sur répertoire absent ;
• refresh manuel/automatique ;
• affichage filename vs alias protégé ;
• no-clobber create/import/export.

Aucun alias ne doit être dérivé du filename ; l'alias reste metadata protégée interne au wallet.

13. Administration OWNER

Les opérations OWNER existent déjà et doivent être appelées directement :

sign
update_alias
add_note
update_note
delete_note
rotate_owner_password
rotate_view_password
disable_view
recreate_view
export_transfer / export_transfer_file

Le frontend doit refléter les permissions : les controls OWNER ne sont pas affichés/activés comme disponibles sous VIEW.

Un wallet.state_conflict doit déclencher un message de conflit/refresh explicite, pas une réécriture forcée ou un retry aveugle.

14. Import/export

Formats acquis :

Solana CLI JSON
Solana keypair Base58 complet

Import :

source externe
-> inspection facultative
-> nouveau .kspwallet no-clobber

Export :

OWNER uniquement
-> destination nouvelle no-clobber

Le frontend ne doit pas recevoir le secret si un export fichier peut être effectué entièrement côté Rust. Un éventuel export texte/copie clipboard doit être traité comme une nouvelle surface de fuite et n'est pas supposé requis par défaut.

15. Tests

15.1 Rust déterministe

Couvrir au minimum :

• mapping Config composite -> wallet path + transport settings ;
• inventory/path safety ;
• locked projection sans Pubkey/metadata ;
• VIEW/OWNER capability mapping ;
• secret absence des DTOs et Debug ;
• balance DTO mapping avec serveur HTTP local/fixture ;
• no-clobber create/import/export ;
• state conflict surfacé correctement ;
• commands Tauri délèguent aux APIs Wallet/Transport au lieu de réimplémenter.

15.2 Frontend

Au minimum :

npm run check

Ajouter des tests ciblés seulement lorsque leur valeur est démontrée ; ne pas construire le bundle production dans ce script.

15.3 Smoke Devnet opt-in

Wallet Desk est une surface légitime de composition Config -> Wallet -> Transport. Un smoke Devnet opt-in peut donc vivre dans l'application ou une sous-surface d'intégration qu'elle possède.

Scénario recommandé :

Config composite Devnet
-> Wallet test-only/éphémère ouvert
-> Pubkey
-> Transport getBalance
-> résultat RPC valide, y compris 0 lamport

Le smoke ne doit pas utiliser un secret de production ni exiger un wallet financé.

16. Sécurité desktop

Préserver les règles acquises de Config Desk :

• pas de dialogues navigateur natifs pour les interactions applicatives normales ;
• pas de persistence frontend des secrets ;
• CSP/capabilities Tauri réaudités ;
• commands privilégiées minimales ;
• aucun path arbitraire non validé ne doit permettre de sortir silencieusement de la racine Wallet choisie lorsqu'une opération est censée être root-scoped ;
• les erreurs UI ne recopient pas de payload secret ou d'URL RPC credentialée.

Les file pickers natifs éventuellement nécessaires doivent être évalués comme surface Tauri explicite, pas ajoutés implicitement.

17. Validation finale Tauri

Après les validations ciblées et workspace :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-wallet-desk
cargo test --workspace
npm run check --prefix crates/ksp-app-wallet-desk

Le build Tauri de production est la dernière opération de validation :

cargo tauri build -c crates/ksp-app-wallet-desk/tauri.conf.json

Le smoke Devnet opt-in, s'il est livré, est exécuté séparément avec une commande documentée.

18. Gate pre.001

Avant toute implémentation lourde, 0.2.6-pre.001 doit produire :

1. audit de ksp-app-config-desk comme template Tauri ;
2. audit de la surface publique finale ksp-wallet-lib ;
3. audit de Config composite et besoin exact d'un std.wallet ;
4. audit de la surface Transport nécessaire (getBalance au minimum) ;
5. UX/screen map ;
6. DTO/command map ;
7. threat model desktop/password/export ;
8. stratégie inventory/path ;
9. stratégie tests + smoke Devnet ;
10. sizing détaillé et forecast souple des prereleases.

Si le scope UI complet ne tient pas dans une release clôturable, scinder les fonctionnalités non essentielles avant implémentation lourde, mais préserver le MVP identité + balance.

19. Forecast initial non contraignant

Point de départ à réviser par pre.001 :

pre.001 audit/sizing/UX/Config/bridge/security
pre.002 crate Tauri + frontend shell + logging + splash/main
pre.003 std.wallet + composite Wallet Desk + adapters Config
pre.004 inventory/selection + locked inspection + DTOs
pre.005 create/import + unlock VIEW/OWNER + lifecycle
pre.006 wallet details + balance HTTP + refresh/diagnostics
pre.007 metadata administration + rotations VIEW/OWNER
pre.008 strong VIEW disable/recreate + export OWNER + security UX
pre.009 integration tests + Devnet smoke + compliance/security review
pre.010 README/USAGE/build final + prompt 0.2.7 si nécessaire
rel.001 publication stable

Cette séquence est un forecast, pas un engagement. pre.001 peut la réduire, l'étendre ou la resegmenter selon l'audit réel.

20. Hors périmètre

modification du wire .kspwallet V1 sans défaut démontré
WalletPolicy / execution policy
construction/simulation/envoi de transaction
WebSocket/gRPC
Store
hardware wallet/Ledger
remote signer
mobile/browser extension
cloud custody
trading

Le Wallet Desk valide et administre Wallet ; il ne devient pas l'application globale KSP.

21. Résultat attendu de 0.2.6

À la clôture stable :

une app Tauri spécialisée existe
Config composite sélectionne logging/wallet/transport proprement
aucun secret Wallet n'est déplacé dans Config ou frontend persistence
un .kspwallet peut être créé/sélectionné/ouvert avec VIEW ou OWNER
Pubkey/alias/notes ne sont affichés qu'après autorisation
la balance de la Pubkey est lisible via Transport HTTP
les opérations OWNER retenues par le sizing délèguent à ksp-wallet-lib
logging frontend/Rust est instrumenté sans secret
les validations Rust/frontend/Tauri sont vertes
un smoke Devnet de composition est disponible si retenu par le gate
README/USAGE et prompt de suite sont synchronisés