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

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

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

> **Statut : consommé et clôturé par la release stable `v0.2.6`.** Ce document reste la trace du contrat de reprise de `0.2.6`; il ne doit plus être utilisé comme prompt actif. La prochaine session utilise [`012-V0_2_7_START_PROMPT.md`](012-V0_2_7_START_PROMPT.md).

## 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. Contrat de session et sources de vérité obligatoires

Cette nouvelle session doit être autonome : **ne pas reconstruire les règles de mémoire, ne pas improviser les conventions et ne pas commencer par coder**.

La source de vérité est, dans cet ordre :

1. l'archive/repository opérateur réellement fourni pour la base stable `v0.2.5` ;
2. les règles KSP versionnées ;
3. les documents d'architecture/plans/validation actuels ;
4. les contrats publics réellement présents dans les crates ;
5. les sources externes officielles actuelles lorsque le comportement d'une dépendance ou de Tauri/Solana doit être vérifié ;
6. les anciennes générations bot3 uniquement comme référence historique, jamais comme autorité supérieure aux règles KSP actuelles.

Avant toute modification, relire au minimum, **dans cet ordre** :

```text
RULES.md
docs/000-README.md

docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/PROMPT_STRUCTURE.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/FILE_CONTRACTS.md

docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md

docs/formats/KSPWALLET_V1.md
docs/validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md
crates/ksp-wallet-lib/README.md
crates/ksp-wallet-lib/USAGE.md
```

Réauditer ensuite les surfaces réellement consommées dans :

```text
crates/ksp-core-lib
crates/ksp-logging-lib
crates/ksp-config-lib
crates/ksp-onchain-transport-lib
crates/ksp-wallet-lib
crates/ksp-app-config-desk
```

Ne jamais supposer une API ou une convention parce qu'elle existait dans une session précédente. Si le repository réel contredit ce prompt, **le repository + les règles versionnées priment**, et l'écart est signalé avant de bâtir dessus.

## 4. Première mission `pre.001` — méthode d'ouverture obligatoire

`0.2.6-pre.001` est d'abord une tranche d'**audit, conception, inventaire et sizing**. L'implémentation UI lourde ne commence pas avant son gate.

Ordre de travail obligatoire :

```text
1. relire les sources internes obligatoires
2. vérifier la base stable et les versions réellement présentes
3. exécuter l'audit Rust structurel existant avant modification
4. auditer Config Desk comme référence Tauri sans le copier aveuglément
5. auditer les APIs publiques finales Config / Wallet / Transport / Logging
6. vérifier sur les sources officielles actuelles les dépendances Tauri/frontend réellement nécessaires
7. produire screen map + command/DTO map + threat model + matrice Config/composition
8. dimensionner les prereleases
9. seulement ensuite commencer l'implémentation de `pre.002` ou la petite fondation explicitement validée par le gate
```

Le premier audit Rust de la session doit inclure :

```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```

Une commande non exécutée n'est jamais déclarée réussie. Un warning, une exception globale ou une violation de règles n'est pas accepté comme « assez bon » pour avancer.

