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

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.

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

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 :

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 :

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 :

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 :

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 :

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.

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 :

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.

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 :

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.

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

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

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

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

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 :

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 :

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 :

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 :

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.

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 :

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

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 :

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 :

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 :

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 :

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 :

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 :

(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

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 :

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 :

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.