Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.2.6-pre.018

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-22 10:56:26 +02:00
parent 362123f357
commit ba8f42f9b1
36 changed files with 1238 additions and 150 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/000-README.md
View File

File diff suppressed because one or more lines are too long

4
docs/IDEAS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/IDEAS.md -->
<!-- version: 22 -->
<!-- version: 23 -->
# Idées à explorer
@@ -206,7 +206,7 @@ Chaque format doit être étudié côté sécurité, round-trip, secret/public,
**Status :** V2 retenu et matérialisé en `0.2.6-pre.015` / facteurs futurs à explorer
Le JSON V1 actuel reste le format historique stable et lisible. Base64 seul n’apporte aucune sécurité et resterait un texte trivialement décodable avec environ un tiers de surcharge. La décision initialement envisagée pour `0.2.7` a été ramenée dans `0.2.6` : `pre.015` définit un **wire binaire V2 KSP** avec magic/framing explicite, entiers big-endian, identifiants numériques stables, longueurs bornées et lecture/écriture canonique stricte. V1 reste supporté sans réinterprétation ; la façade de lecture multi-version, la création/persistence V2, les APIs `_v1/_v2` et la politique `DEFAULT_WALLET_FORMAT = V2` sont matérialisées en `pre.016`, puis la migration explicite V1 -> V2 reste planifiée en `pre.017`. Le V2 ne modifie pas à lui seul les garanties cryptographiques de VIEW/OWNER, keypair ou import/export.
Le JSON V1 actuel reste le format historique stable et lisible. Base64 seul n’apporte aucune sécurité et resterait un texte trivialement décodable avec environ un tiers de surcharge. La décision initialement envisagée pour `0.2.7` a été ramenée dans `0.2.6` : `pre.015` définit un **wire binaire V2 KSP** avec magic/framing explicite, entiers big-endian, identifiants numériques stables, longueurs bornées et lecture/écriture canonique stricte. V1 reste supporté sans réinterprétation ; la façade de lecture multi-version, la création/persistence V2, les APIs `_v1/_v2` et la politique `DEFAULT_WALLET_FORMAT = V2` sont matérialisées en `pre.016`, puis la migration explicite OWNER-authentifiée V1 -> V2 est matérialisée en `pre.017`. Le V2 ne modifie pas à lui seul les garanties cryptographiques de VIEW/OWNER, keypair ou import/export.
V2 est désormais réservé au wire binaire KSP sans second facteur. Un futur V3 pourra introduire d’autres modèles d’autorisation, notamment password + facteur supplémentaire. `ksp-wallet-lib` restera propriétaire du format, des challenges et de la vérification, mais toute interaction réelle (OTP, enrollment/recovery, hardware/WebAuthn, validation distante) exigera une évolution de Wallet Desk ou du client concerné. Un seed TOTP stocké uniquement dans le même fichier que le wallet ne doit pas être présenté automatiquement comme un second facteur indépendant contre un attaquant possédant ce fichier.

4
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Applications, services, scenarios et control plane
@@ -125,6 +125,8 @@ TS-RS reste principalement une frontière applicative pour les DTO exposés à T
Une application Tauri peut devoir intégrer un plugin/framework de tracing, mais `ksp-logging-lib` reste la façade/politique de logging KSP.
En distribution, une application Tauri KSP ne dépend pas du checkout source ni du CWD du launcher. Les resources Config/Schemas nécessaires sont embarquées dans le bundle ; Tauri résout leur racine immutable et `ksp-config-lib` prépare une racine KSP user-writable commune avant le bootstrap applicatif. Les Config utilisateur existantes sont conservées, les schemas package-owned sont resynchronisés et `.env` reste une ressource locale writable jamais embarquée. Cette adaptation de packaging ne transfère ni ownership Config ni accès filesystem au frontend.
# Workers comme services indépendants
Les workers KSP doivent pouvoir fonctionner comme **services/processus indépendants**.

4
docs/formats/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/formats/000-README.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Formats KSP
@@ -10,4 +10,4 @@ Une spécification de format décrit le wire exact, les encodages, les limites,
## Formats actifs
- [`KSPWALLET_V1.md`](KSPWALLET_V1.md) — spécification du format natif autonome `.kspwallet` V1. `0.2.5-pre.003` fige l'enveloppe/wire et les transcripts/AAD, `pre.004` ajoute Argon2id/XChaCha20-Poly1305/CSPRNG OS, `pre.005` fixe les payloads plaintext, le profil de création KSP calibré, l'autorité Ed25519 OWNER et le vecteur complet, `pre.006`–`pre.008` matérialisent persistence/administration/transfert, `pre.009` ferme l'audit adversarial/interoperabilité/compliance et `pre.010` synchronise la documentation finale sans modifier le wire V1.
- [`KSPWALLET_V2.md`](KSPWALLET_V2.md) — wire binaire natif V2 introduit par `0.2.6-pre.015` puis runtime multi-version matérialisé en `pre.016` : framing canonique KSP, IDs numériques, longueurs big-endian, aucun Base64/compression, domains/transcripts V2 distincts et politique `default != latest`.
- [`KSPWALLET_V2.md`](KSPWALLET_V2.md) — wire binaire natif V2 introduit par `0.2.6-pre.015`, runtime multi-version/default V2 matérialisé en `pre.016`, puis migration explicite OWNER-authentifiée V1 -> V2 en `pre.017` : framing canonique KSP, IDs numériques, longueurs big-endian, aucun Base64/compression, domains/transcripts V2 distincts et politique `default != latest`.