## 5. Prévision souple initiale des prereleases

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 suivant si nécessaire
rel.001 publication stable
```

Cette séquence est un **forecast souple**, pas un engagement de clôture au numéro `pre.010`. `pre.001` doit la recalibrer avec un sizing concret. Si une tranche révèle un manque, insérer une prerelease ou un `fix` est préférable à forcer la clôture. Le numéro de tranche n'a jamais priorité sur la complétude du contrat.

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

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

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

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

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

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

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

Aucun script npm de contrôle/dev/build n’est lancé directement par l’opérateur. Tauri possède le cycle frontend et déclenche ses hooks npm ; le build production final reste déclenché via `beforeBuildCommand`.

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

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

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

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

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

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

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

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

## 20. Discipline Rust et normalisation workspace

Toute modification Rust de `0.2.6` respecte **simultanément** `rustfmt`, Clippy et les règles structurelles KSP. Le script d'audit n'est pas optionnel.

Rappels qui doivent être appliqués dès le premier patch, y compris dans les tests :

- `use` uniquement pour des traits réellement nécessaires à la résolution de méthode/contrainte du langage, annotés `rust-rules: trait-import` ;
- aucun import non-trait, alias de `use`, glob ou groupe `{...}` ;
- les `use` restent au début du module, jamais dans une fonction/méthode/test ;
- un item KSP `pub` ou `pub(crate)` partagé est réexporté au crate-root et consommé via le chemin le plus court (`crate::Item` dans sa crate, `ksp_*::Item` depuis une autre crate) ;
- `super::Item` dans un test n'est utilisé que pour un item strictement privé du module parent ;
- aucun `crate::module::Item` pour contourner une façade crate-root ;
- aucun alias de réexport pour résoudre une collision : renommer l'item dans son module propriétaire avec un nom canonique ;
- rustdoc utile pour tout `pub`/`pub(crate)` et leurs champs/méthodes visibles ;
- blocs homogènes ordonnés alphabétiquement lorsque l'ordre n'est pas sémantique ; façade `pub use` puis `pub(crate) use` ; constantes `pub`, puis `pub(crate)`, puis privées ;
- aucune ligne vide dans le corps d'une fonction/méthode ni à l'intérieur d'un `struct`/`enum` ; les lignes vides séparent les items ;
- les versions de fichiers modifiés sont incrémentées conformément aux règles KSP.

Le contrôle mécanique obligatoire est :

```bash
python3 scripts/audit_rust_workspace_rules.py
```

`cargo fmt` et Clippy **ne remplacent pas** ce contrôle.

## 21. Workflow version, delta et validation opérateur

Chaque tranche technique conserve les conventions KSP :

```text
Cargo workspace.package.version : 0.2.6-pre.N ou 0.2.6-pre.N.fix.M
Delta : deltas/0.2.6/pre.NNN.md ou pre.NNN-fix.MMM.md
Commit : v0.2.6-pre.NNN ou v0.2.6-pre.NNN-fix.MMM
Tag Git : uniquement pour la release stable finale v0.2.6
```

Une modification code/build/runtime/config/migration incrémente le signal technique Cargo. Une tranche réellement documentaire ne le fait pas. Le delta de livraison contient uniquement les fichiers ajoutés/modifiés nécessaires à la tranche, jamais une archive complète du repository.

Après toute modification Rust, ordre minimal :

```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
```

Puis tests ciblés pendant le développement. Aux checkpoints globaux et à la clôture :

```bash
cargo test --workspace
```

Pour toute dépendance ajoutée/mise à niveau :

- vérifier la version stable réellement actuelle depuis la source primaire ;
- documenter les features réellement nécessaires ;
- exécuter les `cargo tree`/inverse trees pertinents ;
- ne pas conserver une génération ancienne uniquement par inertie ;
- ne pas forcer une unification impossible si deux dépendances externes imposent légitimement des générations différentes.

Les résultats opérateur collés dans la session deviennent la preuve de validation. Ne jamais inventer une validation locale non exécutée.

## 22. Validation finale Tauri

Après les validations ciblées et workspace :

```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-app-wallet-desk
cargo test --workspace
```

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

```bash
(cd crates/ksp-app-wallet-desk && cargo tauri build)
```

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

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

Le gate n'est considéré franchi que si ces livrables sont écrits/consignés dans le delta/plan, que les dépendances nécessaires sont auditées et que la prévision de prereleases est explicitement recalibrée. Une simple discussion en chat sans matérialisation durable ne clôt pas `pre.001`.

## 24. Hors périmètre

```text
modification destructive du wire V1 stable ; V2 binaire est ajouté explicitement en `pre.015+` sans réécrire V1
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.

### TODO futur `0.2.11` — prix offchain dans Wallet Desk

La visualisation de prix offchain n'appartient pas au scope de `0.2.6`. Une application spécialisée de visualisation de prix offchain doit d'abord être réalisée et valider durablement ses sources, contrats, rafraîchissement, cache et UX.

Pour `0.2.11`, prévoir explicitement un chantier d'intégration de cette capacité dans `ksp-app-wallet-desk` afin qu'un wallet puisse afficher les informations de prix offchain pertinentes sans dupliquer la logique de récupération/normalisation possédée par le composant spécialisé. Le futur travail devra réauditer la frontière entre application, bibliothèque/service partagé et Transport avant implémentation ; le TODO n'autorise pas l'ajout anticipé de logique de prix dans Wallet Desk pendant `0.2.6`.

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

## 26. Instruction d'ouverture

Commencer la nouvelle session par **la relecture effective des sources internes obligatoires et l'audit de la base stable `v0.2.5`**. Ne pas répondre uniquement à partir de ce prompt ou de souvenirs de sessions précédentes.

