v0.2.5-pre.001

Cargo.toml

@@ -6,7 +6,7 @@ resolver = "3"
 members = ["crates/ksp-app-config-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib", "crates/ksp-onchain-transport-lib"]
 
 [workspace.package]
-version = "0.2.4"
+version = "0.2.5-pre.1"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 43 -->
+<!-- version: 45 -->
 
 # Roadmap KSP
 
@@ -49,7 +49,7 @@ Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. U
 - [X] `0.2.2` — HTTP Accounts + Tokens + Cluster : 22 wrappers typés (5 Accounts + 5 Tokens + 12 Cluster), canaries de complétude 52+14, smoke Devnet Transport pur et smoke historique Config -> Transport validés, documentation durable et prompt `0.2.3` publiés stables.
 - [X] `0.2.3` — HTTP Transactions stable : 11/11 wrappers typés publiés, classification `8 Read / 2 WriteSubmission / 1 Simulation`, no-resend ambigu prouvé pour les write submissions, `KSP-TRANSPORT-007` réaudité conforme sur les 37 wrappers HTTP courants, graphes Cargo et deux smokes Devnet validés ; `0.2.4` reprend les 15 Blocks/Economics restants.
 - [X] `0.2.4` — HTTP Blocks + Economics stable : 15/15 wrappers `V0_2_4` publiés, surface typed complète à 52/52 méthodes courantes, 14/14 historiques conservées, réaudit SIMD/inventaire final et `KSP-TRANSPORT-007` global validés ; deux smokes Devnet passés avant publication.
-- [ ] `0.2.5` — Introduire `ksp-wallet-lib` et le format interopérable `.kspwallet` avec threat model offline, capacités indépendantes VIEW/OWNER, metadata protégées, signature, rotations de key slots et import/export extensible ; exclure `WalletPolicy`.
+- [/] `0.2.5` — Wallet foundation ouverte par `pre.001` : threat model offline et héritage bot2/bot3 réaudités, `.kspwallet` V1 entièrement autonome sans facteur externe, design content-keys/key-slots VIEW/OWNER indépendant, read-only VIEW niveau B via autorité Ed25519 de format distincte couvrant tout état mutable, keypair V1 immuable, spec multi-langages séparée + vecteurs publics exigés, paramètres KDF à benchmarker avant freeze, persistence/signature/rotations/import-export répartis jusqu’à `pre.010` ; `WalletPolicy` reste exclu.
 - [ ] `0.2.6` — Introduire `ksp-app-wallet-desk` utilisant Config composite + Wallet + transport HTTP, notamment pour afficher l'identité et le solde d'un wallet.
 - [ ] `0.2.7` — Étendre `ksp-onchain-transport-lib` au WebSocket Solana standard complet ; permettre plusieurs sessions sur une même URL sans imposer encore un pool automatique complexe.
 - [ ] `0.2.8` — Ajouter Helius LaserStream WebSocket comme extension du moteur WebSocket standard, sans duplication de client.

deltas/0.2.5/pre.001.md

