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

<!-- file: prompts/011-V0_2_6_START_PROMPT.md -->
<!-- version: 1 -->

# Prompt de démarrage `0.2.6` — Wallet Desk

## 1. Contexte de reprise

La base attendue est la release stable :

```text
v0.2.5
```

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

```text
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 :

```text
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 :

```text
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 :

```text
crates/ksp-app-wallet-desk
```

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

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
wallets_directory
```

avec un fallback Config du type :

```text
${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 :

```text
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 :

```text
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 :

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

Projection après unlock :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
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 :

```text
Solana CLI JSON
Solana keypair Base58 complet
```

Import :

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

Export :

```text
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 :

```text
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é :

```text
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 :

```bash
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 :

```bash
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` :

```text
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

```text
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 :

```text
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
```