v0.2.5-rel.001

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 54 -->
+<!-- version: 55 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -37,7 +37,7 @@ Séquence par défaut :
 0.1.4  ksp-app-config-desk
 ```
 
-`0.1.1`, `0.1.2`, `0.1.3`, `0.1.4`, `0.2.0` et `0.2.1` sont désormais des releases stables.
+`0.1.1`, `0.1.2`, `0.1.3`, `0.1.4` et `0.2.0` à `0.2.5` sont désormais des releases stables.
 
 `0.1.4 — ksp-app-config-desk` établit le modèle de référence des futures applications Tauri KSP sans déplacer la logique Config dans l'application. Sa matrice finale a été validée avant `rel.001`, avec le build Tauri exécuté en dernière opération.
 
@@ -365,7 +365,7 @@ Par défaut :
 0.2.8  Helius LaserStream WebSocket
 0.2.9  Yellowstone gRPC standard foundation
 0.2.10 off-chain price transport
-0.2.11 price visualization desk
+0.2.11 price visualization desk + intégration prix dans Wallet Desk
 0.2.12 interface/wire foundation
 0.2.13 program-api foundation
 ```
@@ -406,7 +406,7 @@ Le design retient un **metadata read-only VIEW de niveau B** : une clé Ed25519
 
 Le format V1 est cadré comme JSON UTF-8 strict avec binary Base64url sans padding, `format_version`, paramètres Argon2id sérialisés, key slots génériques, owner-control/metadata/secret séparés et XChaCha20-Poly1305. **V1 est entièrement autonome** : aucun salt externe, pepper, OTP, secret KSP, service distant ou ancre externe n'est requis. Les paramètres Argon2 de création ne sont gelés qu'après benchmark. VIEW peut rewrapper le même accès metadata sous un nouveau password VIEW, ce qui remplace son credential courant sans constituer une révocation cryptographique forte d'un ancien détenteur ayant déjà extrait le matériau VIEW. OWNER peut également changer le password VIEW sans connaître l'ancien, changer son propre password, ou rekey les metadata pour une révocation VIEW forte, sans jamais changer la keypair Solana. La keypair V1 reste immuable après création/import. Tout import crée un nouveau `.kspwallet` avec sémantique no-clobber ; il ne remplace jamais un `.kspwallet` existant et ne sert jamais à muter sa keypair.
 
-La release doit fournir `docs/formats/KSPWALLET_V1.md` comme spécification séparée et indépendante de Rust, accompagnée de vecteurs publics auto-contenus permettant une réimplémentation dans un autre langage. La prévision est étendue jusqu'à `pre.010` afin de séparer codec, crypto, capabilities, persistence, administration, import/export, security audit et documentation interopérable. Le plan actif est `docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`.
+La release fournit `docs/formats/KSPWALLET_V1.md` comme spécification séparée et indépendante de Rust, accompagnée de vecteurs publics auto-contenus permettant une réimplémentation dans un autre langage. La trajectoire a été étendue jusqu'à `pre.010` afin de séparer codec, crypto, capabilities, persistence, administration, import/export, security audit et documentation interopérable. Le plan historique clôturé est `docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`.
 
 `0.2.5-pre.002` matérialise la crate sans ouvrir encore le codec ou la cryptographie du fichier : `WalletView`/`WalletOwner`, `WalletCapability`, projections `LockedWalletInfo`/`WalletInfo`/`WalletNote`, wrappers `ViewPassword`/`OwnerPassword`, codes d’erreur Wallet et target de logging explicite `ksp-wallet-lib`. La crate dépend seulement de Core, Logging et `zeroize`; elle consomme la Pubkey exclusivement via `ksp_core_lib::Pubkey` et ne dépend directement ni de `solana-pubkey`, ni de Config, Transport, ExecutionPolicy, Store ou Tauri. Les primitives Solana keypair/signature ne seront ajoutées que lorsqu’elles seront réellement consommées.
 
@@ -418,7 +418,7 @@ La release doit fournir `docs/formats/KSPWALLET_V1.md` comme spécification sép
 
 `0.2.5-pre.006` ajoute la persistence native sans Config : `create_wallet_file_v1` reçoit un chemin explicite du caller et publie uniquement en no-clobber via un fichier temporaire créé dans le même répertoire, écrit puis `sync_all` avant `persist_noclobber`; `open_wallet_view_file_v1`, `open_wallet_owner_file_v1` et `inspect_locked_wallet_file_v1` effectuent une lecture bornée à la limite V1 avant de déléguer au parser/crypto acquis. Les opérations filesystem bloquantes sont isolées par `spawn_blocking`. Les tests couvrent destination existante, concurrence avec un seul gagnant, fault injection avant publication, cleanup ordinaire des temporaires et rejet d'un fichier surdimensionné. La synchronisation du répertoire parent est best-effort sur Unix et n'est pas transformée en garantie portable de crash-durability. Les ACL/permissions OS restent hors du modèle Wallet.
 
-`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, l’inspection sûre limitée à Pubkey+format, l’import no-clobber vers un nouveau `.kspwallet` et l’export OWNER en mémoire/fichier. La source d’import reste inchangée, VIEW n’exporte jamais, aucun `bs58` direct n’est ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` ferme ensuite le gate adversarial/security/interoperability/compliance : canaris de tampering et non-oracle, reproduction indépendante des vecteurs, audit des frontières et graphes Cargo. Le checkpoint opérateur est vert. `pre.010` finalise README/USAGE, la spec, les graphes, la matrice de clôture et le prompt `0.2.6` sans changement de code ni de version Cargo technique. `rel.001` est la prochaine étape et reste strictement publicationnelle.
+`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, l’inspection sûre limitée à Pubkey+format, l’import no-clobber vers un nouveau `.kspwallet` et l’export OWNER en mémoire/fichier. La source d’import reste inchangée, VIEW n’exporte jamais, aucun `bs58` direct n’est ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` ferme ensuite le gate adversarial/security/interoperability/compliance : canaris de tampering et non-oracle, reproduction indépendante des vecteurs, audit des frontières et graphes Cargo. `pre.010` finalise README/USAGE, la spec, les graphes, la matrice de clôture et le prompt `0.2.6`. Les fixes `pre.010-fix.001`–`fix.003` mettent le Dalek direct à `3.0.0`, normalisent le Rust workspace, ajoutent l'audit structurel Python et réconcilient celui-ci avec rustfmt. Le checkpoint final est vert ; `0.2.5-rel.001` publie cette surface sans nouvelle capacité runtime.
 
 ## `0.2.6` — Wallet Desk
 
@@ -450,7 +450,7 @@ Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après
 
 `0.2.10` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
 
-`0.2.11` ajoute une petite application desk de visualisation/validation.
+`0.2.11` ajoute une petite application desk de visualisation/validation. Après stabilisation de cette application spécialisée, la même release doit intégrer la capacité de prix offchain dans `ksp-app-wallet-desk` sans dupliquer la récupération/normalisation appartenant au composant spécialisé.
 
 Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.