@@ -0,0 +1,239 @@
+<!-- file: deltas/0.2.5/pre.001.md -->
+<!-- version: 2 -->
+
+# Delta `0.2.5-pre.001` — audit Wallet, threat model, format V1 et sizing
+
+## Base requise
+
+Release stable attendue :
+
+```text
+v0.2.4
+```
+
+La base fournie confirme `workspace.package.version = 0.2.4` avant ouverture.
+
+## Type de livraison
+
+```text
+ksp-general-0.2.5-pre.001.zip
+```
+
+L'archive d'échange est un **delta** applicable depuis la racine de `v0.2.4` et contient uniquement les fichiers ajoutés/modifiés par cette livraison, conformément à `VER-ARCHIVE-004`.
+
+## Objet
+
+Ouvrir `0.2.5 — Wallet foundation` sans commencer par une implémentation cryptographique. Ce delta :
+
+- réaudite les Wallet historiques bot2/bot3 ;
+- classe les idées à réutiliser/refondre/abandonner/reporter ;
+- formalise le threat model offline du `.kspwallet` ;
+- arrête l'architecture indépendante VIEW/OWNER par content keys + key slots ;
+- retient le niveau B pour le read-only VIEW via une autorité Ed25519 de format distincte de la keypair Solana et couvrant tout état mutable/de sécurité ;
+- confirme que `.kspwallet` V1 est entièrement autonome et ne requiert aucun facteur/ancrage externe ;
+- rend la keypair Solana V1 immuable après création/import ;
+- exige une spec séparée `docs/formats/KSPWALLET_V1.md` suffisante pour une implémentation indépendante dans un autre langage ;
+- choisit l'enveloppe JSON V1 stricte et un transcript binaire sémantique plutôt qu'une signature des octets JSON ;
+- réaudite les crates Solana/crypto/persistence actuelles ;
+- fixe les candidats V1 sans les ajouter prématurément ;
+- distingue rotation de password et révocation cryptographique forte de VIEW ;
+- fixe le minimum import/export à Solana CLI JSON + keypair Base58 générique ;
+- redimensionne la release de 8 à 10 prereleases avant publication.
+
+## Décisions principales
+
+### Héritage
+
+Réutiliser conceptuellement : strict 64-byte Solana keypair, signature sans getter secret, redaction/zeroize, `spawn_blocking`, CSPRNG OS, parsing borné, AEAD/AAD, no-clobber/atomic persistence, Solana CLI JSON, Base58 et inspection sûre.
+
+Refondre : password model, format, alias, unlocked representation, persistence API, logging et adapters.
+
+Abandonner : `.kswallet`, `KSWALLET`, alias/pubkey en clair, alias=filename, single password, chiffrement direct du keypair, JSON legacy/migration, `WalletPolicy`, direct `tracing`.
+
+Reporter : mnemonic UI, proprietary wallets sans wire normatif prouvé, hardware/remote/recovery.
+
+### Threat model
+
+Le fichier volé est attaquable offline sans rate-limit. Les salts sont publics. Aucun pepper KSP n'existe. `.kspwallet` V1 est explicitement auto-contenu : aucun salt externe, pepper, OTP, service distant, keychain ou ancre externe n'est requis. Les altérations partielles et toute mutation sous l'autorité OWNER originale sont authentifiées ; la substitution/rollback total d'un fichier valide reste indétectable par le seul fichier auto-contenu et cette limite est documentée sans introduire de dépendance externe en V1.
+
+### Key hierarchy
+
+```text
+VIEW password -> Argon2id VIEW -> KEK VIEW -> wrap K_metadata
+OWNER password -> Argon2id OWNER -> KEK OWNER -> wrap K_owner_root
+
+K_owner_root -> owner-control -> K_metadata + K_secret + admin signing secret
+K_metadata   -> metadata      -> Pubkey + alias + notes
+K_secret     -> secret        -> Solana keypair
+```
+
+OWNER ne dépend jamais de VIEW.
+
+### VIEW read-only
+
+Le niveau B est retenu : une clé Ed25519 d'administration du format, distincte de la keypair Solana, signe un transcript déterministe de tout l'état mutable/de sécurité. VIEW peut lire les metadata mais ne peut pas produire sous l'autorité OWNER originale une mutation acceptée de metadata, key slots/passwords, compartments ou keypair. Les modifications physiques d'octets restent possibles pour un attaquant filesystem, mais elles sont rejetées si elles ne portent pas une signature OWNER valide.
+
+Cette garantie ne couvre pas le remplacement complet du fichier **et** de sa propre clé publique de contrôle par un autre wallet auto-cohérent, ni le rollback intégral vers une ancienne copie valide. V1 n'utilise aucune ancre externe pour masquer cette limite.
+
+### Rotation / révocation
+
+`rotate_view_password` peut rewrap la même `K_metadata` et invalide l'ancien password pour le fichier courant. Une vraie révocation VIEW génère une nouvelle `K_metadata`, rechiffre metadata/control et recrée/supprime le slot VIEW.
+
+`rotate_owner_password` rewrap `K_owner_root` et ne modifie pas la keypair Solana. La keypair Solana V1 est immuable après création/import ; une autre keypair correspond à un autre wallet, pas à une mutation du wallet existant.
+
+### Format V1
+
+```text
+JSON UTF-8 strict
+magic = KSPWALLET
+format_version = 1
+Base64url sans padding pour binary wire
+key_slots génériques, V1 = OWNER obligatoire + VIEW optionnel
+owner_control / metadata / secret séparés
+owner_auth_public_key visible, identité Solana cachée
+state_signature Ed25519 couvrant tout état mutable/de sécurité
+unknown fields/version = reject
+pas de checksum séparé
+aucune dépendance externe requise pour ouvrir/vérifier V1
+```
+
+La signature porte sur un transcript binaire déterministe et domain-separated, pas sur une canonicalisation JSON.
+
+### Crypto candidate
+
+```text
+KDF        Argon2id v19
+AEAD       XChaCha20-Poly1305
+CSPRNG     getrandom / OS
+memory     zeroize
+admin auth Ed25519 standard, dépendance directe à confirmer par cargo tree
+```
+
+Les paramètres Argon2 de création ne sont **pas** figés ici. Ils seront benchmarkés avant freeze et sérialisés par slot ; le parseur aura des caps anti-DoS avant KDF.
+
+### Import/export minimum
+
+```text
+solana-cli-json
+solana-keypair-base58
+```
+
+Pas de nom/adapteur Phantom/Solflare/Backpack/Trust sans wire actuel suffisamment normatif.
+
+## Prévision révisée
+
+```text
+pre.001  audit + threat model + design + sizing
+pre.002  crate/API foundation + errors/logging/canaries
+pre.003  strict JSON wire + key slots + transcript/AAD + contrat docs/formats + spec initiale
+pre.004  KDF benchmark + AEAD/wrapping + vectors crypto in-memory
+pre.005  compartments + create/open VIEW/OWNER + state signature
+pre.006  persistence atomic/no-clobber + async + filesystem hardening
+pre.007  signing + metadata admin + rotations + VIEW strong revoke/recreate
+pre.008  extensible import/export + CLI JSON + Base58 + inspect
+pre.009  security/interoperability/compliance audit + adversarial tests + cargo trees
+pre.010  spec/README/USAGE/graphes/prompt Wallet Desk + candidate close
+rel.001  publication stricte
+```
+
+Le plan détaillé est `docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`.
+
+## Correction de l'artefact d'échange avant validation
+
+Une première archive préparatoire avait été produite à tort comme copie complète du dépôt. Elle est **invalidée explicitement et ne doit pas être appliquée** : elle ne respectait pas `VER-ARCHIVE-001`/`VER-ARCHIVE-004`. Comme cette livraison n'a pas été validée ni indiquée comme commitée par l'opérateur, le présent artefact est la livraison `pre.001` correcte, reconstruite comme delta depuis `v0.2.4`; il ne s'agit pas d'un `fix` fonctionnel appliqué après commit.
+
+La même revue a durci deux points de conception avant implémentation : autonomie absolue du format V1 et authentification OWNER de tout état mutable, avec la limite irréductible du remplacement total clairement séparée.
+
+## Fichiers ajoutés
+
+```text
+docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md
+deltas/0.2.5/pre.001.md
+```
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+ROADMAP.md
+docs/000-README.md
+docs/plans/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+```
+
+## Fichiers volontairement inchangés
+
+```text
+CHANGELOG.md
+crates/**
+config/**
+docs/validation/**
+deltas/0.2.4/**
+```
+
+Aucune crate Wallet ni dépendance crypto n'est ajoutée par le gate. Le changelog reste synchronisé en fin de session conformément à `VER-SESSION-005`.
+
+## Audit de dépendances actuel
+
+Constats externes au 2026-08-18, sans modification Cargo dans ce delta :
+
+```text
+solana-pubkey       4.3.0
+solana-keypair      3.1.2
+solana-signer       3.0.1
+argon2              0.5.3
+scrypt              0.12.0
+pbkdf2              0.13.0
+chacha20poly1305    0.11.0
+aes-gcm-siv         0.12.0
+getrandom           0.4.3
+zeroize             1.9.0
+ed25519-dalek       3.0.0
+base64              0.23.1
+tempfile            3.27.0
+```
+
+Les versions directes Solana/crypto seront réauditées au moment exact où chaque dépendance est introduite. `solana-signature 3.5.2` est la publication courante auditée ; son ajout direct reste conditionné à la surface publique réellement retenue et au cargo tree de ce moment.
+
+## Validations exécutées
+
+- inspection/réaduit de l'archive stable KSP `v0.2.4` fournie ;
+- relecture de l'index `RULES.md`, de l'ensemble des fichiers `docs/rules/*.md`, des documents architecture/plans/validation Wallet demandés et des conventions de delta/archive ;
+- confirmation des frontières Wallet déjà documentées et de `VER-ARCHIVE-004` ;
+- inspection globale de l'archive historique bot3 et lecture détaillée de `ks-wallet`, de ses tests, guides, plan/validation Wallet, format natif et héritage bot2 Wallet ;
+- inspection de l'ancien `TemporaryWalletStore` bot2 ;
+- réaudit des primitives/crates publiées actuelles nécessaires au plan ;
+- confirmation que le gate ne nécessite aucune nouvelle dépendance dans `pre.001` ;
+- vérification documentaire que le nouveau plan ne réintroduit ni Config, Transport, Store, Tauri ni WalletPolicy dans Wallet ;
+- contrôle que V1 ne requiert aucun facteur externe et que la spec multi-langages séparée est un critère de clôture ;
+- contrôle du contenu de l'archive d'échange selon `VER-ARCHIVE-004` : sept chemins seulement, tous ajoutés/modifiés par `pre.001`.
+
+## Validations non exécutées
+
+Le sandbox courant ne fournit pas le binaire `cargo`; les validations Cargo doivent être rejouées par l'opérateur avant commit :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+```
+
+`cargo test -p ksp-wallet-lib` n'est pas applicable à `pre.001` puisque la crate n'existe volontairement pas encore.
+
+Aucun `cargo tree` ne peut être pertinent à ce stade puisque les dépendances ne changent pas. Il devient obligatoire dès leur introduction et à la compliance finale.
+
+L'archive stable fournie ne contient pas `.git`; le commit attendu après application et validations suit :
+
+```text
+v0.2.5-pre.001
+```
+
+## Questions bloquantes
+
+Aucune pour `pre.002`.
+
+Les paramètres Argon2 de production sont volontairement **non décidés** avant benchmark ; ce n'est pas une question d'architecture bloquante.
+
+## Suite
+
+`0.2.5-pre.002` : créer `crates/ksp-wallet-lib` avec foundation API/capabilities, erreurs, logging KSP et canaries de frontières, sans encore implémenter le chiffrement `.kspwallet`.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 33 -->
+<!-- version: 34 -->
 
 # Documentation KSP
 
@@ -43,7 +43,8 @@ docs/
 │   ├── 008-V0_2_1_ONCHAIN_HTTP_PLAN.md
 │   ├── 009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md
 │   ├── 010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md
-│   └── 011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md
+│   ├── 011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md
+│   └── 012-V0_2_5_WALLET_FOUNDATION_PLAN.md
 ├── validation/
 │   ├── 000-README.md
 │   ├── 001-V0_1_4_CONFIG_DESKTOP.md
@@ -69,7 +70,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
 
 ## Documents de planification
 
-Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) a ouvert la release stable `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan clôturé [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) conserve l’implémentation des 15 wrappers et la compliance `52/52 + 14/14`; la matrice finale [`validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) enregistre le réaudit SIMD/inventaire, les canaries globales et les preuves opérateur avant publication. Le prompt [`../prompts/010-V0_2_5_START_PROMPT.md`](../prompts/010-V0_2_5_START_PROMPT.md), finalisé par `0.2.4-pre.009-fix.001`, ouvre `0.2.5 — Wallet foundation` sur la base stable `v0.2.4`.
+Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La release stable `0.2.1 — HTTP Solana foundation` a été ouverte par [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md). Son gate de sizing et sa matrice exhaustive sont conservés dans [`plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`](plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md), avec la validation finale [`validation/003-V0_2_1_ONCHAIN_HTTP.md`](validation/003-V0_2_1_ONCHAIN_HTTP.md), README/USAGE Transport et le smoke Devnet opt-in de composition Config -> Transport. Le prompt [`../prompts/007-V0_2_2_START_PROMPT.md`](../prompts/007-V0_2_2_START_PROMPT.md) a ouvert la release stable `0.2.2 — HTTP Accounts + Tokens + Cluster`. Son plan clôturé [`plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](plans/009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) conserve l'audit et l'implémentation des 22 wrappers typés, tandis que [`validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](validation/004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) enregistre les validations déterministes, les graphes Cargo et les deux smokes Devnet passés avant publication. Le prompt [`../prompts/008-V0_2_3_START_PROMPT.md`](../prompts/008-V0_2_3_START_PROMPT.md) a ouvert la release stable `0.2.3 — HTTP Transactions`. Son plan clôturé [`plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](plans/010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) conserve l'audit et l'implémentation des 11 wrappers ; le réaudit [`validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](validation/005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) confirme la complétude des 37 wrappers HTTP typés et [`validation/006-V0_2_3_HTTP_TRANSACTIONS.md`](validation/006-V0_2_3_HTTP_TRANSACTIONS.md) enregistre les validations finales, graphes Cargo et deux smokes Devnet passés avant publication. Le prompt [`../prompts/009-V0_2_4_START_PROMPT.md`](../prompts/009-V0_2_4_START_PROMPT.md) a ouvert la release stable `0.2.4 — HTTP Blocks + Economics + compliance HTTP finale`. Son plan clôturé [`plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](plans/011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) conserve l’implémentation des 15 wrappers et la compliance `52/52 + 14/14`; la matrice finale [`validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](validation/007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) enregistre le réaudit SIMD/inventaire, les canaries globales et les preuves opérateur avant publication. Le prompt [`../prompts/010-V0_2_5_START_PROMPT.md`](../prompts/010-V0_2_5_START_PROMPT.md), finalisé par `0.2.4-pre.009-fix.001`, ouvre `0.2.5 — Wallet foundation` sur la base stable `v0.2.4`. Son gate `0.2.5-pre.001` est conservé dans [`plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md) : il réaudite bot2/bot3 et les crates actuelles, formalise le threat model offline, retient les capacités VIEW/OWNER indépendantes et le niveau B read-only, cadre le format interopérable `.kspwallet` V1 et redimensionne la release avant implémentation cryptographique.
 
 `IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.
 

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 40 -->
+<!-- version: 41 -->
 
 # Plans KSP
 
@@ -20,6 +20,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 - [`009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md`](009-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER_PLAN.md) — plan clôturé de la release stable `0.2.2`, établi par `pre.001`, corrigé après réaudit Agave v4.2.1 puis exécuté jusqu'à `pre.007-fix.002`; il couvre les 22 wrappers Accounts/Tokens/Cluster, le smoke Transport opt-in et la préparation de `0.2.3`.
 - [`010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md`](010-V0_2_3_HTTP_TRANSACTIONS_PLAN.md) — plan historique clôturé de la release stable `0.2.3 — HTTP Transactions`, ouvert par `pre.001`, exécuté jusqu'à `pre.009` puis publié par `rel.001`; il couvre les 11 méthodes, la classification `8 Read / 2 WriteSubmission / 1 Simulation`, `KSP-TRANSPORT-007`, le no-resend et la préparation de `0.2.4`.
 - [`011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md`](011-V0_2_4_HTTP_BLOCKS_ECONOMICS_PLAN.md) — plan historique clôturé de la release stable `0.2.4`, ouvert par `pre.001`, exécuté jusqu’à `pre.009`, complété par le fix documentaire Wallet `pre.009-fix.001` puis publié par `rel.001`; il couvre les 10 Blocks + 5 Economics et la compliance finale `52/52 + 14/14` sous `KSP-TRANSPORT-007`.
+- [`012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](012-V0_2_5_WALLET_FOUNDATION_PLAN.md) — plan actif de `0.2.5 — Wallet foundation`, ouvert par `pre.001`; il fixe le threat model offline, le design VIEW/OWNER par key slots, le niveau B read-only, le format `.kspwallet` V1, les primitives candidates et le sizing révisé jusqu’à `pre.010`.
 
 Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
 

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 42 -->
+<!-- version: 44 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -398,11 +398,15 @@ Chaque `pre.001` réaudite la documentation officielle actuelle. Les méthodes D
 
 ## `0.2.5` — Wallet foundation
 
-Mission : créer `ksp-wallet-lib` et le format `.kspwallet`.
+Mission : créer `ksp-wallet-lib` et le format natif interopérable `.kspwallet`, indépendants de Config/Transport/Tauri/ExecutionPolicy.
 
-Inclure un format `.kspwallet` documenté et interopérable, un threat model d’attaque offline, des capacités indépendantes `VIEW`/`OWNER`, Pubkey/alias/notes protégés lorsque verrouillé, key slots/rotations sans changement de keypair, signature sans exposition publique du secret brut et import/export extensible.
+`0.2.5-pre.001` ouvre la release par un gate documentaire : l'ancien JSON temporaire et `.kswallet` ne sont pas migrés, mais leurs invariants utiles (keypair strict, signature sans getter secret, zeroization, `spawn_blocking`, no-clobber/atomic persistence, adapters CLI JSON/Base58) servent de canaris conceptuels. Le nouveau format cache Pubkey/alias/notes lorsqu'il est verrouillé et sépare VIEW/OWNER par content keys et key slots indépendants.
 
-`pre.001` doit auditer les choix KDF/AEAD/key wrapping/secret memory actuels avant de figer V1. Exclure : temporary wallet JSON historique et `WalletPolicy`.
+Le design retient un read-only VIEW de niveau B : une clé Ed25519 d'administration du format, distincte de la keypair Solana, authentifie un transcript déterministe de tout l'état mutable/de sécurité. Sans OWNER, un détenteur VIEW ne peut donc pas fabriquer sous l'autorité OWNER originale une modification de metadata, key slot/password, compartment secret ou keypair qui soit acceptée. La cryptographie détecte/rejette les mutations ; elle ne prétend pas empêcher un attaquant filesystem d'écrire physiquement des octets ni distinguer une substitution intégrale par un autre wallet auto-cohérent.
+
+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. OWNER reste indépendant de VIEW, peut rekey les metadata pour une révocation VIEW forte sans changer la keypair Solana, et la keypair V1 reste immuable après création/import.
+
+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`.
 
 ## `0.2.6` — Wallet Desk