92
docs/formats/KSPWALLET_V2.md
View File

@@ -104,14 +104,14 @@ Une implémentation conforme doit vérifier les bornes **avant** toute allocatio
Le début de fichier est strictement :
| Ordre | Champ | Taille | Valeur / règle |
|---:|---|---:|---|
| 1 | `magic` | 9 | ASCII exact `KSPWALLET` |
| 2 | `format_version` | 2 | `0x0002` |
| 3 | `document_length` | 4 | longueur totale exacte du fichier |
| 4 | `flags` | 2 | bit 0 = VIEW activé ; tous les autres bits = 0 |
| 5 | `owner_auth_public_key` | 32 | clé publique Ed25519 OWNER |
| 6 | `view_descriptor.slot_id` | 16 conditionnels | présent uniquement si `flags & 0x0001 != 0` |
| Ordre | Champ | Taille | Valeur / règle |
|------:|---------------------------|-----------------:|------------------------------------------------|
| 1 | `magic` | 9 | ASCII exact `KSPWALLET` |
| 2 | `format_version` | 2 | `0x0002` |
| 3 | `document_length` | 4 | longueur totale exacte du fichier |
| 4 | `flags` | 2 | bit 0 = VIEW activé ; tous les autres bits = 0 |
| 5 | `owner_auth_public_key` | 32 | clé publique Ed25519 OWNER |
| 6 | `view_descriptor.slot_id` | 16 conditionnels | présent uniquement si `flags & 0x0001 != 0` |
Offsets fixes avant le descripteur conditionnel :
@@ -154,21 +154,21 @@ Aucun compteur de slots ou de compartiments n'est nécessaire : leur cardinalit
Chaque key slot est encodé ainsi :
| Champ | Taille | Valeur / règle |
|---|---:|---|
| `role` | 1 | `0x01` OWNER, `0x02` VIEW |
| `slot_id` | 16 | identifiant binaire exact |
| `kdf_algorithm` | 1 | `0x01` Argon2id |
| `kdf_version` | 4 | `19` |
| `memory_kib` | 4 | `1..1 048 576`, et `>= parallelism * 8` |
| `iterations` | 4 | `1..64` |
| `parallelism` | 4 | `1..64` |
| `salt_length` | 1 | `16..64` |
| `salt` | variable | exactement `salt_length` octets |
| `wrap_algorithm` | 1 | `0x01` XChaCha20-Poly1305 |
| `wrap_nonce` | 24 | nonce exact |
| `wrap_ciphertext_length` | 2 | `16..4096` |
| `wrap_ciphertext` | variable | exactement la longueur déclarée |
| Champ | Taille | Valeur / règle |
|--------------------------|---------:|-----------------------------------------|
| `role` | 1 | `0x01` OWNER, `0x02` VIEW |
| `slot_id` | 16 | identifiant binaire exact |
| `kdf_algorithm` | 1 | `0x01` Argon2id |
| `kdf_version` | 4 | `19` |
| `memory_kib` | 4 | `1..1 048 576`, et `>= parallelism * 8` |
| `iterations` | 4 | `1..64` |
| `parallelism` | 4 | `1..64` |
| `salt_length` | 1 | `16..64` |
| `salt` | variable | exactement `salt_length` octets |
| `wrap_algorithm` | 1 | `0x01` XChaCha20-Poly1305 |
| `wrap_nonce` | 24 | nonce exact |
| `wrap_ciphertext_length` | 2 | `16..4096` |
| `wrap_ciphertext` | variable | exactement la longueur déclarée |
Ordre obligatoire :
@@ -189,14 +189,14 @@ Toute divergence est invalide avant KDF/déchiffrement.
Chaque compartiment est encodé :
| Champ | Taille | Valeur / règle |
|---|---:|---|
| `kind` | 1 | `0x01` OWNER-CONTROL, `0x02` METADATA, `0x03` SECRET |
| `payload_version` | 4 | `1` pour le profil initial V2 |
| `algorithm` | 1 | `0x01` XChaCha20-Poly1305 |
| `nonce` | 24 | nonce exact |
| `ciphertext_length` | 4 | longueur exacte |
| `ciphertext` | variable | ciphertext + tag Poly1305 |
| Champ | Taille | Valeur / règle |
|---------------------|---------:|------------------------------------------------------|
| `kind` | 1 | `0x01` OWNER-CONTROL, `0x02` METADATA, `0x03` SECRET |
| `payload_version` | 4 | `1` pour le profil initial V2 |
| `algorithm` | 1 | `0x01` XChaCha20-Poly1305 |
| `nonce` | 24 | nonce exact |
| `ciphertext_length` | 4 | longueur exacte |
| `ciphertext` | variable | ciphertext + tag Poly1305 |
Bornes initiales :
@@ -214,10 +214,10 @@ Les payloads plaintext V2 conservent le modèle fonctionnel établi en V1 pour c
La fin du document est :
| Champ | Taille | Valeur / règle |
|---|---:|---|
| `state_signature.algorithm` | 1 | `0x01` Ed25519 |
| `state_signature.signature` | 64 | signature detached exacte |
| Champ | Taille | Valeur / règle |
|-----------------------------|-------:|---------------------------|
| `state_signature.algorithm` | 1 | `0x01` Ed25519 |
| `state_signature.signature` | 64 | signature detached exacte |
Aucun octet ne peut suivre ces 65 octets.
@@ -377,17 +377,17 @@ Le nonce/ciphertext n'est pas inclus dans son propre AAD.
V1 et V2 sont deux formats explicites :
| Propriété | V1 | V2 |
|---|---|---|
| enveloppe | JSON UTF-8 | binaire KSP |
| champs binaires | Base64url no-pad | bytes directs |
| version | `1` | `2` |
| canonicalité | sémantique JSON + Base64 canonique | byte-exact |
| taille fixture wire-only | 2037 octets | 628 octets |
| Argon2id | oui | oui |
| XChaCha20-Poly1305 | oui | oui |
| Ed25519 OWNER state | oui | oui |
| VIEW/OWNER | oui | oui |
| Propriété | V1 | V2 |
|--------------------------|------------------------------------|---------------|
| enveloppe | JSON UTF-8 | binaire KSP |
| champs binaires | Base64url no-pad | bytes directs |
| version | `1` | `2` |
| canonicalité | sémantique JSON + Base64 canonique | byte-exact |
| taille fixture wire-only | 2037 octets | 628 octets |
| Argon2id | oui | oui |
| XChaCha20-Poly1305 | oui | oui |
| Ed25519 OWNER state | oui | oui |
| VIEW/OWNER | oui | oui |
La réduction mesurée sur le fixture structurel de référence est :