Ensuite :

1. vérifier l'état réel de `ksp-app-config-desk`, Config, Wallet, Transport et Logging ;
2. exécuter la validation Rust structurelle de base ;
3. consulter les documentations officielles actuelles nécessaires pour Tauri/plugins/frontend ;
4. produire l'audit/sizing `0.2.6-pre.001`, avec screen map, DTO/commands, Config/composite, sécurité et forecast recalibré ;
5. **ne pas commencer l'implémentation UI lourde avant ce gate**.

Les règles de la session ne doivent pas être renégociées au fil des corrections : elles sont dans les documents KSP versionnés et doivent être appliquées dès chaque premier patch. Si un conflit ou une règle manquante est découvert, corriger la règle et son contrôle durable avant de propager une nouvelle convention.

## `pre.014-fix.001` — retour opérateur après reprise de session

Le correctif de polish après `pre.014` traite uniquement les régressions de gabarit et de canari :

```text
sidebar/content : aucun wrap lors du redimensionnement
Wallet Desk : header/footer/shell card alignés sur Config Desk
Wallet Desk : suppression de #shellStatus
splash : #debug-info sur toute la largeur
canari pre.013 : ne plus figer la phase shell historique
version technique : 0.2.6-pre.14.fix.1
```

Le workflow Tauri reste crate-local. En debug, les deux binaires recalent ensuite leur current working directory sur la racine du workspace via `CARGO_MANIFEST_DIR/../..`; la stratégie release/bundle reste un point explicite à fermer dans la candidate finale `pre.018`.

## Addendum `pre.015` — V2 binaire intercalé

Après validation du polish `pre.014-fix.001`, la release est volontairement étendue : `pre.015` wire/codec V2, `pre.016` APIs génériques/versionnées et V2 runtime, `pre.017` migration/régression, `pre.018` candidate finale. Le prompt `0.2.7` redevient WebSocket Solana standard.

## Addendum `pre.016` — runtime V2 et façade multi-version matérialisés

`pre.016` matérialise la politique figée en `pre.015` : `DEFAULT_WALLET_FORMAT = V2`, APIs génériques de création/import en V2, lecture/inspection V1/V2 auto-détectée, variantes `_v1`/`_v2` strictes et Wallet Desk consommant uniquement la façade non versionnée. Les handles OWNER/VIEW persistent leurs mutations dans le format natif ouvert ; aucune conversion implicite V1 -> V2 n'est effectuée.

`pre.017` matérialise la migration explicite OWNER-authentifiée V1 -> V2 : conversion mémoire, copie filesystem no-clobber, remplacement in-place stale-protected, conservation identité/metadata/note IDs, cible VIEW explicite et canaris tampering/state-conflict. Wallet Desk reste version-neutral et aucune ouverture ne migre implicitement. La prochaine tranche est `pre.018`, dédiée à la documentation/candidate finale, au packaging/CWD et au build Tauri en toute dernière opération.

## Addendum `pre.018` — candidate finale et runtime packagé

Le checkpoint opérateur `pre.017` est entièrement vert : fmt/audit/check/clippy/workspace tests passent, les canaris migration V1 -> V2 sont verts et le parcours Tauri confirme qu'un import Wallet Desk crée réellement un V2 puis exécute `getBalance` sur Devnet.

`pre.018` matérialise la candidate finale : README/USAGE Wallet Desk, compliance/documentation synchronisée, versions applicatives alignées, et fermeture du comportement distribué. Les deux Desks embarquent les huit documents Config/schemas enregistrés comme resources Tauri ; en release, `ksp-config-lib` prépare une racine KSP user-writable commune via `ProjectDirs`, seed les Config uniquement lorsqu'elles sont absentes, resynchronise les schemas, n'embarque jamais `.env`, puis le runtime Tauri active cette racine comme CWD avant `AppState::initialize`.

Après application de `pre.018`, toutes les validations et parcours fonctionnels sont exécutés avant `(cd crates/ksp-app-wallet-desk && cargo tauri build)`, qui reste l'absolue dernière opération. Si ce gate est vert, la seule étape suivante est `0.2.6-rel.001` avec version stable `0.2.6`, mise à jour du `CHANGELOG.md` et tag `v0.2.6`; aucune nouvelle fonctionnalité n'est introduite en `rel.001`.