4
docs/plans/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/000-README.md -->
<!-- version: 51 -->
<!-- version: 52 -->
# Plans KSP
@@ -21,7 +21,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
- [`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 historique clôturé de la release stable `0.2.5 — Wallet foundation`, ouvert par `pre.001`, livré jusqu’à `pre.010`, renforcé par `pre.010-fix.001`–`fix.003` pour Dalek 3 et la normalisation Rust/audit structurel, puis publié par `rel.001`; il couvre `.kspwallet` V1, VIEW/OWNER, crypto, persistence, administration, transfer et compliance.
- [`013-V0_2_6_WALLET_DESK_PLAN.md`](013-V0_2_6_WALLET_DESK_PLAN.md) — plan actif de `0.2.6 — Wallet Desk`, ouvert par `pre.001`; `pre.002` matérialise le shell Tauri et `pre.003` la composition `std.wallet`/composite ainsi que la préparation des répertoires. Le plan fixe aussi secrets `KSP_SECRET_WALLET_PASS_*`, inventory DataTables/path safety, lifecycle VIEW/OWNER, screen/command/DTO maps, balance HTTP, administration retenue et forecast étendu jusqu’à `pre.018` : `pre.014` polish Bootstrap/splashscreen, `pre.015` wire binaire `.kspwallet` V2 et `pre.016` APIs génériques/versionnées + runtime V2 et `pre.017` migration explicite V1 -> V2 désormais matérialisés ; prochain gate `pre.018` documentation candidate et build Tauri final.
- [`013-V0_2_6_WALLET_DESK_PLAN.md`](013-V0_2_6_WALLET_DESK_PLAN.md) — plan actif de `0.2.6 — Wallet Desk`, ouvert par `pre.001`; shell Tauri, composition Config/Wallet/Transport, inventory, lifecycle VIEW/OWNER, administration, import/export et compliance sont acquis. `pre.015`–`pre.017` ajoutent le wire binaire `.kspwallet` V2, les APIs génériques/versionnées, le runtime V2 et la migration explicite V1 -> V2. `pre.018` matérialise désormais la candidate documentaire et le runtime Tauri packagé commun user-writable ; validation opérateur/build final puis `rel.001` restent à fermer.
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.

4
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 76 -->
<!-- version: 77 -->
# Séquence des releases fonctionnelles KSP
@@ -449,7 +449,7 @@ pre.018 documentation finale, validations, prompt 0.2.7 et cargo tauri build en
rel.001 publication stable 0.2.6
```
`pre.017` est désormais matérialisé : la migration V1 -> V2 est explicite, OWNER-authentifiée et séparée de toute ouverture normale, avec copie no-clobber et remplacement in-place stale-protected. Le prochain gate est `pre.018`.
`pre.017` est désormais matérialisé et validé : la migration V1 -> V2 est explicite, OWNER-authentifiée et séparée de toute ouverture normale, avec copie no-clobber et remplacement in-place stale-protected. `pre.018` matérialise la candidate finale : README/USAGE Wallet Desk, documentation/compliance, runtime packagé commun à Config Desk/Wallet Desk avec Config resources + racine user-writable, et prompt `0.2.7`. Le build Wallet Desk et `rel.001` restent les gates finaux.
La tranche `pre.014` est réservée aux défauts visuels/templating observés en usage réel, notamment les scrollbars occasionnelles du splashscreen ; son contenu précis sera borné à partir du retour opérateur avant implémentation. `ROADMAP.md` reste synthétique et `CHANGELOG.md` n'est synchronisé qu'à la phase documentaire finale.

100
docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md -->
<!-- version: 34 -->
<!-- version: 35 -->
# Plan `0.2.6` — Wallet Desk
@@ -770,32 +770,32 @@ outil de logging contrôlé
## 12. Command map
| Command | Entrée frontend | Sortie sûre | Délégation |
|----------------------------------------------|--------------------|-------------------------------------|---------------------------------|
| `get_runtime_status` | — | `WalletRuntimeStatusDto` | Config/app state |
| `list_wallets` | — | `Vec<WalletInventoryEntryDto>` | app filesystem + Wallet inspect |
| `refresh_wallets` | — | inventory DTO | app filesystem + Wallet inspect |
| `select_wallet` | wallet id | `LockedWalletDto` | app resolver + Wallet inspect |
| `deselect_wallet` | — | session DTO | app state |
| `create_wallet` | create request | `WalletAuthorizedDto` OWNER | Wallet create file |
| `unlock_wallet_view` | password | authorized VIEW | Wallet open VIEW |
| `unlock_wallet_owner` | password | authorized OWNER | Wallet open OWNER |
| `unlock_wallet_view_with_configured_secret` | — | authorized VIEW / operation result | Config env + Wallet open VIEW |
| `unlock_wallet_owner_with_configured_secret` | — | authorized OWNER / operation result | Config env + Wallet open OWNER |
| `lock_wallet` | — | `LockedWalletDto` | drop handle + inspect |
| `refresh_wallet_balance` | — | `WalletBalanceDto` | Transport getBalance |
| `inspect_import_source` | format only | transfer inspection DTO / cancel | Rust native picker + Wallet inspect |
| `import_wallet` | import request | authorized OWNER | staged bytes + Wallet import |
| `update_wallet_alias` | alias mutation | authorized DTO | WalletOwner |
| `add_wallet_note` | note create | authorized DTO | WalletOwner |
| `update_wallet_note` | note update | authorized DTO | WalletOwner |
| `delete_wallet_note` | note id | authorized DTO | WalletOwner |
| `rotate_owner_password` | rotation request | operation result | WalletOwner |
| `rotate_view_password` | rotation request | operation result | WalletOwner |
| `disable_view` | confirmation | authorized DTO | WalletOwner |
| `recreate_view` | new VIEW password | authorized DTO | WalletOwner |
| `export_wallet_owner` | format + save path | operation result | Wallet export file |
| `emit_frontend_log` | redacted payload | `()` | Logging facade |
| Command | Entrée frontend | Sortie sûre | Délégation |
|----------------------------------------------|--------------------|-------------------------------------|-------------------------------------|
| `get_runtime_status` | — | `WalletRuntimeStatusDto` | Config/app state |
| `list_wallets` | — | `Vec<WalletInventoryEntryDto>` | app filesystem + Wallet inspect |
| `refresh_wallets` | — | inventory DTO | app filesystem + Wallet inspect |
| `select_wallet` | wallet id | `LockedWalletDto` | app resolver + Wallet inspect |
| `deselect_wallet` | — | session DTO | app state |
| `create_wallet` | create request | `WalletAuthorizedDto` OWNER | Wallet create file |
| `unlock_wallet_view` | password | authorized VIEW | Wallet open VIEW |
| `unlock_wallet_owner` | password | authorized OWNER | Wallet open OWNER |
| `unlock_wallet_view_with_configured_secret` | — | authorized VIEW / operation result | Config env + Wallet open VIEW |
| `unlock_wallet_owner_with_configured_secret` | — | authorized OWNER / operation result | Config env + Wallet open OWNER |
| `lock_wallet` | — | `LockedWalletDto` | drop handle + inspect |
| `refresh_wallet_balance` | — | `WalletBalanceDto` | Transport getBalance |
| `inspect_import_source` | format only | transfer inspection DTO / cancel | Rust native picker + Wallet inspect |
| `import_wallet` | import request | authorized OWNER | staged bytes + Wallet import |
| `update_wallet_alias` | alias mutation | authorized DTO | WalletOwner |
| `add_wallet_note` | note create | authorized DTO | WalletOwner |
| `update_wallet_note` | note update | authorized DTO | WalletOwner |
| `delete_wallet_note` | note id | authorized DTO | WalletOwner |
| `rotate_owner_password` | rotation request | operation result | WalletOwner |
| `rotate_view_password` | rotation request | operation result | WalletOwner |
| `disable_view` | confirmation | authorized DTO | WalletOwner |
| `recreate_view` | new VIEW password | authorized DTO | WalletOwner |
| `export_wallet_owner` | format + save path | operation result | Wallet export file |
| `emit_frontend_log` | redacted payload | `()` | Logging facade |
Aucune commande de signature arbitraire n'est ajoutée dans cette release.
@@ -1741,7 +1741,7 @@ Une future API `_v3` pourra être ajoutée sans transformer automatiquement le d
### `pre.017` — migration V1 -> V2 + persistence/canaris
**Statut : matérialisé par `0.2.6-pre.017`.**
**Statut : matérialisé par `0.2.6-pre.017` et checkpoint opérateur entièrement vert.**
La migration est une opération explicite OWNER-authentifiée et reste séparée de toute ouverture normale :
@@ -1765,23 +1765,41 @@ Invariants retenus :
Les canaris `pre.017` couvrent migration mémoire, conservation identité/metadata/note IDs, choix du credential VIEW cible, no-clobber, remplacement in-place, tampering, stale-state et exposition API publique. Wallet Desk reste version-neutral et non-migrant : aucune ouverture/inventory du Desk ne déclenche la migration.
### `pre.018` — documentation finale, candidate build et prompt suivant
### `pre.018` — documentation finale, runtime packagé et candidate build
Dernière tranche prévue avant `rel.001` :
**Statut : candidate matérialisée ; validations opérateur et build final encore à exécuter.**
Cette tranche ferme la stratégie CWD/resources release qui restait ouverte depuis le polish desktop :
```text
README/USAGE Wallet Desk
docs/validation 0.2.6 finalisée
ROADMAP / functional sequence / CHANGELOG synchronisés
stratégie CWD/resources release packagée fermée
dépendances et versions finales réauditées
validation Rust workspace finale
parcours fonctionnel cargo tauri dev final
prompt de démarrage 0.2.7 WebSocket finalisé
cargo tauri build en toute dernière opération
bundle.resources : 4 documents Config + 4 schemas du registre courant
Config packagée : seed uniquement si absente
Schemas : synchronisés depuis le package courant à chaque lancement
.env : jamais embarqué ni seedé
racine runtime writable : ProjectDirs commun KSP
release Tauri : resource_dir -> prepare_packaged_runtime -> set_current_dir -> AppState::initialize
debug Tauri : comportement workspace-root existant conservé
```
Si une correction technique apparaît, utiliser `pre.018-fix.NNN` ou insérer une tranche supplémentaire.
Les deux Desks utilisent le même runtime KSP writable et ne dépendent donc plus du checkout source en distribution. Aucun accès filesystem supplémentaire n'est accordé au guest frontend. `ksp-config-lib` reste propriétaire de la préparation des Config/schemas et de la localisation user-writable.
Livrables candidate :
```text
README/USAGE Wallet Desk créés
README/USAGE Config Desk synchronisés sur le runtime packagé
docs/validation 0.2.6 finalisée jusqu'au gate opérateur
règles KSP packaging/CWD durables
ROADMAP / functional sequence / indexes mis à jour globalement
CHANGELOG audité mais volontairement inchangé jusqu'à rel.001
versions Cargo/package/Tauri alignées sur pre.018
prompt de démarrage 0.2.7 WebSocket finalisé
canaris resources/packaging ajoutés
```
Le checkpoint `pre.017` de référence est vert : fmt/audit/check/clippy/workspace tests passent, `ksp-wallet-lib` compte 84 tests passés + 1 benchmark ignoré, et le parcours Tauri confirme un import créant réellement un V2 puis un `getBalance` Devnet réussi.
Après application de `pre.018`, toutes les validations Rust, le parcours `cargo tauri dev`, les éventuels smokes live et audits de dépendances sont exécutés avant le build. `(cd crates/ksp-app-wallet-desk && cargo tauri build)` demeure **l'absolue dernière opération de validation**. Si une correction technique apparaît, utiliser `pre.018-fix.NNN` avant de rejouer le gate depuis le début.
### `rel.001` — publication stable
@@ -1955,6 +1973,6 @@ splash : feed #debug-info pleine largeur dans les deux Desks
pre.013 gate : le canari ne fige plus une shell_phase destinée à évoluer à chaque tranche
```
Le recalage du CWD n'existe actuellement qu'en `debug_assertions` dans les deux `main.rs`. La candidate finale `pre.018` doit donc vérifier explicitement la stratégie de résolution production/bundle pour `config`, `.env`, `logs` et `wallets` avant le build final ; le comportement release ne doit pas être supposé identique au parcours `cargo tauri dev`.
Le recalage du CWD n'existait alors qu'en `debug_assertions` dans les deux `main.rs`. Ce point historique est fermé par `pre.018` : le runtime release résout les resources Tauri puis une racine KSP user-writable via Config avant le bootstrap ; il ne suppose plus le comportement du parcours `cargo tauri dev`.
Ce fix touche le frontend/build contract et porte donc le signal technique `workspace.package.version = 0.2.6-pre.14.fix.1`. `ROADMAP.md`, `CHANGELOG.md` et `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` restent inchangés.

4
docs/rules/RULES_KSP.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/RULES_KSP.md -->
<!-- version: 37 -->
<!-- version: 38 -->
# Règles spécifiques à KSP
@@ -45,6 +45,7 @@
- **KSP-CONFIG-015** — L'environnement du processus reste read-only. La surface management peut créer/modifier/supprimer uniquement des entrées KSP/KSPB du `.env`; chaque mutation rapporte séparément changement de source persistée, changement effectif courant, shadowing par le process et besoin de reload.
- **KSP-CONFIG-016** — Les rapports management ordinaires n'exposent que des valeurs sûres/redacted. L'accès en clair à une valeur d'environnement passe par un appel `reveal_*` explicite; l'authentification/autorisation de l'utilisateur final appartient à l'application et cette révélation n'autorise jamais le secret dans les logs/`Debug`/diagnostics génériques.
- **KSP-CONFIG-017** — Les frontières d'ownership Config sont vérifiées par des audits exécutables du workspace : Core/Logging ne dépendent pas de Config, les crates hors `ksp-config-lib` ne lisent pas directement les variables KSP/KSPB via `std::env::var*`/énumération de l'environnement et ne codent pas en dur les noms physiques des fichiers gérés lorsqu'un contrat Config existe.
- **KSP-CONFIG-018** — Dans un runtime desktop packagé, `ksp-config-lib` possède la préparation de la racine KSP writable à partir des resources applicatives : les documents Config packagés ne sont seedés que lorsqu'ils sont absents, les JSON Schemas possédés par le package courant sont resynchronisés à chaque lancement, et `.env` n'est jamais embarqué ni seedé. La localisation physique writable est résolue par une primitive plateforme dédiée et n'est pas codée en dur dans les applications.
- **KSP-CONFIG-018** — L'inventaire `.env.example` est vérifié automatiquement contre les variables KSP/KSPB concrètes utilisées par les JSON sous `config/` et le code Rust production. Toute clé runtime détectée doit posséder une entrée d'inventaire précédée d'un commentaire explicatif.
## Programmes et exécution
@@ -231,6 +232,7 @@
- **KSP-APP-032** — Les interfaces desk KSP n’utilisent pas les dialogues bloquants natifs du navigateur (`window.alert`, `window.confirm`, `window.prompt`) pour les interactions applicatives normales. Les confirmations destructives ou privilégiées utilisent un modal Bootstrap intégré à l’UI, instrumenté par le bridge Logging ; toute exception doit être explicitement justifiée et documentée.
- **KSP-APP-033** — Un test d’une application ou d’un manager qui peut modifier un document Config du workspace ne traite jamais les valeurs courantes de ce document comme une fixture immuable. Les tests de valeurs exactes utilisent une fixture isolée ; les tests qui lisent la Config workspace vérifient uniquement des invariants, la validité et la cohérence source → résolution → runtime afin de rester valides après une édition légitime par Config Desk.
- **KSP-APP-034** — Pour une application Tauri KSP, npm n’est jamais invoqué directement pour lancer les scripts applicatifs de développement, contrôle ou build. Les seules commandes npm directes servent à installer ou mettre à jour les dépendances déclarées. Le cycle applicatif est crate-local : `(cd crates/<app> && cargo tauri dev)` et `(cd crates/<app> && cargo tauri build)` ; Tauri déclenche lui-même les hooks `beforeDevCommand` / `beforeBuildCommand`, dont le `cwd` reste explicitement la crate. Dans une validation finale, le `cargo tauri build` crate-local est exécuté **en toute dernière opération**, après fmt/audit/check/clippy, tests et parcours fonctionnel.
- **KSP-APP-035** — Une application Tauri KSP distribuée ne dépend ni d'un checkout source ni du répertoire courant choisi par l'utilisateur. Les Config/Schemas nécessaires sont embarqués via `bundle.resources`; avant le bootstrap applicatif release, Tauri résout son resource directory, délègue à `ksp-config-lib` la préparation du runtime writable commun puis active cette racine comme current working directory. Le guest frontend n'obtient aucune permission filesystem supplémentaire pour ce bootstrap.
## Data plane / control plane

6
docs/validation/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/000-README.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Validations KSP
@@ -14,9 +14,7 @@ Documents :
- [`003-V0_2_1_ONCHAIN_HTTP.md`](003-V0_2_1_ONCHAIN_HTTP.md) — matrice de clôture de `0.2.1 — HTTP Solana foundation`, registry 52+14, résilience, Config -> Transport, quatre canaris et smoke Devnet opt-in.
- [`004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md`](004-V0_2_2_HTTP_ACCOUNTS_TOKENS_CLUSTER.md) — matrice finale validée de `0.2.2`, 22 wrappers Accounts/Tokens/Cluster, canaries 52+14, graphes Cargo, smoke Devnet Transport pur, smoke historique Config -> Transport et préparation de `0.2.3`.
- [`005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md`](005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md) — réaudit rétroactif de complétude `KSP-TRANSPORT-007` des 37 wrappers HTTP typés livrés de `0.2.1` à `0.2.3-pre.007`, avec preuves Solana/Agave et verdict méthode par méthode.
- [`006-V0_2_3_HTTP_TRANSACTIONS.md`](006-V0_2_3_HTTP_TRANSACTIONS.md) — matrice finale validée de `0.2.3`, 11 wrappers Transactions, sécurité write/simulation, réaudit 52+14, `KSP-TRANSPORT-007` 37/37, graphes Cargo et deux smokes Devnet passés avant publication stable.
- [`007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) — matrice finale validée de `0.2.4`, inventaire exact 52 current + 14 Deprecated, preuve typed 52/52, audit SIMD final, `KSP-TRANSPORT-007`, workspace complet et deux smokes Devnet passés avant publication stable.
- [`008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) — matrice finale validée de la release stable `0.2.5`, threat model V1, canaris adversariaux, reproduction externe des vecteurs, audit de frontières, normalisation Rust/audit structurel, graphes Cargo et checkpoint final `pre.010-fix.003` vert.
- [`009-V0_2_6_WALLET_DESK_COMPLIANCE.md`](009-V0_2_6_WALLET_DESK_COMPLIANCE.md) — matrice de compliance ouverte en `0.2.6-pre.013`, couvrant composition Config/Wallet/Transport, frontières DTO/IPC/frontend, path/inventory adversarial, capabilities Tauri, dependency firewall, graphes Cargo et smoke Devnet Wallet Desk opt-in.
- [`009-V0_2_6_WALLET_DESK_COMPLIANCE.md`](009-V0_2_6_WALLET_DESK_COMPLIANCE.md) — matrice de compliance ouverte en `0.2.6-pre.013`, étendue aux wires V1/V2, à la migration explicite et au runtime Tauri packagé ; `pre.018` y matérialise la candidate finale, le dernier build opérateur restant à enregistrer avant `rel.001`.

95
docs/validation/009-V0_2_6_WALLET_DESK_COMPLIANCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/009-V0_2_6_WALLET_DESK_COMPLIANCE.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Validation `0.2.6` — Wallet Desk integration / compliance / security
@@ -51,19 +51,19 @@ Le checkpoint opérateur `pre.012` du 21 août 2026 est vert : `cargo fmt`, audi
## 3. Matrice de frontières
| Frontière | Contrat `0.2.6` | Preuve durable |
|---|---|---|
| Frontend -> Config | aucun accès direct env/.env | `release_compliance::backend_keeps_config_wallet_transport_and_logging_ownership_boundaries` + ownership Config |
| Frontend -> Wallet secret | passwords uniquement request-only ; jamais de keypair en IPC | `desktop_security` + `release_compliance::response_dtos_keep_secret_key_material_out_of_ipc` |
| Frontend -> filesystem | aucun path arbitraire ; picker natif Rust | tests import/export + capability audit |
| Frontend -> réseau Solana | aucun `fetch`/WebSocket/RPC direct | `release_compliance::frontend_has_no_direct_filesystem_network_or_secret_persistence_surface` |
| Wallet Desk -> Solana crates | aucune dépendance protocole directe | `release_compliance::wallet_desk_dependency_firewall_and_tauri_capabilities_are_minimal` |
| Wallet Desk -> HTTP | `ksp-onchain-transport-lib` uniquement | manifest + smoke Devnet |
| Wallet Desk -> Wallet crypto | `ksp-wallet-lib` uniquement | manifest + feature canaries |
| Wallet Desk -> logging | façade `ksp-logging-lib` + adapter `tauri-plugin-tracing` | source audit + workspace logging canary |
| locked -> frontend | format/version/VIEW enabled seulement | `desktop_security` |
| VIEW/OWNER handles | Rust-only `AppState` | session/security tests |
| export | OWNER-only, file direct, no-clobber | `desktop_security` + runtime `pre.012` |
| Frontière | Contrat `0.2.6` | Preuve durable |
|------------------------------|--------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| Frontend -> Config | aucun accès direct env/.env | `release_compliance::backend_keeps_config_wallet_transport_and_logging_ownership_boundaries` + ownership Config |
| Frontend -> Wallet secret | passwords uniquement request-only ; jamais de keypair en IPC | `desktop_security` + `release_compliance::response_dtos_keep_secret_key_material_out_of_ipc` |
| Frontend -> filesystem | aucun path arbitraire ; picker natif Rust | tests import/export + capability audit |
| Frontend -> réseau Solana | aucun `fetch`/WebSocket/RPC direct | `release_compliance::frontend_has_no_direct_filesystem_network_or_secret_persistence_surface` |
| Wallet Desk -> Solana crates | aucune dépendance protocole directe | `release_compliance::wallet_desk_dependency_firewall_and_tauri_capabilities_are_minimal` |
| Wallet Desk -> HTTP | `ksp-onchain-transport-lib` uniquement | manifest + smoke Devnet |
| Wallet Desk -> Wallet crypto | `ksp-wallet-lib` uniquement | manifest + feature canaries |
| Wallet Desk -> logging | façade `ksp-logging-lib` + adapter `tauri-plugin-tracing` | source audit + workspace logging canary |
| locked -> frontend | format/version/VIEW enabled seulement | `desktop_security` |
| VIEW/OWNER handles | Rust-only `AppState` | session/security tests |
| export | OWNER-only, file direct, no-clobber | `desktop_security` + runtime `pre.012` |
## 4. Inventory / path adversarial
@@ -238,9 +238,9 @@ cargo test --workspace : BLOCKED par un faux positif du canari Logging global
Le blocage workspace est limité à `ksp-logging-lib/tests/ownership.rs::workspace_crates_do_not_bypass_ksp_logging_facade` : le scanner voit le littéral `tracing::` dans `release_compliance.rs`, alors que ce littéral est la chaîne recherchée par le canari et non un usage de `tracing`. `pre.013-fix.002` supprime ce littéral statique en construisant le motif à l'exécution, sans modifier le scanner global ni relâcher la politique Logging.
La matrice reste ouverte jusqu'à `pre.018`, après les tranches V2 `pre.015`–`pre.017`; `pre.018` ajoute le parcours fonctionnel final, README/USAGE et le build Tauri exécuté en toute dernière opération.
La matrice reste ouverte jusqu'à la preuve opérateur finale de `pre.018`. Les tranches V2 `pre.015`–`pre.017` sont acquises ; `pre.018` matérialise README/USAGE, runtime packagé et candidate, puis le build Tauri est exécuté en toute dernière opération.
## 11. Intercalation V2 à partir de `pre.015`
## 12. Intercalation V2 à partir de `pre.015`
`pre.015` ne modifie pas encore Wallet Desk : il ajoute dans `ksp-wallet-lib` un codec binaire V2 strict et une fixture canonique. Les gates Desk `pre.013`/`pre.014` restent donc applicables sans changement.
@@ -256,3 +256,66 @@ V2 nouvellement créé/importé administration complète conservée en V2
```
Les canaris `pre.016` couvrent également le refus croisé des lecteurs explicitement versionnés et le maintien du format V2 après metadata/rotations/disable/recreate/self-rotation VIEW. `pre.017` matérialise ensuite la migration V1 -> V2 explicite : mémoire, copie no-clobber et remplacement in-place stale-protected, avec conservation identité/metadata/note IDs et canaris tampering/state-conflict. Wallet Desk reste non-migrant et continue à ouvrir/inspecter via les APIs génériques.
## 13. Checkpoint opérateur `pre.017`
Le checkpoint communiqué le 22 août 2026 ferme les tranches fonctionnelles V2 avant candidate :
```text
cargo fmt --all PASS
audit Rust workspace PASS
cargo check --workspace PASS
cargo clippy --workspace --all-targets PASS, sans warning
cargo test --workspace PASS
ksp-wallet-lib 84 passés / 1 benchmark ignored
Wallet Desk desktop_contract 17/17
Wallet Desk desktop_security 12/12
Wallet Desk release_compliance 4/4
```
Le parcours Tauri crate-local avec un `KSP_WALLETS_DIRECTORY` isolé confirme ensuite : création du répertoire effectif Config-owned, import Solana CLI JSON, création native `format_version=2`, ouverture d'une session OWNER, inventory du nouveau wallet et `getBalance` Devnet réussi avec un slot non nul. Aucun build production n'est exécuté à ce checkpoint.
## 14. Candidate `pre.018` — runtime packagé et resources
`pre.018` ferme le point CWD/resources laissé ouvert par `pre.014-fix.001`. Le runtime release ne dépend plus du checkout source :
```text
Tauri bundle.resources
-> documents Config enregistrés + JSON Schemas uniquement
-> aucun .env / logs / wallets / secret
Tauri resource_dir
-> ksp-config-lib::prepare_packaged_runtime
-> racine KSP user-writable résolue par ProjectDirs
-> Config documents seed-only-if-absent
-> Schemas package-owned synchronisés à chaque lancement
-> set_current_dir(runtime_root) avant AppState::initialize
```
Config Desk et Wallet Desk embarquent le même ensemble de huit resources du registre courant. Le guest frontend ne reçoit aucune permission filesystem supplémentaire. Les Config déjà modifiées restent inchangées lors d'un nouveau lancement packagé ; `.env` n'est jamais embarqué ni seedé. Les chemins relatifs Logging/Wallet restent ancrés sur la racine runtime writable sauf override explicite par Config.
Les canaris déterministes de la candidate couvrent le seed Config non destructif, la synchronisation des schemas, le rejet d'une destination symlink sur Unix, l'exposition publique du layout packagé, les mappings Tauri des deux Desks et l'absence de ressources mutables/secrètes dans le bundle Wallet Desk.
## 15. Gate final opérateur `pre.018`
Le delta candidate doit être validé dans cet ordre :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-config-lib
cargo test -p ksp-wallet-lib
cargo test -p ksp-app-config-desk
cargo test -p ksp-app-wallet-desk
cargo test --workspace
```
Le parcours fonctionnel `cargo tauri dev`, les éventuels smokes live et tout audit complémentaire retenu sont exécutés **avant** le build. La dernière opération de validation reste :
```bash
(cd crates/ksp-app-wallet-desk && cargo tauri build)
```
`pre.018` ne préjuge pas du résultat de ce build : la preuve opérateur sera enregistrée avant `rel.001`. `CHANGELOG.md` reste volontairement inchangé pendant la prerelease ; l'entrée stable `0.2.6` appartient à la clôture `rel.001` après gate final vert.