v0.2.0-rel.001

CHANGELOG.md

@@ -1,10 +1,14 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Changelog KSP
 
 Ce changelog résume uniquement les releases KSP considérées comme stables, dans l'ordre chronologique décroissant. Les détails de chaque livraison restent dans `deltas/`.
 
+## 0.2.0 — Audit bot3 et planification de la série `0.2.x` — 2026-08-17
+
+`0.2.0` stabilise le cadrage de la prochaine phase fonctionnelle de KSP après audit de `khadhroony-bot3`. La release fixe l'ordre `0.2.1+` autour du transport HTTP Solana, du Wallet `.kspwallet`, de Wallet Desk, des transports WebSocket/LaserStream/Yellowstone, du transport off-chain de prix, de `ksp-interface-lib` et de `ksp-program-api`; elle impose la couverture exhaustive des surfaces Transport documentées avec warnings KSP pour les opérations deprecated/obsolete encore fonctionnelles et unstable/experimental. Elle stabilise également la progression durable `RAW -> CORE -> DECODE -> SPECIALIZED`, RAW/CORE sans décodage Program, puis des vertical slices complets par groupe à partir de DECODE, avec priorité Solana Core, SPL token/trading, metadata token, Anchor, Meteora/Raydium/Pump/Orca, routing et Market Desk progressive. Le prompt `prompts/006-V0_2_1_START_PROMPT.md` ouvre `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation` avec un gate de sizing imposant qu'une release concrète reste clôturable dans une seule session.
+
 ## 0.1.4 — Config Desk — 2026-08-17
 
 `0.1.4` stabilise `ksp-app-config-desk` comme première application desktop/Tauri spécialisée et modèle de référence des futures applications KSP. La release valide de bout en bout les contrats de `ksp-config-lib` et le lifecycle de `ksp-logging-lib` : shell splash/main, inventaire et diagnostics des documents Config, profils et provenance sûre, management `.env` avec shadowing et reveal Secret privilégié, éditeur Logging typé multi-profils/multi-sinks, persistence atomique, hot reload transactionnel, rollback, sélection runtime explicite, génération observable, fichiers de logs distincts par lancement, bridge frontend vers la façade KSP et panneau Test Logging pour démontrer le routing niveau/target/domain. Elle ajoute également les audits desktop/ownership/sécurité, un registre extensible `file_id -> éditeur spécialisé`, une baseline Logging de release `info`/`warn`, et prépare `0.2.0` comme release intermédiaire d’audit de `khadhroony-bot3` et de planification du reste de `0.2.x`.

Cargo.toml

@@ -1,12 +1,12 @@
 # file: Cargo.toml
-# version: 92
+# version: 95
 
 [workspace]
 resolver = "3"
 members = ["crates/ksp-app-config-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"]
 
 [workspace.package]
-version = "0.1.4"
+version = "0.2.0"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

ROADMAP.md

@@ -1,11 +1,9 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 20 -->
+<!-- version: 24 -->
 
 # Roadmap KSP
 
-Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues pour y parvenir. Une série `X.Y.x` regroupe une famille fonctionnelle de travaux ; elle peut contenir plusieurs releases concrètes et plusieurs sessions.
+Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. Une série `X.Y.x` regroupe une famille fonctionnelle ; chaque release concrète reste une unité de développement/session distincte.
-
-Les décisions architecturales négatives ou de prudence n'apparaissent pas comme des tâches à cocher. Elles sont conservées dans les règles et documents d'architecture.
 
 ## Légende
 
@@ -15,6 +13,13 @@ Les décisions architecturales négatives ou de prudence n'apparaissent pas comm
 - `[C]` — annulé ;
 - `[R]` — reporté.
 
+## Discipline de livraison
+
+- Une prerelease vise environ **15 à 20 minutes de travail effectif**.
+- Une release concrète doit être dimensionnée pour pouvoir être ouverte et clôturée dans **une seule session de chat**.
+- Si `pre.001` révèle qu'une release est trop grosse, elle est scindée avant implémentation fonctionnelle lourde.
+- À partir des couches Program/Decode, KSP progresse verticalement groupe par groupe plutôt que par grandes vagues horizontales de decoders/materializers/executors séparés.
+
 ## 0.0.x — Fondation
 
 - [X] `0.0.1` — Initialiser le dépôt.
@@ -25,97 +30,127 @@ Les décisions architecturales négatives ou de prudence n'apparaissent pas comm
 
 ## 0.1.x — Fondations N1
 
-### Objectifs
+- [X] `0.1.1` — `ksp-core-lib` : Error/Result, Program IDs fondamentaux et primitives N1.
+- [X] `0.1.2` — `ksp-logging-lib` : façade KSP de tracing.
+- [X] `0.1.3` — `ksp-config-lib` : documents, profils, environnement, persistence et adapters.
+- [X] `0.1.4` — `ksp-app-config-desk` : première application Tauri de référence.
 
-Regrouper les releases consacrées aux fondations N1. Chaque release concrète est une unité de développement/session distincte et commence par son propre `pre.001` de brainstorming/audit/planification.
+## 0.2.x — Accès Solana, Wallet et contrats d'extension initiaux
 
-### Releases concrètes
+### Cadrage
 
-- [X] `0.1.1` — Stabiliser `ksp-core-lib` : `Error`/`Result`, Program IDs fondamentaux et primitives réellement N1.
+- [X] `0.2.0` — Audit bot3, ordre de `0.2.x`, architecture durable et prompt `0.2.1` stabilisés par `0.2.0-rel.001`.
-- [X] `0.1.2` — Introduire `ksp-logging-lib` comme façade KSP de `tracing`, `tracing-appender` et `tracing-subscriber`.
+- [X] `0.2.0-pre.001` — Méthode d'audit, cartographie initiale et matrice provisoire.
-- [X] `0.1.3` — Stabiliser `ksp-config-lib` : documents, profils, résolution, validation, environnement KSP/KSPB, management/persistence et adapter Logging.
+- [X] `0.2.0-pre.002` — Fixer l'ordre fonctionnel, la discipline de sizing, le pipeline RAW/CORE/DECODE/SPECIALIZED et préparer le prompt `0.2.1`.
-- [X] `0.1.4` — Introduire `ksp-app-config-desk` pour valider réellement Config et la frontière Tauri.
+- [X] `0.2.0-pre.003` — Audit de cohérence final : règles résiduelles supersédées corrigées, fiches `0.2.1+` complétées, TODO bot3 utiles préservés et prompt `0.2.1` finalisé.
+- [X] `0.2.0-rel.001` — Publication stable du cadrage `0.2.x`; prochaine release : `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`.
 
-`0.1.1`, `0.1.2`, `0.1.3` et `0.1.4` sont désormais stables. `0.1.4` publie `ksp-app-config-desk` comme première validation desktop/Tauri de Config et modèle de référence des futures applications Tauri KSP. La prochaine session est `0.2.0`, release intermédiaire d’audit de `khadhroony-bot3` et de planification du reste de `0.2.x`.
+### Releases fonctionnelles décidées/pressenties
 
-Les contrats publics supplémentaires ne sont introduits que lorsqu'une release concrète en démontre le besoin.
+- [ ] `0.2.1` — Introduire `ksp-onchain-transport-lib` avec HTTP Solana/JSON-RPC, settings publics, document Config standard + adapter, pools, rôles, priorités, limites, retry/backoff et couverture complète de la documentation HTTP ciblée.
+- [ ] `0.2.2` — Introduire `ksp-wallet-lib`, le format `.kspwallet`, la gestion sûre des secrets et une architecture d'import/export extensible ; exclure `WalletPolicy`.
+- [ ] `0.2.3` — Introduire `ksp-app-wallet-desk` utilisant Config composite + Wallet + transport HTTP, notamment pour afficher l'identité et le solde d'un wallet.
+- [ ] `0.2.4` — É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.5` — Ajouter Helius LaserStream WebSocket comme extension du moteur WebSocket standard, sans duplication de client.
+- [ ] `0.2.6` — Ajouter une première fondation Yellowstone gRPC standard/provider-neutral ; dimensionner la surface exacte à `pre.001` selon la documentation normative actuelle.
+- [ ] `0.2.7` — Introduire `ksp-offchain-transport-lib` avec un premier lecteur de prix, au minimum SOL/USD et SOL/EUR.
+- [ ] `0.2.8` — Introduire une petite application desk de visualisation des prix.
+- [ ] `0.2.9` — Introduire la première surface de `ksp-interface-lib`, comprenant une API wire publique utilisable par les implémentations officielles et externes.
+- [ ] `0.2.10` — Introduire `ksp-program-api` comme premier contrat Program extensible, sans imposer encore `ksp-program-lib` complet.
 
-## 0.2.x — Accès Solana et fondation programmes
+### Règles Transport pour toute la série
 
-### Release de cadrage `0.2.0`
+- [ ] Couvrir toutes les méthodes/opérations documentées pour la surface normative ciblée par chaque release.
+- [ ] Conserver les méthodes deprecated/obsolete encore fonctionnelles et émettre un `warn` KSP lors de leur utilisation.
+- [ ] Implémenter les méthodes unstable/experimental ciblées et émettre un `warn` KSP lors de leur utilisation.
+- [ ] Centraliser la metadata de statut des méthodes plutôt que disperser des warnings ad hoc.
+- [ ] Garder `ksp-onchain-transport-lib` indépendant de `ksp-config-lib`, du Store et des modèles Program/métier.
 
-- [ ] `0.2.0` — Auditer les fonctionnalités pertinentes de `khadhroony-bot3`, décider ce qui doit être repris, refondu, abandonné ou ajouté dans KSP, puis découper et ordonner les releases fonctionnelles restantes de `0.2.x`.
+## Architecture de données — progression canonique
 
-`0.2.0` est une release intermédiaire de transition et de planification de série. Elle ne doit pas démarrer par l'implémentation arbitraire d'un composant N2 : elle établit d'abord la cartographie fonctionnelle, les écarts avec KSP, les dépendances, les contrats à préserver ou redéfinir et le découpage concret de `0.2.1`, `0.2.2`, etc.
+La chaîne durable cible est :
 
-### Capacités à répartir dans les releases fonctionnelles suivantes
+```text
+RAW -> CORE -> DECODE -> SPECIALIZED
+```
 
-- [ ] Introduire `ksp-onchain-transport-lib` avec des modèles de transport homogènes indépendants du store.
+- **RAW** et **CORE** ne nécessitent aucun décodage Program.
-- [ ] Introduire `ksp-wallet-lib` et `ksp-app-wallet-desk`.
+- À la fin de chaque couche horizontale RAW/CORE, ajouter les jobs/workers/apps nécessaires pour la rendre réellement exploitable avant d'ouvrir la couche suivante.
-- [ ] Développer la première surface utile de `ksp-interface-lib`.
+- À partir de **DECODE**, avancer verticalement groupe par groupe : wire -> decode -> matérialisation -> projection spécialisée si utile -> préparation d'exécution -> policy -> execution -> scénarios Devnet.
-- [ ] Introduire `ksp-program-api` puis `ksp-program-lib`.
-- [ ] Définir `ksp-execution-policy-api` comme contrat de policy commun à plusieurs contextes.
-- [ ] Introduire `ksp-execution-lib` lorsque le premier cycle d'exécution réel justifie l'orchestration programme/policy/wallet/transport.
-- [ ] Introduire `ksp-offchain-transport-lib` seulement au premier besoin réel.
 
-## 0.3.x — Données, stockage et acquisition raw
+## 0.3.x — RAW / acquisition persistée
 
-- [ ] Introduire `ksp-materializer-api` / `ksp-materializer-lib`.
+- [ ] `0.3.1` — Introduire `ksp-store-api` + `ksp-store-lib` avec PostgreSQL de référence et **modèles/persistence RAW uniquement**.
-- [ ] Introduire `ksp-store-api` / `ksp-store-lib` avec PostgreSQL de référence.
+- [ ] `0.3.2` — Étendre `ksp-interface-lib` avec les wires génériques nécessaires aux acquisitions et à la future normalisation CORE.
-- [ ] Établir les niveaux durables D1 Raw, D2 Core, D3 journal de matérialisation générique et D4 projections de domaine.
+- [ ] `0.3.3` — Introduire `ksp-job-api` et un job de backfill historique concret.
-- [ ] Garantir des replays indépendants D1 -> D2, D2 -> D3 et D3 -> D4.
+- [ ] `0.3.4` — Introduire une application spécialisée de backfill/inspection RAW.
-- [ ] Introduire `ksp-app-store-desk`.
+- [ ] Compléter ensuite la couche RAW avec le worker/service live, son contrôle et les outils d'exploitation réellement nécessaires avant de passer à CORE.
-- [ ] Introduire `ksp-worker-api` et `ksp-worker-raw-retriever`.
-- [ ] Introduire `ksp-worker-control-lib` lorsque le manager W1 crée le premier besoin concret.
-- [ ] Introduire `ksp-job-api` et `ksp-job-backfill`.
-- [ ] Introduire les pipelines spécialisés raw ingestion, Core processing, generic materialization et domain projection lorsque leurs premières frontières fonctionnelles sont développées.
-- [ ] Introduire les jobs de replay indépendants D1 -> D2, D2 -> D3 et D3 -> D4.
-- [ ] Normaliser les notifications de données persistées indépendamment de leur producteur et conserver le Store comme source de vérité du backlog.
-- [ ] Mettre en place claim/lease, outcomes durables et reprise après crash pour les traitements concurrents.
 
-## 0.4.x — Baseline Solana, SPL et metadata
+## Série CORE suivante
 
-- [ ] Ajouter progressivement les decoders et `ProgramExecutionPreparer` Core/SPL nécessaires.
+- [ ] Définir la persistence CORE canonique Solana générique.
-- [ ] Ajouter Token, Token-2022, ATA et metadata utiles.
+- [ ] Implémenter `RAW -> CORE` sans decoder Program : blocs, slots, signatures, transactions/messages, comptes, instructions/CPI brutes, logs/meta et relations structurelles.
-- [ ] Introduire `ksp-offchain-transport-lib` au plus tard au premier besoin externe.
+- [ ] Ajouter replay/backfill RAW -> CORE.
-- [ ] Ajouter materializers et jobs ponctuels nécessaires.
+- [ ] Ajouter worker/service CORE.
-- [ ] Ajouter les crates `ksp-scenario-<domain>-lib` spécialisées.
+- [ ] Ajouter l'application de contrôle/inspection CORE utile.
-- [ ] Ajouter les demos `ksp-app-scenario-<domain>-<environment>-desk-demo` correspondantes.
-- [ ] Garder Memo, Token, ATA, Token-2022 séparés ; regrouper uniquement Metaplex Token Metadata + Token-2022 Metadata dans la famille metadata ; garder SPM séparé.
 
-## 0.5.x — Anchor et protocoles trading
+## Séries DECODE/SPECIALIZED/EXECUTION — progression verticale
 
-- [ ] Introduire Anchor.
+### Priorité 1 — Solana Core Programs
-- [ ] Étendre Meteora par surfaces bornées.
-- [ ] Étendre Raydium par surfaces bornées.
-- [ ] Ajouter progressivement Pump, Orca, Jupiter, OKX et autres intégrations utiles.
-- [ ] Ajouter interfaces, program implementations, materializers, jobs/scénarios/demos nécessaires pour chaque surface.
 
-## 0.6.x — Processing autonome et orchestration
+- [ ] Wire/decoding des programmes Core nécessaires transversalement.
+- [ ] Matérialisation et projections utiles.
+- [ ] Préparation d'exécution, policy et scénarios Devnet pour les opérations retenues.
 
-- [ ] Introduire `ksp-worker-core-processor` pour D1 Raw -> D2 Core canonique.
+### Priorité 2 — SPL token/trading
-- [ ] Introduire `ksp-worker-generic-materializer` pour D2 Core -> D3 journal de matérialisation générique.
-- [ ] Introduire `ksp-worker-domain-projector` pour D3 -> D4 projections spécialisées ; nom révisable.
-- [ ] Exploiter les mêmes pipelines spécialisés pour les workers live et les jobs de replay afin d'éviter la duplication des frontières de processing.
-- [ ] Étendre `ksp-worker-control-lib` à la gouvernance de plusieurs workers autonomes.
-- [ ] Fournir pour chaque worker un mode service autonome, avec logique réutilisable séparée du binaire d'enveloppe.
-- [ ] Construire d'abord les applications spécialisées nécessaires au développement, test et exploitation de chaque capacité.
-- [ ] Garder jobs et workers sous des lifecycle APIs séparées.
 
-## 0.7.x — Trading Intelligence
+- [ ] SPL Token.
+- [ ] Associated Token Account.
+- [ ] Token-2022 et extensions pertinentes.
+- [ ] Pour chaque famille : decode -> materialize -> specialized -> prepare -> policy -> execute -> scenarios.
 
-- [ ] Statistiques et métriques.
+### Priorité 3 — Metadata token
-- [ ] Features et datasets historiques.
+
-- [ ] Signaux et risque.
+- [ ] Metaplex Token Metadata.
+- [ ] Token-2022 Metadata.
+- [R] Solana Program Metadata (SPM) — redéveloppement plus tard avec le décodage généraliste.
+
+### Priorité 4 — Anchor
+
+- [ ] Introduire les contrats et mécanismes Anchor nécessaires aux protocoles trading suivants.
+
+### Priorité 5 — DEX à fort intérêt
+
+- [ ] Meteora, y compris vaults/fees/positions/états auxiliaires nécessaires à son groupe.
+- [ ] Raydium, y compris programmes satellites nécessaires.
+- [ ] Pump, y compris fee program et composants launch/bonding/pool nécessaires.
+- [ ] Orca, y compris programmes satellites nécessaires.
+- [ ] Chaque groupe est terminé verticalement avant de devenir secondaire au profit du suivant.
+
+### Market Desk V1
+
+- [ ] Après les premiers groupes Meteora/Raydium/Pump/Orca, introduire une petite `ksp-app-market-desk` spécialisée.
+- [ ] Visualiser tokens, pools/markets, liquidité, swaps/trades, prix, volumes, OHLC/candles et activité live/récente lorsque disponible.
+- [ ] Lire les projections SPECIALIZED KSP ; ne pas reconstruire la logique protocolaire dans l'UI.
+
+### Routing
+
+- [ ] Jupiter.
+- [ ] OKX et autres routeurs selon besoin réel.
+- [ ] Enrichir Market Desk avec routes, legs, DEX impliqués, fees/slippage et comparaison quote/execution lorsque disponible.
+
+### Trading-adjacent puis décodage généraliste
+
+- [ ] Ajouter ensuite les programmes indépendants utiles au trading : oracles, locks/vesting indépendants, lifecycle token, risk/signaux, etc.
+- [ ] Ne jamais y repousser un satellite appartenant à un groupe DEX déjà ciblé.
+- [ ] Étendre enfin le décodage au reste de Solana selon valeur fonctionnelle.
+
+## Trading Intelligence et produits ultérieurs
+
+- [ ] Statistiques/features/datasets historiques.
+- [ ] Signaux, risque, anomalies et patterns.
 - [ ] Replay analytique/backtests.
-- [ ] Patterns/anomalies.
+- [ ] XGBoost puis autres modèles lorsque les données et contrats sont stables.
-- [ ] XGBoost puis autres modèles lorsque les contrats sont stables.
+- [ ] Construire ensuite les produits de trading opérationnel au-dessus de ces couches.
-
+- [ ] Faire évoluer Market Desk vers davantage d'analyse sans la confondre avec l'application globale ou l'orchestrateur.
-## 0.8.x et suivantes — Trading opérationnel et expansion produits
+- [ ] Étudier plus tard les autres applications Wallet : mobile, extensions navigateur et web.
-
-- [ ] Construire les couches puis l'application de trading monoposte au-dessus de Trading Intelligence.
-- [ ] Étendre l'automatisation de trading.
-- [ ] Étendre continuellement Program IDs, decoders, execution preparers et materializers.
-- [ ] Construire progressivement l'explorer Solana.
-- [ ] Construire progressivement l'explorer/analyse DEX.
-- [ ] Étudier plus tard d'autres applications utilisant `ksp-wallet-lib`, notamment mobile, extensions navigateur et web.

crates/ksp-app-config-desk/README.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-config-desk/README.md -->
-<!-- version: 23 -->
+<!-- version: 24 -->
 
 # `ksp-app-config-desk`
 
@@ -89,7 +89,7 @@ Deux audits d'intégration applicatifs complètent les audits Config/Logging exi
 Les artefacts frontend construits ne sont pas versionnés. `tauri.conf.json` fixe :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 `vite.config.ts` résout cette même destination depuis la racine de la crate, ce qui maintient `dist` hors du workspace source et l'aligne avec la stratégie `.cargo/config.toml` pour les artefacts Rust.

crates/ksp-app-config-desk/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-app-config-desk/USAGE.md -->
-<!-- version: 23 -->
+<!-- version: 24 -->
 
 # Utilisation de `ksp-app-config-desk`
 
@@ -66,7 +66,7 @@ npm run build
 Vite construit les pages `main.html` et `splash.html` vers :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 Cette destination est résolue depuis la racine de la crate dans `vite.config.ts` et correspond au `frontendDist` de `tauri.conf.json`.

crates/ksp-app-config-desk/tauri.conf.json

@@ -7,7 +7,7 @@
         "beforeDevCommand": "npm run dev",
         "devUrl": "http://localhost:1430",
         "beforeBuildCommand": "npm run build",
-        "frontendDist": "../../builds/khadhroony-solana-project/ksp-app-config-desk/dist"
+        "frontendDist": "../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist"
     },
     "app": {
         "windows": [

crates/ksp-app-config-desk/vite.config.ts

@@ -8,7 +8,7 @@ import { defineConfig, normalizePath } from "vite";
 
 const appRoot = fileURLToPath(new URL(".", import.meta.url));
 const frontendRoot = normalizePath(resolve(appRoot, "frontend"));
-const frontendDist = normalizePath(resolve(appRoot, "../../builds/khadhroony-solana-project/ksp-app-config-desk/dist"));
+const frontendDist = normalizePath(resolve(appRoot, "../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist"));
 const devHost = process.env.TAURI_DEV_HOST;
 
 export default defineConfig({

deltas/0.1.4/pre.004.md

@@ -1,5 +1,5 @@
 <!-- file: deltas/0.1.4/pre.004.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Delta 0.1.4-pre.004 — squelette Rust/Tauri de `ksp-app-config-desk`
 
@@ -134,7 +134,7 @@ Le plugin tracing n'est volontairement pas déclaré dans cette tranche ; son co
 La destination de build est fixée dès maintenant à :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 `tauri.conf.json` l'utilise comme `build.frontendDist`. `vite.config.ts` utilisera la même valeur comme `build.outDir` à partir de `pre.005`.
@@ -255,5 +255,5 @@ Si cette tranche est validée et commitée, `pre.005` introduira le gabarit fron
 - Bootstrap, Font Awesome, SimpleBar et `resize-observer-polyfill` ;
 - `tauri-plugin-tracing` + `@fltsci/tauri-plugin-tracing` ;
 - Vite strict `1430`, HMR `1431` ;
-- output `../../builds/khadhroony-solana-project/ksp-app-config-desk/dist` ;
+- output `../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist` ;
 - premier `cargo tauri dev` du shell minimal.

deltas/0.1.4/pre.005.md

@@ -1,5 +1,5 @@
 <!-- file: deltas/0.1.4/pre.005.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Delta 0.1.4-pre.005 — gabarit frontend Vite/TypeScript/SCSS et tracing Tauri
 
@@ -167,13 +167,13 @@ Le serveur est configuré ainsi :
 `tauri.conf.json` possédait déjà :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 `vite.config.ts` part maintenant de la racine de la crate puis résout **le même chemin contractuel** :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 Le `root` Vite reste `frontend/`, mais l'utilisation d'un path absolu résolu depuis la crate évite que `build.outDir` ne soit accidentellement interprété relativement à `frontend/`.

deltas/0.1.4/pre.016-fix.002.md

@@ -1,3 +1,6 @@
+<!-- file: deltas/0.1.4/pre.016-fix.002.md -->
+<!-- version: 2 -->
+
 # 0.1.4-pre.016-fix.002
 
 ## Objet

deltas/0.2.0/pre.001.md

@@ -0,0 +1,242 @@
+<!-- file: deltas/0.2.0/pre.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-pre.001
+
+## Base requise
+
+Release stable attendue :
+
+```text
+v0.1.4
+```
+
+L'archive KSP fournie contient :
+
+```text
+workspace.package.version = "0.1.4"
+```
+
+et les quatre fondations stabilisées :
+
+- `ksp-core-lib` ;
+- `ksp-logging-lib` ;
+- `ksp-config-lib` ;
+- `ksp-app-config-desk`.
+
+L'archive ne contient pas `.git`; le tag `v0.1.4` n'est donc pas revérifiable localement depuis le zip.
+
+Le snapshot `khadhroony-bot3` fourni pour audit est l'archive d'échange :
+
+```text
+khadhroony-bot3_v0.5.3-pre.005-fix010.zip
+```
+
+Son `Cargo.toml` porte `workspace.package.version = "0.5.3-pre.5"`.
+
+## Objectif
+
+Ouvrir `0.2.0` par la tranche obligatoire de brainstorming, inventaire et méthode d'audit, sans commencer l'implémentation d'une capacité Solana N2.
+
+Le plan directeur est créé dans :
+
+```text
+docs/plans/007-V0_2_0_SERIES_PLANNING.md
+```
+
+## Version Cargo
+
+Conformément à `VER-ID-009`, une prerelease non-fix synchronise la version Cargo même lorsque son contenu fonctionnel est documentaire.
+
+`workspace.package.version` passe donc de :
+
+```text
+0.1.4
+```
+
+à :
+
+```text
+0.2.0-pre.1
+```
+
+L'identifiant de livraison reste :
+
+```text
+0.2.0-pre.001
+```
+
+Aucune nouvelle dépendance n'est ajoutée.
+
+## Méthode d'audit définie
+
+Chaque élément bot3 est désormais séparé en :
+
+- fonctionnalité ;
+- implémentation historique ;
+- contrat public ;
+- dépendance externe ;
+- convention de projet.
+
+La décision `reprendre / adapter / refondre / abandonner / ajouter` porte d'abord sur le besoin et le contrat utile, jamais implicitement sur une copie du code.
+
+La fiche d'audit couvre ownership, dépendances, Config/environnement, Logging, tests/invariants, dette, risques et lot `0.2.x` candidat.
+
+## Première cartographie bot3
+
+Le snapshot a été inspecté par domaines.
+
+### Wallet
+
+`ks-wallet` expose notamment alias/identité non secrète, wallet temporaire, manager multi-wallet, format `.kswallet` protégé, password redacted, `UnlockedWallet`, création atomique/no-clobber, changement de password, migration legacy, import/export Solana CLI JSON/Base58 et contrôles de collision.
+
+Les invariants de sécurité et le contrat de capacité de signature sont des candidats forts à la reprise/adaptation.
+
+Le store JSON legacy `TemporaryWalletStore` et le `lamport_spend_limit` situé dans `WalletPolicy` ne sont pas retenus comme frontières cibles.
+
+### Transport
+
+`ks-onchain-transport` possède une surface HTTP/WS importante : JSON-RPC, pools, rôles/quota, typed standard methods, sessions/subscriptions/reconnect et méthodes techniques d'exécution.
+
+Deux couplages imposent déjà une refonte de frontière :
+
+- le public transport consomme directement des types `ks-config` ;
+- `getTransaction` et le trait RPC minimal dépendent de types `ks-lib`.
+
+KSP doit produire des modèles transport homogènes possédés par `ksp-onchain-transport-lib`, sans dépendance Program/Store.
+
+### Interface / Program / Execution
+
+Bot3 ne possède pas de crate Interface isolée : wire, codecs et protocoles sont dispersés dans `ks-lib`, qui regroupe decoder, executor et materializer.
+
+Les API `DcApi*` / `ExApi*` contiennent des concepts utiles mais ne correspondent pas au découpage KSP cible. Elles seront utilisées comme inventaire de contrats et de preuves, puis réparties entre `ksp-interface-lib`, `ksp-program-api`, `ksp-program-lib`, `ksp-execution-policy-api` et éventuellement `ksp-execution-lib`.
+
+### Scénarios/demos
+
+Le principe de scénarios réutilisables hors Tauri est conservé. En revanche la crate multi-domaines `ks-pipeline-demo-scenarios` et l'application omnibus `kb-app-demo-desktop` ne sont pas des modèles cibles KSP.
+
+### Off-chain
+
+Aucune crate générale off-chain n'existe dans le snapshot. Le besoin reste conditionnel et ne sera pas introduit par anticipation.
+
+## Première matrice
+
+Le plan `007` contient une première matrice provisoire couvrant Wallet, Transport, Interface, Program, Execution, scenarios/demos et off-chain.
+
+Aucun numéro `0.2.1+` n'est figé dans cette tranche. Les candidats restent des lots fonctionnels non numérotés.
+
+## Graphe de dépendances initial
+
+Le plan confirme notamment :
+
+```text
+Wallet ---------------------------+
+                                  |
+Interface -> Program API/Program -+-> Execution policy -> Execution
+                                  |
+Transport ------------------------+
+```
+
+avec les nuances suivantes :
+
+- Wallet, Transport et Interface sont largement indépendants au démarrage ;
+- Program dépend d'Interface pour la première surface wire réelle ;
+- Execution ne doit être créée que si un cycle réel justifie Program + Policy + Wallet + Transport ;
+- Store/Materializer/worker restent hors `0.2.x`.
+
+## Prévision souple de `0.2.0`
+
+Le plan prévoit initialement :
+
+```text
+pre.001  méthode + cartographie initiale
+pre.002  Wallet
+pre.003  transport on-chain
+pre.004  Interface/wire + dépendances
+pre.005  Program API/Program
+pre.006  policy/execution
+pre.007  scenarios/demos/off-chain gaps
+pre.008  matrice/graphe/découpage candidat
+pre.009  challenge et dimensionnement des releases 0.2.1+
+pre.010  clôture/docs/nettoyage/prompt suivant
+```
+
+La séquence reste révisable.
+
+## Fichiers ajoutés
+
+```text
+docs/plans/007-V0_2_0_SERIES_PLANNING.md
+deltas/0.2.0/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 supprimés
+
+Aucun.
+
+## Validations exécutées
+
+- lecture de `ROADMAP.md`, de `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, des règles KSP et des documents d'architecture Program/Wire/Execution/Scenario ;
+- inspection du workspace KSP stable `0.1.4` ;
+- inspection du workspace bot3 fourni et de ses manifests ;
+- inventaire ciblé de `ks-wallet`, `ks-wallet-demo-scenarios`, `ks-onchain-transport`, `ks-lib`, `ks-pipeline`, `ks-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
+- inspection des guides/rapports Wallet bot3 et de la configuration historique Wallet/Transport/Execution ;
+- contrôle de la présence des surfaces public decoder/executor et des principaux couplages de dépendances ;
+- vérification documentaire de l'absence de développement N2 dans cette tranche.
+
+## Validations non exécutées
+
+Aucune fonctionnalité Rust n'est ajoutée et aucune dépendance n'est modifiée hors signal de version Cargo.
+
+Les versions upstream des dépendances candidates ne sont pas auditées dans `pre.001` car aucune dépendance n'est introduite. Elles seront vérifiées depuis les sources officielles au moment où une tranche décide réellement de les ajouter.
+
+Le sandbox de préparation ne fournit pas le binaire `cargo` (`cargo: command not found`). Les validations suivantes n'ont donc pas pu être exécutées ici :
+
+```text
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+```
+
+Elles devront être rejouées sur le poste de développement avant commit de `pre.001`.
+
+L'archive source KSP fournie ne contient pas de métadonnées `.git`. Le commit ne peut donc pas être créé ni vérifié dans ce sandbox. Après application de la livraison sur le checkout Git canonique et validation technique, le commit attendu suit `VER-GIT-001` : `v0.2.0-pre.001`.
+
+## Décisions prises
+
+- `0.2.0` reste une release d'audit, pas la première release N2 ;
+- aucune migration mécanique de bot3 ;
+- fondations bot3 déjà remplacées par `0.1.x` utilisées uniquement comme référence historique ;
+- Wallet bot3 considéré comme candidat mature à reprendre/adapter, avec abandon du store JSON legacy comme cible ;
+- Transport bot3 considéré comme riche fonctionnellement mais nécessitant une nouvelle frontière publique sans `ks-lib` ;
+- `ks-lib` monolithique non retenu comme architecture cible ;
+- Interface/wire doit être auditée contrat par contrat ;
+- Program preparation, policy et execution restent séparés ;
+- scenarios réutilisables conservés comme méthode, mais spécialisés par domaine ;
+- off-chain reste `need-driven` ;
+- aucun numéro `0.2.1+` n'est figé dans `pre.001`.
+
+## Questions ouvertes
+
+Les questions structurantes sont conservées dans le plan `007`, notamment :
+
+- compatibilité exacte du format `.kswallet` bot3 avec KSP ;
+- primitive signer publique minimale ;
+- séparation ou non des releases Transport HTTP/WS ;
+- frontière transport/Core de `getTransaction` ;
+- stratégie exacte de réexport/réimplémentation des interfaces Solana/SPL/Metaplex ;
+- choix du premier Program canari ;
+- nécessité réelle d'Execution dans `0.2.x`.
+
+La prochaine tranche prévue est l'audit Wallet détaillé.

deltas/0.2.0/pre.002.md

@@ -0,0 +1,195 @@
+<!-- file: deltas/0.2.0/pre.002.md -->
+<!-- version: 1 -->
+
+# Delta `0.2.0-pre.002`
+
+## Identité
+
+```text
+release : 0.2.0
+prerelease : pre.002
+identifiant de commit attendu : v0.2.0-pre.002
+workspace.package.version : 0.2.0-pre.2
+base : 0.2.0-pre.001
+```
+
+Cette livraison est une **nouvelle tranche planifiée** et non un `pre.001-fix.001` : `pre.001` avait volontairement laissé le découpage `0.2.1+` ouvert. `pre.002` ajoute de nouvelles décisions de planification/architecture issues de l'audit et du brainstorming suivants.
+
+## Mission
+
+Consolider le plan de série `0.2.x`, fixer la première séquence fonctionnelle, corriger l'ancienne ambiguïté D1/D2 liée au décodage Program, établir la progression `RAW -> CORE -> DECODE -> SPECIALIZED`, formaliser la discipline de sizing d'une release/session et préparer un prompt de démarrage complet pour `0.2.1`.
+
+Aucune capacité Solana runtime N2 n'est implémentée dans cette tranche.
+
+## Décisions principales
+
+### Dimensionnement
+
+- une prerelease vise environ 15–20 minutes de travail effectif ;
+- une release concrète doit être entièrement clôturable dans une seule session de chat ;
+- si `pre.001` révèle un risque de dépassement, la release est scindée avant implémentation fonctionnelle lourde.
+
+### Début de `0.2.x`
+
+```text
+0.2.1  HTTP Solana foundation
+0.2.2  ksp-wallet-lib / .kspwallet
+0.2.3  ksp-app-wallet-desk
+0.2.4  standard WebSocket
+0.2.5  Helius LaserStream WebSocket
+0.2.6  Yellowstone gRPC standard foundation
+0.2.7  off-chain price transport
+0.2.8  price desk
+0.2.9  ksp-interface-lib foundation
+0.2.10 ksp-program-api foundation
+```
+
+HTTP précède Wallet afin que Wallet Desk puisse être validé avec un solde réseau réel.
+
+### Transport
+
+- `ksp-onchain-transport-lib` possède ses settings publics et ne dépend pas de Config ;
+- `ksp-config-lib` peut fournir un document standard Transport et un adapter Config -> Transport ;
+- pools/rôles/priorités/limites HTTP sont retenus ;
+- toute méthode documentée de la surface normative ciblée doit être inventoriée/implémentée sauf impossibilité documentée ;
+- une méthode deprecated/obsolete encore fonctionnelle émet un warning KSP à l'utilisation ;
+- une méthode unstable/experimental émet également un warning KSP ;
+- WebSocket autorise plusieurs sessions sur une même URL mais n'impose pas encore un pool automatique ;
+- Helius WS réutilise le moteur standard ;
+- Yellowstone reste provider-neutral dans sa première version ;
+- providers avancés/shred streams sont reportés dans IDEAS.
+
+### Wallet
+
+- format natif KSP : `.kspwallet` ;
+- temporary wallet JSON historique abandonné ;
+- `WalletPolicy` sort de Wallet et relève de la future execution policy ;
+- import/export reste extensible, formats supplémentaires suivis dans IDEAS.
+
+### Interface / Program / Policy
+
+- `ksp-interface-lib` expose sa propre API publique wire ; pas de `ksp-interface-api` séparée actuellement ;
+- nomenclature confirmée : `ksp-program-api` / `ksp-program-lib` ;
+- `ksp-execution-policy-api` reste le contrat commun ; petites policies locales dans scenarios/orchestrateurs, libs communes uniquement si réutilisation réelle.
+
+### Données
+
+La chaîne durable devient explicitement :
+
+```text
+RAW -> CORE -> DECODE -> SPECIALIZED
+```
+
+- RAW et CORE ne nécessitent aucun decoder Program ;
+- CORE est une normalisation générique Solana ;
+- Program decoding commence à CORE -> DECODE ;
+- à partir de DECODE, progression verticale groupe par groupe.
+
+### Groupes Program
+
+Ordre prioritaire :
+
+```text
+Solana Core Programs
+-> SPL token/trading
+-> token metadata
+-> Anchor
+-> Meteora
+-> Raydium
+-> Pump
+-> Orca
+-> Market Desk V1
+-> Jupiter/OKX routing
+-> Market Desk V2
+-> trading-adjacent
+-> general decoding
+```
+
+Les programmes satellites nécessaires restent dans leur groupe : Meteora vaults avec Meteora, Pump fee avec Pump, etc.
+
+### Market Desk
+
+Une première `ksp-app-market-desk` est prévue après les DEX prioritaires pour afficher notamment tokens, pools, liquidity, trades, prix et OHLC. Elle est enrichie après routing avec routes/legs/fees/slippage/quote-execution.
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+ROADMAP.md
+docs/000-README.md
+docs/IDEAS.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/006-WIRE_AND_PROGRAM.md
+docs/architecture/007-EXECUTION_AND_POLICY.md
+docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
+docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
+docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
+docs/plans/000-README.md
+docs/plans/001-V0_0_3_PLAN.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/plans/007-V0_2_0_SERIES_PLANNING.md
+docs/rules/PROMPT_STRUCTURE.md
+docs/rules/RULES_DEPENDENCIES.md
+docs/rules/RULES_KSP.md
+prompts/000-README.md
+```
+
+## Fichier ajouté
+
+```text
+prompts/006-V0_2_1_START_PROMPT.md
+```
+
+Le prompt `0.2.1` impose notamment :
+
+- audit bot3 précis ;
+- consultation des sources officielles Solana actuelles ;
+- matrice exhaustive des méthodes HTTP ;
+- classification stable/deprecated/unstable ;
+- warnings runtime appropriés ;
+- ownership Config/Transport ;
+- pools/rôles/limites ;
+- tests/canaries ;
+- gate de sizing avant grosse implémentation ;
+- préparation du futur plan `docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md`.
+
+## Validations réalisées dans l'environnement d'échange
+
+- parsing TOML du `Cargo.toml` via Python `tomllib` ;
+- contrôle de la version Cargo `0.2.0-pre.2` ;
+- contrôle des en-têtes `<!-- file: ... -->` / `<!-- version: ... -->` des fichiers modifiés ;
+- contrôle des fences Markdown équilibrées ;
+- contrôle des liens Markdown locaux des fichiers modifiés ;
+- recherche de contradictions actives principales (`ksp-program-api-lib`, ancienne dépendance Program dans RAW -> CORE, anciennes chaînes de workers/pipelines figées) ;
+- annotation explicite du plan historique `0.0.3` pour distinguer ses anciennes décisions des règles désormais actives ;
+- contrôle de l'archive d'échange et calcul SHA-256.
+
+## Validations non exécutables dans cet environnement
+
+Le conteneur d'échange ne fournit ni `cargo` ni `rustc`. Les commandes Rust doivent donc être exécutées après application sur le dépôt canonique :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+```
+
+Aucune de ces commandes n'est déclarée réussie dans ce delta.
+
+## Commit attendu
+
+Après application et validations sur le dépôt canonique :
+
+```text
+v0.2.0-pre.002
+```
+
+Conformément aux règles KSP, ce commit de prerelease ne reçoit pas de tag Git stable.
+
+## Suite
+
+Le travail restant de `0.2.0` est volontairement court : audit de cohérence final, correction des écarts documentaires restants, finalisation du prompt `0.2.1`, puis publication `0.2.0-rel.001` lorsque le cadrage est validé.

deltas/0.2.0/pre.003.md

@@ -0,0 +1,210 @@
+<!-- file: deltas/0.2.0/pre.003.md -->
+<!-- version: 2 -->
+
+# Delta `0.2.0-pre.003`
+
+## Identité
+
+```text
+release : 0.2.0
+prerelease : pre.003
+identifiant de commit attendu : v0.2.0-pre.003
+workspace.package.version : 0.2.0-pre.3
+base : 0.2.0-pre.002
+```
+
+`pre.003` est la **dernière prerelease planifiée** de la release de cadrage `0.2.0`. Elle ne développe aucune capacité N2 runtime ; elle réalise l'audit de cohérence final demandé par le plan `007` avant `rel.001`.
+
+## Mission
+
+Auditer la base Git complète `0.2.0-pre.002`, éliminer les contradictions normatives/documentaires résiduelles, vérifier que les décisions bot3 utiles n'ont pas été perdues, compléter les fiches de releases `0.2.1+`, finaliser le prompt `0.2.1` et fournir une matrice de clôture durable.
+
+## Écarts détectés et corrigés
+
+### Collisions d'identifiants normatifs
+
+`docs/rules/RULES_KSP.md` utilisait deux fois :
+
+```text
+KSP-TRANSPORT-001
+KSP-DATA-001
+KSP-DATA-002
+```
+
+Correction :
+
+```text
+KSP-TRANSPORT-001  reste : pas de ksp-onchain-transport-api séparée
+KSP-TRANSPORT-006  devient : couverture documentaire exhaustive + warnings de statut
+KSP-DATA-001/002   restent : contrats de notifications de données
+KSP-FLOW-001/002   deviennent : progression RAW/CORE/DECODE/SPECIALIZED + satellites de protocole
+```
+
+Un audit automatique des IDs normatifs ne trouve plus de doublon après correction.
+
+### Replay jobs historiques encore figés
+
+`KSP-JOB-009` imposait encore :
+
+```text
+ksp-job-replay-core
+ksp-job-replay-generic-materialization
+ksp-job-replay-domain-projection
+```
+
+Cette règle contredisait la progression verticale fixée par `pre.002`.
+
+La nouvelle règle ne fige plus de jobs DECODE/SPECIALIZED globaux. Un replay Core pourra être introduit avec CORE ; à partir de DECODE, les jobs de replay émergent avec les groupes/capacités réels et réutilisent la même logique que le processing live correspondant.
+
+Les entrées `IDEAS.md` basées sur `generic-materialization`, `domain-projection` et un type global `DomainProjector` sont requalifiées en conséquence.
+
+### Diagramme global W1–W4 encore actif
+
+`docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md` conservait encore :
+
+```text
+W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4
+```
+
+Ce schéma pouvait contredire la décision de `pre.002` en suggérant quatre workers globaux imposés. Il est remplacé par les frontières durables `D1 RAW -> D2 CORE -> D3 DECODE -> D4 SPECIALIZED`, avec workers RAW/CORE horizontaux et workers/processors DECODE/SPECIALIZED introduits need-driven par groupe vertical.
+
+### TODO Wallet bot3 incomplets dans KSP
+
+L'audit du TODO/matrice Wallet bot3 montre que KSP avait conservé Solana CLI/Base58/Phantom/Solflare mais avait trop résumé plusieurs reports utiles.
+
+`IDEAS.md` conserve maintenant explicitement :
+
+- Solflare Keystore, seulement avec format suffisamment stable/testable ;
+- Backpack, après caractérisation exacte du wire Solana `Private key` ;
+- Trust Wallet, après caractérisation du wire Solana exact ;
+- Base app / ex-Coinbase Wallet, sans synthèse de recovery phrase ;
+- distinction entre Base app et Coinbase Developer Platform.
+
+Ces entrées restent des idées/TODO, pas des dépendances ni engagements de `0.2.2`.
+
+### Fiches de release manquantes
+
+Le prompt d'ouverture `0.2.0` exigeait pour chaque release `0.2.1+` :
+
+```text
+mission
+périmètre
+hors-périmètre
+dépendances
+critères de clôture
+estimation souple des prereleases
+```
+
+`pre.002` avait fixé la séquence mais n'avait pas regroupé ces six dimensions pour chaque release.
+
+`docs/plans/007-V0_2_0_SERIES_PLANNING.md` contient maintenant une fiche pour `0.2.1` à `0.2.10`.
+
+## Spot-check HTTP Solana
+
+Un contrôle externe daté du **2026-08-17** a été effectué uniquement pour valider le sizing et la qualité du prompt `0.2.1` :
+
+- l'index officiel HTTP Solana observé contient 52 méthodes courantes ;
+- la section officielle `Deprecated Methods` expose séparément 14 noms ;
+- l'inventaire bot3 `ks-onchain-transport/src/standard_methods.rs` contient les 52 noms courants observés ;
+- bot3 ne couvre pas ces 14 anciennes méthodes deprecated comme surface standard ;
+- l'égalité des noms courants ne garantit pas un contrat équivalent, bot3 distinguant notamment typed adapters et appels raw JSON.
+
+Ces nombres ne deviennent pas une règle durable. `0.2.1-pre.001` doit refaire l'inventaire depuis la documentation officielle du jour et vérifier la disponibilité runtime des méthodes deprecated/obsolete avant de promettre leur support.
+
+## Prompt `0.2.1`
+
+`prompts/006-V0_2_1_START_PROMPT.md` passe en version 2 et est considéré **finalisé côté contenu** pour l'ouverture de `0.2.1` après `v0.2.0` stable.
+
+Il impose maintenant explicitement :
+
+- index HTTP courant ;
+- section officielle `Deprecated Methods` séparée ;
+- toute surface HTTP unstable/experimental officiellement documentée ;
+- vérification de disponibilité runtime des méthodes deprecated/obsolete ;
+- comparaison nom par nom avec bot3 ;
+- distinction du niveau de contrat bot3 `typed` vs raw/generic ;
+- gate de sizing avant implémentation lourde.
+
+## Matrice de clôture ajoutée
+
+Nouveau document :
+
+```text
+docs/validation/002-V0_2_0_SERIES_PLANNING.md
+```
+
+Il trace les critères du prompt `0.2.0`, les preuves documentaires, les écarts trouvés par `pre.003`, le spot-check HTTP et les conditions permettant de passer à `rel.001`.
+
+## Fichiers modifiés
+
+```text
+Cargo.toml
+ROADMAP.md
+docs/000-README.md
+docs/IDEAS.md
+docs/architecture/000-README.md
+docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
+docs/plans/000-README.md
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/plans/007-V0_2_0_SERIES_PLANNING.md
+docs/rules/RULES_KSP.md
+docs/validation/000-README.md
+prompts/000-README.md
+prompts/006-V0_2_1_START_PROMPT.md
+```
+
+## Fichiers ajoutés
+
+```text
+docs/validation/002-V0_2_0_SERIES_PLANNING.md
+deltas/0.2.0/pre.003.md
+```
+
+## Validation statique réalisée dans l'environnement d'échange
+
+- parsing TOML de `Cargo.toml` ;
+- `workspace.package.version = 0.2.0-pre.3` ;
+- audit d'unicité des IDs normatifs sous `docs/rules/` ;
+- contrôle des en-têtes `<!-- file: ... -->` / versions des fichiers modifiés ;
+- contrôle des fences Markdown équilibrées ;
+- contrôle des liens Markdown locaux, en ignorant les exemples littéraux de syntaxe Markdown ;
+- scan global des headers Markdown : un ancien delta livré `deltas/0.1.4/pre.016-fix.002.md` ne possède pas le header moderne ; il est volontairement laissé intact afin de ne pas réécrire silencieusement l'historique `0.1.4` ;
+- recherche des anciennes décisions actives `replay-generic-materialization` / `replay-domain-projection` / `DomainProjector` ;
+- recherche des diagrammes/contrats pouvant encore imposer mécaniquement un worker global par niveau D1–D4 ;
+- comparaison ciblée avec les TODO Wallet et l'inventaire HTTP de bot3 ;
+- spot-check de la documentation officielle Solana actuelle pour HTTP et Deprecated Methods.
+
+## Validations non exécutables dans cet environnement
+
+Le conteneur d'échange ne fournit ni `cargo` ni `rustc`.
+
+Avant commit de `pre.003`, exécuter sur le dépôt canonique :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+```
+
+Aucun build Tauri n'est requis par cette tranche documentaire : aucune application/frontend/runtime Tauri n'est modifié.
+
+## Commit attendu
+
+Après application et validations :
+
+```text
+v0.2.0-pre.003
+```
+
+Aucun tag Git stable n'est créé pour cette prerelease.
+
+## Suite
+
+Si les validations de `pre.003` sont propres, la prochaine livraison doit être :
+
+```text
+0.2.0-rel.001
+```
+
+`rel.001` doit rester minimal : version stable `0.2.0`, statuts documentaires, entrée `CHANGELOG`, delta final, validations globales, commit de release puis tag `v0.2.0`.

deltas/0.2.0/rel.001.md

@@ -0,0 +1,118 @@
+<!-- file: deltas/0.2.0/rel.001.md -->
+<!-- version: 1 -->
+
+# Delta `0.2.0-rel.001` — publication stable du cadrage `0.2.x`
+
+## Base validée
+
+La base requise est le commit :
+
+```text
+e721464a7c2cbf4c564757061a2a44dd7913facb
+v0.2.0-pre.003
+```
+
+Le user a communiqué le 2026-08-17 les validations suivantes avec succès :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+`cargo test --workspace` exécute 241 tests avec succès ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement ignoré. `git diff --check` et `git status --short` ne produisent aucune sortie après le commit `pre.003`.
+
+## Objet
+
+Publier sous version stable le cadrage `0.2.0` déjà audité et validé, sans ajouter de capacité N2 ni modifier les décisions architecturales finalisées en `pre.003`.
+
+## Changements
+
+- `workspace.package.version` passe de `0.2.0-pre.3` à `0.2.0` ;
+- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
+- `ROADMAP.md` marque `0.2.0` et `0.2.0-pre.003` réalisés et enregistre `rel.001` ;
+- l'index documentaire marque `007-V0_2_0_SERIES_PLANNING.md` comme plan historique clôturé ;
+- la séquence fonctionnelle enregistre `0.2.0` stable et `0.2.1` comme prochaine release ;
+- le plan `007` enregistre sa clôture par `rel.001` ;
+- la matrice `docs/validation/002-V0_2_0_SERIES_PLANNING.md` enregistre les preuves opérateur finales de `pre.003` ;
+- le prompt `prompts/006-V0_2_1_START_PROMPT.md` reste inchangé et devient le point d'entrée de la prochaine release après création du tag stable.
+
+## Surface stable publiée
+
+`0.2.0` stabilise notamment :
+
+- l'ordre fonctionnel de `0.2.1+` : HTTP Solana -> Wallet -> Wallet Desk -> WebSocket standard -> Helius LaserStream WebSocket -> Yellowstone gRPC standard -> off-chain prix -> app prix -> Interface -> Program API ;
+- `ksp-onchain-transport-lib` indépendant de `ksp-config-lib`, Store et Program, avec settings publics propres au transport et adapter Config -> Transport ;
+- la règle de couverture exhaustive des méthodes/opérations documentées pour chaque surface Transport ciblée ;
+- la conservation des méthodes deprecated/obsolete encore fonctionnelles avec warning KSP, et le warning KSP des méthodes unstable/experimental ;
+- la progression durable `RAW -> CORE -> DECODE -> SPECIALIZED` ;
+- RAW et CORE sans decoder Program, complétés horizontalement avec persistence/replay/jobs/workers/apps selon besoin ;
+- à partir de DECODE, des vertical slices groupe par groupe : wire -> decode -> materialize -> specialized -> prepare -> policy -> execute -> scenario Devnet ;
+- l'intégration des composants satellites dans leur groupe protocolaire, par exemple Meteora vaults avec Meteora et Pump fees avec Pump ;
+- la priorité Solana Core -> SPL token/trading -> metadata token -> Anchor -> Meteora/Raydium/Pump/Orca -> Market Desk V1 -> Jupiter/OKX -> Market Desk V2 -> trading-adjacent -> décodage généraliste ;
+- le gate de sizing : une prerelease vise environ 15–20 minutes et une release concrète doit rester clôturable dans une seule session de chat, sinon elle est redécoupée avant l'implémentation lourde.
+
+## Hors périmètre
+
+`0.2.0-rel.001` ne modifie pas :
+
+- les crates Rust hors signal de version workspace ;
+- `ksp-app-config-desk` runtime/frontend ;
+- les versions `package.json` / `tauri.conf.json` de Config Desk ;
+- les dépendances Cargo ;
+- les contrats publics existants ;
+- la configuration runtime ;
+- le prompt `0.2.1` finalisé par `pre.003`.
+
+Aucune nouvelle fonctionnalité N2 n'est introduite.
+
+## Version technique
+
+```text
+workspace.package.version = "0.2.0"
+```
+
+## Validation de `rel.001`
+
+Le delta modifie `Cargo.toml` et de la documentation, sans fichier Rust ni frontend/Tauri. Avant publication/tag, exécuter :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+Aucun `cargo tauri build` n'est requis : la version Tauri de `ksp-app-config-desk` reste `0.1.4` et aucun fichier de l'application n'est modifié par cette publication.
+
+## Commit et tag
+
+Après validation de `rel.001` :
+
+```text
+commit : v0.2.0-rel.001
+tag    : v0.2.0
+```
+
+Seul le tag stable `v0.2.0` est attendu.
+
+## Suite
+
+Après création du tag `v0.2.0`, ouvrir :
+
+```text
+0.2.1-pre.001
+```
+
+avec :
+
+```text
+prompts/006-V0_2_1_START_PROMPT.md
+```
+
+`0.2.1` commence par audit de la documentation Solana HTTP actuelle, audit du transport bot3, matrice exhaustive des méthodes et gate de sizing avant toute implémentation fonctionnelle lourde.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 16 -->
+<!-- version: 20 -->
 
 # Documentation KSP
 
@@ -38,10 +38,12 @@ docs/
 │   ├── 003-V0_1_1_CORE_FOUNDATION_PLAN.md
 │   ├── 004-V0_1_2_LOGGING_FOUNDATION_PLAN.md
 │   ├── 005-V0_1_3_CONFIG_FOUNDATION_PLAN.md
-│   └── 006-V0_1_4_CONFIG_DESKTOP_PLAN.md
+│   ├── 006-V0_1_4_CONFIG_DESKTOP_PLAN.md
+│   └── 007-V0_2_0_SERIES_PLANNING.md
 ├── validation/
 │   ├── 000-README.md
-│   └── 001-V0_1_4_CONFIG_DESKTOP.md
+│   ├── 001-V0_1_4_CONFIG_DESKTOP.md
+│   └── 002-V0_2_0_SERIES_PLANNING.md
 └── rules/
     ├── FILE_CONTRACTS.md
     ├── PROMPT_STRUCTURE.md
@@ -58,7 +60,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 prochaine session est `0.2.0-pre.001`, ouverte par [`../prompts/005-V0_2_0_START_PROMPT.md`](../prompts/005-V0_2_0_START_PROMPT.md).
+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 prochaine release fonctionnelle est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, à ouvrir avec [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md).
 
 `IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.
 

docs/IDEAS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDEAS.md -->
-<!-- version: 15 -->
+<!-- version: 17 -->
 
 # Idées à explorer
 
@@ -70,6 +70,14 @@ Définir avec les premières APIs réelles les conventions de nommage des traits
 
 Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades `lib.rs`, modules API et réexports publics.
 
+### API Interface séparée
+
+**Status :** Rejetée pour l'instant
+
+`ksp-interface-lib` expose sa propre API publique wire afin que des crates Program externes puissent expérimenter contre les mêmes contrats que les implementations officielles.
+
+Ne créer `ksp-interface-api` que si un futur problème réel de graphe de dépendances, de poids d'implémentation ou de publication démontre qu'un contrat séparé est nécessaire. La symétrie avec `ksp-program-api` n'est pas une justification suffisante.
+
 ## Transport
 
 ### Modèles homogènes on-chain
@@ -94,17 +102,44 @@ Réévaluer seulement si les premières implémentations montrent une duplicatio
 
 `ksp-offchain-transport-lib` regroupe metadata, prix, quotes, routage et autres accès externes afin d'éviter une explosion de crates. Il n'est pas nécessaire de leur inventer une API métier commune.
 
+### Pool automatique de sessions WebSocket
+
+**Status :** À explorer après `0.2.4`
+
+Le contrat WebSocket doit autoriser plusieurs sessions physiques sur une même URL, chaque session portant plusieurs subscriptions.
+
+Ne pas implémenter automatiquement un scheduler/pool de sessions tant qu'un besoin réel de distribution de charge, quotas provider, isolation de flux ou reconnexion indépendante ne le justifie pas.
+
+### Providers Yellowstone avancés
+
+**Status :** À explorer après la fondation standard
+
+Candidats à intégrer ultérieurement par adapters/capabilities sans dupliquer le client Yellowstone générique :
+
+- Helius LaserStream gRPC ;
+- Triton One / Dragon's Mouth ;
+- ERPC ;
+- Chainstack ;
+- Shyft ;
+- autres providers compatibles réellement utiles.
+
+Le choix dépendra des capacités, quotas, replay, authentification, prix et besoins opérationnels au moment de leur introduction.
+
+### Streaming pré-exécution / shreds
+
+**Status :** À explorer plus tard
+
+Conserver comme pistes séparées les offres pré-exécution/shred/deshred (Helius Shred Delivery, Triton/Yellowstone deshred, Shyft RabbitStream ou équivalents). Leur sémantique n'est pas identique à un flux exécuté Yellowstone standard et elles ne doivent pas être ajoutées comme simples aliases provider sans audit.
+
 ## Workers et jobs
 
 ### Workers de processing
 
-**Status :** Retenue
+**Status :** Retenue, granularité révisée
 
-Après `ksp-worker-raw-retriever`, les responsabilités de processing actuellement prévues sont séparées :
+RAW et CORE peuvent disposer de workers dédiés à la fin de leur couche respective.
 
-- `ksp-worker-core-processor` ;
+À partir de DECODE, ne pas figer à l'avance une chaîne globale `generic-materializer -> domain-projector` pour tout Solana : la granularité des workers/processors doit émerger des vertical slices Program réels et réutiliser les mêmes transformations que les jobs de replay correspondants.
-- `ksp-worker-generic-materializer` ;
-- `ksp-worker-domain-projector` (nom provisoire).
 
 ### Worker control
 
@@ -145,6 +180,28 @@ Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage d
 
 Un wallet web/online utilisant les contrats KSP est envisagé. La gestion des secrets et le modèle de confiance devront être traités comme une question architecturale majeure avant développement.
 
+### Formats Wallet import/export supplémentaires
+
+**Status :** À explorer avec `0.2.2` et après
+
+Le format natif KSP est `.kspwallet`. L'architecture d'import/export doit rester extensible, mais seules les conversions réellement nécessaires sont implémentées immédiatement.
+
+Formats/cibles à inventorier et prioriser selon usage réel :
+
+- Solana CLI keypair JSON ;
+- keypair Base58 complet lorsque pertinent ;
+- Phantom, en privilégiant le wire Solana générique réellement documenté plutôt qu'un codec de marque inutile ;
+- Solflare, y compris réévaluation du keystore protégé seulement si son format public devient suffisamment stable pour un round-trip testé ;
+- Backpack : caractériser le wire Solana exact de l'import `Private key` avant tout codec/alias dédié ;
+- Trust Wallet : caractériser le wire Solana exact d'import/export avant implémentation ;
+- Base app / ex-Coinbase Wallet : ne jamais synthétiser une recovery phrase depuis une keypair arbitraire ; réévaluer uniquement si un import direct de keypair Solana est officiellement spécifié ;
+- distinguer Coinbase Developer Platform d'un wallet utilisateur Base/Coinbase si son API d'import/export est étudiée ;
+- autres wallets logiciels Solana ;
+- hardware wallets / standards de dérivation si un besoin apparaît ;
+- migrations depuis formats historiques KSP/bot uniquement si utiles aux utilisateurs réels.
+
+Chaque format doit être étudié côté sécurité, round-trip, secret/public, dépendances et compatibilité avant engagement.
+
 ## Pipelines
 
 ### Pas de pipeline monolithique
@@ -234,9 +291,9 @@ Les processing outcomes par processor/version/capability constituent la vérité
 
 ### Jobs de replay
 
-**Status :** Transférée vers une décision/règle
+**Status :** Requalifiée par `0.2.0-pre.003`
 
-Trois jobs distincts sont retenus : `ksp-job-replay-core`, `ksp-job-replay-generic-materialization` et `ksp-job-replay-domain-projection`. Ils réutilisent les pipelines spécialisés correspondants.
+L'ancienne liste figée `ksp-job-replay-core` / `ksp-job-replay-generic-materialization` / `ksp-job-replay-domain-projection` n'est plus une décision KSP. La frontière `RAW -> CORE` pourra introduire un replay Core lorsque CORE sera ouverte. À partir de DECODE, les jobs de replay doivent émerger avec les groupes/capacités verticaux réels et réutiliser la même logique que le processing live correspondant, sans imposer un materializer/projector global à tout Solana.
 
 ### Notification backend de référence
 
@@ -258,11 +315,11 @@ Définir le schéma SQL, la durée/renouvellement de lease et la technique Postg
 
 Fixer les noms/types exacts et distinguer Produced, NoOutput, NotApplicable, Unsupported et failure déterministe sans transformer des situations normales en erreurs.
 
-### Contexte stateful des projectors
+### Contexte stateful des projections SPECIALIZED
 
 **Status :** À explorer avec la première projection nécessitant un état existant
 
-Le Store est interrogé par le pipeline/worker puis le contexte est injecté au `DomainProjector`. Définir comment le projector décrit les données de contexte nécessaires sans dépendre du backend.
+Le Store est interrogé par la couche de composition/pipeline/worker puis le contexte est injecté dans l'implémentation de projection/materialization spécialisée concernée. Définir comment cette capacité décrit les données de contexte nécessaires sans dépendre du backend, sans imposer un type global `DomainProjector`.
 
 ### Job pause/resume
 
@@ -276,6 +333,24 @@ Checkpoint/restart est nécessaire pour backfill/replay. Déterminer si pause/re
 
 Backlog count, oldest pending age, processing rate et failure rate doivent être observables. Décider plus tard si health/status + logging suffisent ou si une API/metrics exporter dédiée devient nécessaire.
 
+### Market Desk évolutive
+
+**Status :** Transférée au roadmap
+
+Introduire une première `ksp-app-market-desk` après les groupes DEX prioritaires Meteora/Raydium/Pump/Orca, puis l'enrichir après Jupiter/OKX.
+
+Pistes futures au-delà de la V1/V2 :
+
+- profondeur/market microstructure si les sources le permettent ;
+- indicateurs dérivés ;
+- alertes/anomalies ;
+- overlays de risk ;
+- outputs XGBoost/ML ;
+- comparaison de providers/latence ;
+- vues replay historiques.
+
+Ces extensions restent séparées de l'application de trading opérationnel tant que leur responsabilité est l'observation/analyse.
+
 ## Applications et orchestration futures
 
 ### Application globale de contrôle/exploitation
@@ -318,8 +393,8 @@ Si cette capacité devient utile, l’intégration doit être conçue dans la pi
 
 ### Numérotation fine après `0.1.x`
 
-**Status :** À décider à l'approche de chaque série
+**Status :** Transférée au roadmap pour le début de `0.2.x`
 
-`0.1.1` et `0.1.2` sont fixées ; `0.1.3` / `0.1.4` constituent la séquence par défaut sous réserve d'une éventuelle scission de Config.
+`0.2.0-pre.002` fixe désormais le début concret `0.2.1 -> 0.2.10` sous réserve du gate de dimensionnement de chaque `pre.001`.
 
-Pour `0.2.x+`, ne pas attribuer prématurément un numéro précis à chaque composant. L'ordre candidat est documenté dans `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` et sera converti en releases concrètes lorsque les dépendances et premiers cas d'usage de la série seront connus.
+Les séries après RAW/CORE ne sont volontairement pas numérotées programme par programme à ce stade : la règle est de redécouper chaque vertical slice selon sa taille réelle et de ne jamais ouvrir une release qui ne peut pas être clôturée dans sa session.

docs/architecture/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/000-README.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Architecture KSP
 
@@ -26,6 +26,6 @@ Ils ne remplacent ni `ROADMAP.md`, ni les plans de version, ni les deltas.
 7. [`007-EXECUTION_AND_POLICY.md`](007-EXECUTION_AND_POLICY.md) — policy multi-checkpoints, orchestration transactionnelle, wallet/transport, retry, approval externe et résultat d'exécution ;
 8. [`008-DATA_MATERIALIZATION_AND_STORE.md`](008-DATA_MATERIALIZATION_AND_STORE.md) — niveaux durables D1–D4, Materialization, Store PostgreSQL de référence, provenance, idempotence, replay et notifications de données persistées ;
 9. [`009-ACQUISITION_WORKERS_AND_JOBS.md`](009-ACQUISITION_WORKERS_AND_JOBS.md) — pipelines spécialisés, workers live, jobs de backfill/replay, backlog, claim/lease, reprise, concurrence et mécanisme de notification de référence ;
-10. [`010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`](010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md) — apps spécialisées, workers autonomes, control plane, scenarios réutilisables, demos desktop et frontières IPC/orchestration.
+10. [`010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`](010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md) — apps spécialisées, workers autonomes et need-driven, control plane, scenarios réutilisables, demos desktop et frontières IPC/orchestration.
 
 `004-COMPONENT_INVENTORY.md` et `005-DEPENDENCY_GRAPH.md` sont maintenus ensemble : une évolution du graphe qui change le propriétaire d'une responsabilité doit corriger l'inventaire au lieu de laisser deux descriptions contradictoires.

docs/architecture/002-LAYERS_AND_DEPENDENCIES.md

@@ -1,202 +1,201 @@
 <!-- file: docs/architecture/002-LAYERS_AND_DEPENDENCIES.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Couches et dépendances KSP
 
-## Rôle des niveaux
+## Rôle des niveaux architecturaux
 
-Les niveaux N1 à N4 servent à raisonner sur les responsabilités, la stabilité et le sens des dépendances. Ils ne constituent pas une chaîne d'appels obligatoire.
+Les niveaux architecturaux N1–N4 décrivent les familles de composants du projet. Ils ne doivent pas être confondus avec les niveaux durables D1–D4.
 
-Les niveaux durables de données utilisent une nomenclature distincte **D1 à D4** afin de ne jamais être confondus avec les couches architecturales N1 à N4 : D1 Raw, D2 Core canonique, D3 journal de matérialisation générique et D4 projections spécialisées.
+### N1 — Fondations communes
 
-Une couche supérieure peut dépendre directement d'une bibliothèque KSP plus basse lorsque cette bibliothèque est exactement la propriétaire de la capacité recherchée.
+- `ksp-core-lib` ;
+- `ksp-logging-lib` ;
+- `ksp-config-lib` ;
+- premières règles/outils transversaux.
 
-## N1 — Fondations
+### N2 — Capacités Solana réutilisables
-
-N1 contient les contrats et services transversaux qui doivent rester bas dans le graphe de dépendances.
-
-Positionnement actuellement retenu :
-
-- `ksp-core-lib` — primitives et contrats fondamentaux réellement transversaux, type d'erreur commun KSP et responsabilité autrefois séparée des identifiants de programmes ;
-- `ksp-interface-lib` — façade KSP des interfaces/wire on-chain nécessaires aux autres bibliothèques ;
-- `ksp-config-lib` — contrats, chargement/résolution et manipulation autorisée de la configuration et des profils ;
-- `ksp-logging-lib` — façade commune de logging/tracing, propriétaire de l'initialisation et des dépendances directes `tracing`, `tracing-appender` et `tracing-subscriber`.
-
-`ksp-logging-lib` peut dépendre de `ksp-core-lib` pour le contrat commun `Error` / `Result`. La relation inverse n'est pas requise : `ksp-core-lib` reste sans dépendance logging tant qu'aucun besoin réel ne la justifie.
-
-Les crates KSP contenant du comportement/runtime peuvent dépendre directement de `ksp-logging-lib` afin de produire des logs structurés aux niveaux `error`, `warn`, `info`, `debug` et `trace`. Les crates `*-api` purement déclaratives n'ajoutent pas cette dépendance sans comportement réel à logger.
-
-Une bibliothèque N1 ne doit pas dépendre d'une fonctionnalité métier située dans une couche supérieure.
-
-## N2 — Capacités Solana
-
-N2 regroupe les capacités réutilisables opérant sur Solana au-dessus des fondations.
-
-Le nom `ksp-program-lib` est retenu pour la bibliothèque propriétaire du traitement des programmes : décodage et préparation technique d'opérations via `ProgramExecutionPreparer`. Elle doit s'appuyer sur `ksp-interface-lib` plutôt que faire porter les contrats wire aux applications.
-
-Les autres responsabilités N2 candidates comprennent notamment :
 
 - `ksp-onchain-transport-lib` ;
-- `ksp-offchain-transport-lib` lorsqu'un premier besoin réel justifiera son implémentation ;
+- `ksp-offchain-transport-lib` ;
-- `ksp-wallet-lib`.
+- `ksp-wallet-lib` ;
+- `ksp-interface-lib` ;
+- `ksp-program-api` puis implementations Program ;
+- `ksp-execution-policy-api` et orchestration d'exécution lorsqu'un vertical slice réel le justifie.
 
-Le transport off-chain est général : il ne se limite pas aux metadata et pourra servir à des ressources telles que metadata externes, prix de référence, services de routage ou autres données hors blockchain.
+### N3 — Données, jobs, workers et processing
 
-## N3 — Données et orchestration réutilisable
+- `ksp-store-api` / `ksp-store-lib` ;
+- `ksp-materializer-api` / implementations lorsque DECODE s'ouvre ;
+- `ksp-job-api` et jobs ;
+- `ksp-worker-api` et workers ;
+- processors/pipelines spécialisés réellement réutilisés.
 
-N3 doit accueillir les responsabilités qui interprètent, persistent ou orchestrent des capacités inférieures, notamment :
+### N4 — Exécutables
 
-- matérialisation ;
+- applications desk ;
-- stockage ;
+- services workers ;
-- replay/reconstruction ;
+- outils/jobs exécutables ;
-- pipelines ;
+- demos/scenarios ;
-- scénarios réutilisables ;
+- future orchestration globale.
-- contrôle/orchestration de workers lorsqu'il sera introduit.
 
-### W1
+## Chaîne durable indépendante des niveaux N1–N4
 
-W1 est un worker d'acquisition live/quasi-live uniquement.
+La chaîne de données canonique est :
-
-Il consomme au minimum les contrats de configuration, transport on-chain et stockage nécessaires pour :
-
-1. écouter les sources configurées ;
-2. rapatrier les données ;
-3. les persister sous forme raw ;
-4. notifier qu'une nouvelle information raw est disponible.
-
-W1 :
-
-- ne décode pas ;
-- ne matérialise pas ;
-- ne réalise pas de replay ;
-- ne décide pas de l'utilisation métier des données collectées ;
-- doit pouvoir faire évoluer à chaud ce qu'il écoute, rapatrie ou stocke selon les mécanismes de configuration/commande qui seront définis.
-
-Les notifications W1 servent de wake-up. Les workers/jobs downstream reconstruisent leur backlog depuis le Store et appliquent les pipelines spécialisés correspondant aux frontières D1 -> D2 -> D3 -> D4.
-
-### Workers de processing futurs
-
-Le processing continu n'est plus modélisé comme un unique W2. Il sépare `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector` afin de respecter les frontières durables D1 Raw -> D2 Core -> D3 journal de matérialisation générique -> D4 projections de domaine. Le lifecycle, backlog, claim/lease et replay sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
-
-## N4 — Exécutables
-
-N4 contient les applications, demos et workers.
-
-### Dépendances directes autorisées
-
-N4 n'est pas obligé de traverser N3 puis N2 pour atteindre N1.
-
-Exemples valides :
 
 ```text
-ksp-app-config-desk
+D1 RAW
-    └── ksp-config-lib
+  -> D2 CORE
-
+  -> D3 DECODE
-ksp-app-store-desk
+  -> D4 SPECIALIZED
-    ├── ksp-store-lib
-    └── ksp-config-lib
 ```
 
-Une application de configuration n'a aucune raison de dépendre de couches Solana qui ne participent pas à sa fonction.
+Aliases fonctionnels :
 
-Une application de store peut utiliser `ksp-config-lib` pour sélectionner/résoudre un profil et `ksp-store-lib` pour valider, initialiser ou reconstruire le stockage. Elle ne doit pas réimplémenter ces opérations ni appeler directement le backend propriétaire.
+```text
+RAW -> CORE -> DECODE -> SPECIALIZED
+```
 
-## Applications et demos
+RAW et CORE sont indépendants du décodage Program.
 
-Une application ou demo :
+CORE est une normalisation générique de Solana : structure des blocs, transactions, messages, comptes, instructions/CPI brutes, logs/meta et relations fondamentales.
 
-- recueille et présente les données ;
+Le premier decoder Program intervient seulement à `CORE -> DECODE`.
-- effectue les conversions/validations strictement liées à son interface ;
-- sélectionne les options, profils et scénarios autorisés ;
-- appelle les bibliothèques KSP propriétaires ;
-- affiche ou exporte les résultats.
 
-Elle ne doit pas réécrire :
+## Progression par couche
 
-- le décodage ;
+### RAW et CORE
-- la logique protocolaire ;
-- les PDA et layouts ;
-- la construction d'instructions ;
-- la matérialisation ;
-- les opérations de stockage ;
-- les scénarios réutilisables ;
-- les autres opérations appartenant à une bibliothèque inférieure.
 
-Lorsqu'une bibliothèque de scénarios possède déjà un workflow de démonstration, l'application demo doit l'appeler.
+Ces deux couches sont construites horizontalement.
 
-Les demos/scénarios doivent rester séparés par responsabilité fonctionnelle cohérente. Un regroupement n'est autorisé que lorsque plusieurs interfaces représentent réellement le même domaine fonctionnel.
+À la fin de chaque couche, KSP ajoute les composants d'exploitation nécessaires : persistence, replay/backfill, worker/service et application de contrôle lorsque utiles.
 
-Exemples actuellement retenus :
+### DECODE et SPECIALIZED
 
-- Memo : demo/scénarios séparés ;
+À partir du décodage, KSP progresse verticalement par groupe fonctionnel :
-- SPL Token classique : demo/scénarios séparés ;
-- Associated Token Account : demo/scénarios séparés ;
-- Token-2022 : demo/scénarios séparés ;
-- metadata d'assets/tokens : Metaplex Token Metadata et Token-2022 Metadata peuvent partager une même famille de demo/scénarios ;
-- Solana Program Metadata (SPM) reste séparé car il n'appartient pas à la même catégorie fonctionnelle.
 
-## Workers
+```text
+wire
+ -> decode
+ -> materialize
+ -> specialized projection si utile
+ -> execution preparation
+ -> policy
+ -> execute
+ -> scenarios
+```
 
-Les workers sont différents des interfaces utilisateur. Ils peuvent contenir l'orchestration runtime strictement nécessaire à leur responsabilité.
+Cela évite de développer tous les decoders avant les matérialisations et toutes les executions.
 
-Un worker doit néanmoins consommer les bibliothèques KSP propriétaires des contrats Solana et ne doit pas dépendre directement de crates Solana/protocoles externes.
+## Séparation maximale des dépendances
 
-Les premiers managers de workers sont spécialisés et séparés. Une application globale est un produit futur, tandis qu'un orchestrateur commun reste une abstraction à réévaluer seulement lorsqu'un besoin opérationnel concret le justifie.
+Chaque composant possède son contrat et reçoit explicitement les données nécessaires.
+
+Exemples structurants :
+
+```text
+ksp-onchain-transport-lib -X-> ksp-config-lib
+ksp-onchain-transport-lib -X-> ksp-store-api
+ksp-wallet-lib            -X-> ksp-onchain-transport-lib
+ksp-wallet-lib            -X-> execution policy
+ksp-interface-lib         -X-> ksp-program-api
+ksp-execution-lib         -X-> ksp-program-lib
+```
+
+La composition supérieure relie les composants.
+
+## Configuration
+
+`ksp-config-lib` est l'unique propriétaire des documents Config, `.env` et variables KSP/KSPB.
+
+Un composant ne dépend pas de Config pour être utilisable. Il expose des settings publics.
+
+Config peut fournir un document standard et un adapter vers ces settings lorsque cela devient utile :
+
+```text
+ksp-config-lib -> public settings du composant
+```
+
+sans dépendance inverse.
+
+## Logging
+
+`ksp-logging-lib` reste l'unique façade KSP de tracing runtime.
+
+Les crates comportant du comportement runtime peuvent en dépendre. Les crates `*-api` purement déclaratives n'ajoutent cette dépendance que si elles ont réellement un comportement à logger.
+
+## Applications
+
+Les applications Tauri restent minces :
+
+- DTOs applicatifs ;
+- composition de services KSP ;
+- lifecycle fenêtre/UI ;
+- instrumentation frontend ;
+- aucun déplacement de logique de transport, Wallet, Config, Program, Store ou Materializer dans Tauri.
+
+Des applications spécialisées sont ajoutées au fur et à mesure pour valider les couches : Config Desk, Wallet Desk, Price Desk, backfill/RAW tooling, CORE tooling puis Market Desk.
+
+## Workers et jobs
+
+Un worker est un service continu/autonome ; un job est borné/terminable.
+
+Ils utilisent des APIs lifecycle distinctes et ne s'appellent pas entre eux pour transférer les payloads du data plane.
+
+Le Store reste le point durable de synchronisation entre couches de processing.
 
 ## Firewall des dépendances externes
 
-Les exécutables KSP dépendent des bibliothèques KSP pour les capacités Solana.
+Les exécutables et couches supérieures n'importent pas directement les crates Solana/protocoles métier lorsqu'une façade KSP existe ou est prévue.
 
-```text
+Exceptions bas niveau explicitement autorisées restent limitées aux primitives stables décidées par les règles KSP.
-application / demo / worker
-            │
-            ▼
-       bibliothèques KSP
-            │
-            ▼
-primitives externes explicitement autorisées
-            │
-            ▼
-          Solana
-```
 
-Une dépendance externe Solana ou protocolaire doit être possédée par la bibliothèque KSP la plus basse et la plus cohérente avec sa responsabilité.
+`ksp-interface-lib` concentre les interfaces/wires officielles ou compatibles afin d'éviter les doublons de générations et les dépendances protocolaires dans les couches supérieures.
-
-## Sens des dépendances
-
-Le principe recherché est :
-
-```text
-N4 ───────► N3 / N2 / N1
-N3 ───────► N2 / N1
-N2 ───────► N1
-N1 ───────► fondations externes explicitement autorisées
-```
-
-Il n'est pas permis d'introduire une dépendance vers une couche supérieure pour résoudre localement un problème. Si cela semble nécessaire, le classement des responsabilités doit être réexaminé.
 
 ## Principe contract-first
 
-Les contrats minimaux entre couches doivent être définis suffisamment tôt pour que les composants futurs puissent se construire contre une frontière KSP stable, même lorsque l'implémentation complète arrive dans une version ultérieure.
+Une crate `*-api` est créée uniquement lorsque l'extension externe/backend/lifecycle exige un contrat séparé.
 
-Ce principe s'applique notamment aux futurs :
+Cas décidés :
 
-- decoders ;
+```text
-- `ProgramExecutionPreparer` / constructeurs d'opérations ;
+ksp-program-api
-- materializers ;
+ksp-materializer-api
-- store/repositories ;
+ksp-store-api
-- transports ;
+ksp-worker-api
-- scénarios ;
+ksp-job-api
-- notifications et contrôle des workers ;
+ksp-execution-policy-api
-- orchestrateur.
+```
 
-Il ne signifie pas qu'il faut implémenter prématurément toutes les fonctionnalités. Les interfaces/traits peuvent évoluer légèrement lorsque l'expérience révèle un besoin réel, mais une dépendance entre couches ne doit pas être remplacée par un couplage ad hoc sous prétexte que le contrat final n'existe pas encore.
+`ksp-interface-lib`, Wallet et transports conservent pour l'instant leurs APIs publiques dans leur bibliothèque d'implémentation.
+
+## Groupes Program prioritaires
+
+Après RAW/CORE :
+
+```text
+Solana Core Programs
+-> SPL token/trading
+-> token metadata
+-> Anchor
+-> Meteora
+-> Raydium
+-> Pump
+-> Orca
+-> Market Desk V1
+-> Jupiter/OKX routing
+-> Market Desk V2
+-> trading-adjacent
+-> general decoding
+```
+
+Un satellite nécessaire à un protocole reste dans son groupe : Pump fee avec Pump, Meteora vault avec Meteora, etc.
 
 ## Questions encore ouvertes
 
-- représentation interne exacte du type d'erreur commun KSP, à traiter dès `0.1.1-pre.001` ;
+- forme exacte des settings publics Transport ;
-- types publics précis de `ksp-program-api` et format ouvert/persistable des résultats décodés ;
+- nécessité future d'un pool automatique de sessions WebSocket ;
-- méthode de conformité wire contre les projets externes ;
+- split éventuel d'une API Interface séparée uniquement si un vrai besoin apparaît ;
+- contrats Rust exacts de Program/Materializer/Store ;
 - mécanisme IPC du premier manager de worker autonome ;
-- besoins de contexte des futurs `DomainProjector` stateful ;
+- granularité future des workers DECODE/SPECIALIZED par groupe.
-- nécessité réelle d'un orchestrateur commun lorsque plusieurs services/managers existeront.

docs/architecture/003-COMPONENT_CONTRACTS.md

@@ -1,30 +1,17 @@
 <!-- file: docs/architecture/003-COMPONENT_CONTRACTS.md -->
-<!-- version: 11 -->
+<!-- version: 6 -->
 
 # Contrats initiaux des composants KSP
 
 ## Objet
 
-Ce document enregistre les frontières déjà suffisamment claires pour guider la planification. Il ne définit pas encore les API Rust finales.
+Ce document synthétise les responsabilités des composants KSP. Les types Rust exacts restent définis au moment de leur première implémentation réelle.
-
-Le principe commun est de définir tôt les contrats nécessaires entre composants, puis d'enrichir les implémentations lorsque le besoin réel apparaît.
-
-L'inventaire détaillé courant est maintenu dans [`004-COMPONENT_INVENTORY.md`](004-COMPONENT_INVENTORY.md), le graphe autorisé/interdit dans [`005-DEPENDENCY_GRAPH.md`](005-DEPENDENCY_GRAPH.md), Wire/Program dans [`006-WIRE_AND_PROGRAM.md`](006-WIRE_AND_PROGRAM.md) Execution/Policy dans [`007-EXECUTION_AND_POLICY.md`](007-EXECUTION_AND_POLICY.md), Data/Materialization/Store dans [`008-DATA_MATERIALIZATION_AND_STORE.md`](008-DATA_MATERIALIZATION_AND_STORE.md) Acquisition/Workers/Jobs dans [`009-ACQUISITION_WORKERS_AND_JOBS.md`](009-ACQUISITION_WORKERS_AND_JOBS.md) et Apps/Services/Scenarios/Control dans [`010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`](010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md).
 
 ## Convention API / implémentation
 
-Lorsqu'un domaine doit exposer des contrats publics pouvant être implémentés indépendamment, KSP peut séparer :
+Une crate de contrats extensibles se nomme `ksp-<domain>-api`. Une implémentation réutilisable se nomme `ksp-<role>-lib`.
 
-```text
+Couples explicitement retenus :
-ksp-<domain>-api
-ksp-<domain>-lib
-```
-
-La crate `ksp-<domain>-api` est techniquement une bibliothèque Rust mais ne porte volontairement pas le suffixe `-lib`.
-
-Cette séparation n'est pas automatique. Elle est utilisée lorsqu'une vraie frontière d'extension/backend/lifecycle la justifie.
-
-Couples retenus :
 
 ```text
 ksp-program-api        / ksp-program-lib
@@ -32,185 +19,192 @@ ksp-materializer-api   / ksp-materializer-lib
 ksp-store-api          / ksp-store-lib
 ```
 
-APIs lifecycle retenues :
+Lifecycle APIs séparées :
 
 ```text
 ksp-worker-api
 ksp-job-api
+ksp-execution-policy-api
 ```
 
-Aucune API commune worker+job n'est prévue.
+Une crate `*-api` n'est jamais créée uniquement pour la symétrie des noms.
 
-## Execution policy
+## Core
 
-`ksp-execution-policy-api` est un contrat public de décision séparé de `ksp-program-lib`, du wallet, du transport et de l'UI.
+`ksp-core-lib` porte les primitives transversales réellement fondamentales, dont `Error`/`Result` et le registre KSP des Program IDs fondamentaux.
 
-Une exécution réelle via `ksp-execution-lib` reçoit explicitement une policy ; aucun fallback permissif implicite n'est prévu.
+Il ne devient pas une crate de modèles métier ou de transport.
-
-La policy peut être évaluée à plusieurs checkpoints afin d'intégrer des informations obtenues pendant le cycle, notamment le résultat de simulation.
-
-Une policy peut autoriser, refuser ou imposer des requirements ; elle ne réalise pas elle-même la simulation, la signature, le réseau ou une interaction Tauri.
-
-Les implémentations appartiennent aux crates de contexte appropriées : scenario Devnet, future bibliothèque d'application générale, future policy trading, etc.
-
-Aucune `ksp-execution-policy-lib` générique n'est prévue sans logique réellement commune.
-
-## Execution orchestration
-
-`ksp-execution-lib` consomme fondamentalement `PreparedProgramExecution` conforme à `ksp-program-api` et ne dépend pas de `ksp-program-lib`.
-
-Il orchestre :
-
-- policy checkpoints ;
-- assemblage message/transaction ;
-- simulation via `ksp-onchain-transport-lib` ;
-- résolution des signers et signature via `ksp-wallet-lib` ;
-- submission ;
-- confirmation ;
-- retry d'exécution lorsque celui-ci change le lifecycle ;
-- suspension/reprise lorsqu'une approbation externe est requise.
-
-Le wallet et le provider/réseau sont sélectionnés/fournis par la composition supérieure ; `ksp-execution-lib` les utilise sans définir une policy de sélection implicite.
-
-Le retry d'un appel réseau identique reste une responsabilité transport, distincte du retry d'exécution nécessitant reconstruction/resimulation/resignature.
-
-`ksp-execution-lib` ne persiste pas automatiquement son résultat et ne dépend pas du store.
 
 ## Logging
 
-`ksp-logging-lib` est la façade KSP unique pour le logging/tracing runtime. Elle importe/initialise directement `tracing`, `tracing-appender` et `tracing-subscriber` et peut dépendre de `ksp-core-lib` pour `Error` / `Result`.
+`ksp-logging-lib` est la façade unique KSP de tracing runtime.
 
-Les crates comportementales KSP utilisent sa façade pour leurs événements `error`, `warn`, `info`, `debug`, `trace` et pour leurs spans sync/async. Elles n'émettent pas leurs propres logs via une dépendance directe à la stack tracing.
+Les composants runtime émettent leurs événements via cette façade. Les targets tiers sont silencieux par défaut et les informations utiles sont réémises sous le target du composant KSP propriétaire.
 
-Chaque émission KSP indique un target correspondant au nom Cargo de la crate propriétaire ; `domain`, `component` et les autres champs structurés décrivent les subdivisions fonctionnelles sans multiplier les targets.
+## Config
 
-Le subscriber KSP rend les targets tiers silencieux par défaut. Lorsqu'une information provenant d'une dépendance externe est nécessaire, la crate KSP qui possède l'opération la réémet explicitement sous son propre target ; Logging ne renomme pas les événements tiers.
+`ksp-config-lib` est l'unique propriétaire des documents Config, `.env`, variables KSP/KSPB et persistence Config.
 
-Logging possède ses `LoggingSettings`, ses writers/guards et son lifecycle. Le subscriber global est installé une fois, puis la configuration peut être rechargée à chaud via la façade KSP sans dépendance vers Config.
+Les composants exposent leurs settings publics ; Config peut fournir un document standard et un adapter vers ces settings sans créer de dépendance inverse.
-
-`ksp-core-lib` n'a pas de dépendance logging requise. Les crates `*-api` purement déclaratives restent sans logging par défaut.
-
-Une application Tauri peut exceptionnellement avoir une dépendance/framework tracing imposée par un plugin, sans définir une politique parallèle à `ksp-logging-lib`; les événements KSP restent émis via la façade KSP.
-
-## Frontière materializer / store
-
-Les niveaux durables utilisent D1 Raw, D2 Core canonique, D3 journal de matérialisation générique et D4 projections spécialisées.
-
-`ksp-materializer-api` peut dépendre de `ksp-program-api` pour consommer des contrats Core ouverts. Il doit pouvoir distinguer conceptuellement une matérialisation générique D2 -> D3 et une projection spécialisée D3 -> D4.
-
-`ksp-materializer-lib` reste une bibliothèque de transformation et ne dépend ni de `ksp-store-api` ni de `ksp-store-lib`.
-
-`ksp-store-api` possède les DTO/contrats persistants et reste indépendant des APIs Program/Materializer. Les workers/jobs de processing convertissent explicitement entre modèles runtime et modèles persistants.
-
-D3 est un journal durable obligatoire ; D4 reste plus évolutif. Cette séparation évite d'introduire un `ksp-data-api` monolithique uniquement pour partager des modèles entre couches.
 
 ## Transport on-chain
 
 Aucune `ksp-onchain-transport-api` séparée n'est prévue.
 
-`ksp-onchain-transport-lib` regroupe les transports/providers on-chain et expose des modèles de sortie homogènes par catégorie de données.
+`ksp-onchain-transport-lib` possède :
 
-Il ne dépend pas de `ksp-store-api`.
+- settings runtime publics ;
+- endpoints/providers/clusters ;
+- pools/rôles/capabilities ;
+- HTTP JSON-RPC ;
+- WebSocket ;
+- Yellowstone gRPC et futurs adapters provider lorsque introduits ;
+- modèles homogènes par catégorie de donnée ;
+- observabilité transport.
 
-Les modèles de transport doivent cependant être conçus pour une conversion explicite et simple vers les modèles raw persistants du store, sans décodage protocolaire.
+Il ne dépend pas de Config, Store ou Program.
+
+Pour toute surface normative ciblée, toutes les méthodes documentées sont inventoriées/implémentées sauf impossibilité documentée. Les méthodes deprecated/obsolete encore fonctionnelles et unstable/experimental émettent un warning KSP à l'utilisation.
 
 ## Transport off-chain
 
 Aucune `ksp-offchain-transport-api` commune n'est prévue.
 
-La crate est volontairement hétérogène : metadata, prix, quotes, routage et autres ressources externes peuvent avoir des modules/APIs distincts à l'intérieur d'une seule crate afin d'éviter une prolifération de crates artificielles.
+`ksp-offchain-transport-lib` peut contenir plusieurs modules/APIs distincts : prix, metadata HTTP/IPFS/Arweave, quotes et autres accès externes. La première surface engagée est le prix SOL/USD et SOL/EUR.
 
 ## Wallet
 
-Aucune `ksp-wallet-api` n'est prévue.
+Aucune `ksp-wallet-api` séparée n'est prévue.
 
-`ksp-wallet-lib` possède le format wallet KSP et les capacités de lecture/protection/import/export/pubkey/secret/signature nécessaires à ses consommateurs.
+`ksp-wallet-lib` possède le format `.kspwallet`, le secret protégé, l'identité publique, signature, import/export et conversions utiles.
 
-## Store et notifications de données
+Il ne possède pas `WalletPolicy` ni les règles d'autorisation d'exécution.
 
-`ksp-store-api` reste la frontière backend-agnostic. `ksp-store-lib` contient PostgreSQL comme implémentation de référence.
+Le wallet temporaire JSON historique n'est pas migré.
 
-Les notifications de données persistées sont normalisées indépendamment de leur producteur. W1, un job de backfill, un import ou un replay utilisent le même contrat pour signaler le même type de donnée.
+## Interface / wire
 
-Une notification est seulement un signal de réveil : le Store et les marqueurs d'idempotence/backlog restent la source de vérité. La publication suit l'ordre `persist -> commit -> notify`.
+`ksp-interface-lib` est la façade wire officielle KSP et expose aussi une API publique wire réutilisable par `ksp-program-lib` et les extensions Program externes.
 
-Le contrat de notification est distinct de son transport concret.
+Aucune `ksp-interface-api` séparée n'est retenue actuellement.
+
+La crate sélectionne entre réexport contrôlé, wrapper ou implémentation wire compatible selon stabilité, ownership et graphe de dépendances des interfaces externes.
+
+## Program
+
+`ksp-program-api` porte les contrats extensibles de Program : descriptors/capabilities, decoders, outputs et préparation d'exécution lorsque ces contrats sont démontrés.
+
+`ksp-program-lib` porte les implementations officielles et dépend de `ksp-program-api`.
+
+Une crate externe peut implémenter `ksp-program-api` sans dépendre de `ksp-program-lib`.
+
+## Execution policy
+
+`ksp-execution-policy-api` est le contrat commun de décision/safety.
+
+Une policy décide ; elle ne signe pas, n'envoie pas et ne possède ni Wallet ni Transport.
+
+Une petite policy de scenario/orchestrateur peut être implémentée localement. Des bibliothèques communes sont créées uniquement si une réutilisation réelle apparaît.
+
+## Execution orchestration
+
+`ksp-execution-lib` est introduit lorsque le premier vertical slice réel nécessite une orchestration stable entre :
+
+```text
+ksp-program-api
+ksp-execution-policy-api
+ksp-wallet-lib
+ksp-onchain-transport-lib
+```
+
+Il ne dépend pas de `ksp-program-lib` afin d'accepter des implementations Program externes.
+
+## Store et niveaux durables
+
+La chaîne durable est :
+
+```text
+D1 RAW
+ -> D2 CORE
+ -> D3 DECODE
+ -> D4 SPECIALIZED
+```
+
+### RAW
+
+Acquisition replayable + provenance, sans décodage Program.
+
+### CORE
+
+Normalisation générique Solana, sans décodage Program.
+
+### DECODE
+
+Interprétation Program/protocole puis matérialisation générique/journal durable.
+
+### SPECIALIZED
+
+Projections queryables de domaine : token, metadata, pools, trades, OHLC, routes, etc.
+
+`ksp-store-api` possède les contrats backend-agnostic. `ksp-store-lib` fournit PostgreSQL comme backend officiel.
+
+La première Store release est RAW-only ; les couches suivantes sont ajoutées quand elles sont réellement ouvertes.
+
+## Materializer
+
+`ksp-materializer-api`/`ksp-materializer-lib` sont introduits avec le premier besoin DECODE réel, pas avant.
+
+Program et Materializer restent indépendants du backend Store ; les composants de composition convertissent leurs outputs vers les DTO persistants.
 
 ## Workers
 
-`ksp-worker-api` est une lifecycle API pour services continus/live.
+`ksp-worker-api` est la lifecycle API des services continus.
 
-`ksp-worker-control-lib` est une implémentation réutilisable de gouvernance pouvant être consommée d'abord par les applications manager spécialisées, puis éventuellement par un futur orchestrateur ou une future application globale.
+RAW et CORE peuvent recevoir leurs workers à la fin de leur couche respective.
 
-Workers retenus :
+Les workers DECODE/SPECIALIZED sont introduits avec les groupes Program réels, afin de ne pas créer une orchestration générique vide avant les processors.
-
-```text
-ksp-worker-raw-retriever
-ksp-worker-core-processor
-ksp-worker-generic-materializer
-ksp-worker-domain-projector
-```
-
-Le dernier nom reste provisoire.
-
-Chaque worker doit pouvoir fonctionner comme service/processus indépendant afin d'être arrêté, redémarré ou mis à jour sans imposer l'arrêt des autres. La direction de packaging préférée est un package `ksp-worker-*` avec cible bibliothèque réutilisable et binaire autonome mince.
-
-Les workers de processing utilisent le Store comme source de vérité du backlog, peuvent être réveillés par notification, et doivent pouvoir reprendre après crash. Le raw retriever possède en plus une capacité de hot reconfiguration de sa sélection d'acquisition.
 
 ## Jobs
 
-`ksp-job-api` est une lifecycle API distincte pour travaux déclenchés et terminables.
+`ksp-job-api` est la lifecycle API des travaux déclenchés/terminables.
 
-Jobs de données retenus :
+Le premier job retenu est le backfill RAW.
+
+Les jobs de replay suivent ensuite les frontières durables ouvertes : RAW -> CORE, CORE -> DECODE, DECODE -> SPECIALIZED.
+
+Aucune `ksp-job-control-lib` n'est prévue sans duplication concrète.
+
+## Scenarios
+
+Les scenarios restent dans `ksp-scenario-<domain>-lib` et sont appelables sans desktop.
+
+Ils composent les Program implementations, policy, Wallet, transport et execution nécessaires à leur vertical slice.
+
+L'application demo correspondante reste une UI mince.
+
+## Applications
+
+KSP privilégie des applications spécialisées servant à valider/exploiter une capacité réelle :
 
 ```text
-ksp-job-backfill
+ksp-app-config-desk
-ksp-job-replay-core
+ksp-app-wallet-desk
-ksp-job-replay-generic-materialization
+price desk
-ksp-job-replay-domain-projection
+backfill/raw tooling
+CORE tooling
+ksp-app-market-desk
 ```
 
-Les trois jobs de replay correspondent exactement aux frontières D1 -> D2, D2 -> D3 et D3 -> D4.
+Une application globale reste future.
 
-Aucune `ksp-job-control-lib` n'est prévue actuellement. D'autres jobs pourront apparaître pour metadata, quotes ou autres besoins ponctuels.
+## Progression verticale Program
 
-## Scénarios
+À partir de DECODE :
-
-Les scénarios restent dans des crates spécialisées `ksp-scenario-<domain>-lib`.
-
-`ksp-scenario-api` n'est pas retenu actuellement : `docs/rules/SCENARIO_CONVENTION.md` porte la norme commune tant qu'un vrai contrat Rust réutilisable n'a pas émergé.
-
-Les demos desktop de scénario suivent provisoirement la forme :
 
 ```text
-ksp-app-scenario-<domain>-<environment>-desk-demo
+wire -> decode -> materialize -> specialized -> prepare -> policy -> execute -> scenario
 ```
 
-et réutilisent la crate de scénario correspondante.
+Ordre prioritaire actuel : Solana Core Programs, SPL token/trading, token metadata, Anchor, Meteora, Raydium, Pump, Orca, routing, trading-adjacent, puis décodage généraliste.
 
-## Applications, services et control plane
+Un satellite nécessaire reste dans son groupe protocolaire.
-
-Les applications spécialisées sont développées avant toute application globale.
-
-Les apps restent des interfaces/compositions et ne réimplémentent pas les workflows des bibliothèques/services sous-jacents.
-
-Les workers sont des services autonomes et ne communiquent pas directement leurs données entre eux. D1–D4 constituent le data plane ; `ksp-worker-api`, `ksp-worker-control-lib`, `ksp-job-api` et le futur IPC constituent le control plane.
-
-Aucun `ksp-ipc-api` générique ni `ksp-orchestrator-lib` n'est retenu comme crate actuelle.
-
-Une future application globale est conservée comme idée produit, pas comme tâche du roadmap présent.
-
-## Pipelines
-
-Aucun `ksp-pipeline-lib` monolithique.
-
-Quatre pipelines spécialisés sont maintenant retenus parce qu'ils évitent de dupliquer une même frontière entre worker live et job :
-
-```text
-ksp-pipeline-raw-ingestion-lib
-ksp-pipeline-core-processing-lib
-ksp-pipeline-generic-materialization-lib
-ksp-pipeline-domain-projection-lib
-```
-
-Ils dépendent des APIs de domaine nécessaires, pas des implémentations officielles `ksp-store-lib`, `ksp-program-lib` ou `ksp-materializer-lib`. Les workers/jobs réalisent cette composition.

docs/architecture/004-COMPONENT_INVENTORY.md

@@ -1,344 +1,153 @@
 <!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
-<!-- version: 10 -->
+<!-- version: 6 -->
 
 # Inventaire initial des composants KSP
 
 ## Objet
 
-Ce document constitue le premier inventaire architectural de `0.0.3-pre.002`.
+Ce document maintient l'inventaire synthétique des composants retenus ou pressentis. Les numéros de release précis restent soumis au sizing de chaque session.
-
-Il répond principalement à la question : **quel composant possède quelle responsabilité ?**
-
-Le premier inventaire a été produit en `0.0.3-pre.002`. `pre.003` l'a corrigé à partir du graphe, puis `pre.004` a détaillé Wire/Program dans [`006-WIRE_AND_PROGRAM.md`](006-WIRE_AND_PROGRAM.md), `pre.005` Execution/Policy, `pre.006` les niveaux durables/Materialization/Store, `pre.007` l'exploitation workers/jobs/pipelines, `pre.008` Apps/Services/Scenarios/Control, puis `pre.009` le séquencement des premières releases fonctionnelles. La séquence détaillée est dans `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`. Les détails de types Rust restent révisables avec les premières implémentations.
 
 ## Statuts
 
-- **Retenu** — composant ou responsabilité considérée nécessaire dans la trajectoire actuelle ;
+- `Stable` — implémenté et publié ;
-- **Candidat fort** — composant très probable mais dont la frontière exacte doit encore être validée ;
+- `Retenu` — composant/contrat décidé ;
-- **Futur retenu** — responsabilité acquise mais implémentation différée ;
+- `Pressenti` — direction décidée mais périmètre exact à confirmer ;
-- **À la demande** — ne doit être créé que lorsqu'un premier besoin concret le justifie ;
+- `À la demande` — créé seulement au premier besoin réel ;
-- **Non retenu actuellement** — idée volontairement non créée ; elle peut être réévaluée si l'usage réel change.
+- `Non retenu` — explicitement écarté pour l'instant.
 
 ## Inventaire synthétique
 
-| Domaine                          | Composant                                   | Nature                  | Niveau provisoire | Statut                            | Première série envisagée          | Responsabilité principale                                                                                                                               |
+| Domaine                 | Composant                                | Type               | Statut       | Première cible actuelle         | Mission                                                  |
-|----------------------------------|---------------------------------------------|-------------------------|-------------------|-----------------------------------|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
+|-------------------------|------------------------------------------|--------------------|--------------|---------------------------------|----------------------------------------------------------|
-| Core                             | `ksp-core-lib`                              | lib                     | N1                | Retenu                            | `0.1.1`                           | `Error` commun, Program IDs, primitives/contrats réellement transversaux                                                                                |
+| Core                    | `ksp-core-lib`                           | lib                | Stable       | `0.1.1`                         | Error/Result, Program IDs et primitives fondamentales    |
-| Configuration                    | `ksp-config-lib`                            | lib                     | N1                | Retenu                            | `0.1.3` par défaut                | documents de configuration, profils, résolution, modifications autorisées                                                                               |
+| Logging                 | `ksp-logging-lib`                        | lib                | Stable       | `0.1.2`                         | façade unique tracing KSP                                |
-| Logging                          | `ksp-logging-lib`                           | lib                     | N1                | Retenu                            | `0.1.2`                           | façade unique `tracing`/appender/subscriber, initialisation et logging structuré KSP ; peut dépendre de core pour Error/Result                          |
+| Config                  | `ksp-config-lib`                         | lib                | Stable       | `0.1.3`                         | documents, profils, env et persistence Config            |
-| Config desktop                   | `ksp-app-config-desk`                       | app                     | N4                | Retenu                            | `0.1.4` par défaut                | app spécialisée Tauri validant chargement, profils, édition, sauvegarde, validation et diagnostics Config                                               |
+| Config Desk             | `ksp-app-config-desk`                    | app                | Stable       | `0.1.4`                         | validation/management Config                             |
-| Wire Solana                      | `ksp-interface-lib`                         | lib                     | N1                | Retenu                            | `0.2.x`                           | façade wire on-chain, réexports contrôlés et réimplémentations compatibles                                                                              |
+| On-chain HTTP           | `ksp-onchain-transport-lib`              | lib                | Retenu       | `0.2.1`                         | JSON-RPC HTTP complet, settings, pools, rôles            |
-| Program API                      | `ksp-program-api`                           | API                     | N2 contrat        | Retenu                            | `0.2.x`                           | contrats publics ouverts de décodage, préparation d'exécution, descriptors et registry                                                                  |
+| Wallet                  | `ksp-wallet-lib`                         | lib                | Retenu       | `0.2.2`                         | `.kspwallet`, secrets, signature, import/export          |
-| Program impl.                    | `ksp-program-lib`                           | lib                     | N2                | Retenu                            | `0.2.x+`                          | decoders et `ProgramExecutionPreparer` officiels organisés par domaine/programme/capacité                                                               |
+| Wallet Desk             | `ksp-app-wallet-desk`                    | app                | Retenu       | `0.2.3`                         | Wallet + Config composite + HTTP/balance                 |
-| Program extension                | `ksp-program-<name>-lib`                    | lib externe/optionnelle | N2                | À la demande                      | dès besoin                        | implémentation externe de `ksp-program-api` pour un Program ID non encore intégré officiellement                                                        |
+| Standard WS             | `ksp-onchain-transport-lib`              | lib                | Retenu       | `0.2.4`                         | WebSocket Solana complet, sessions/subscriptions         |
-| Execution policy                 | `ksp-execution-policy-api`                  | API                     | N3 contrat        | Retenu                            | premier besoin d'exécution réelle | policy obligatoire, multi-checkpoints, décision/requirements sans wallet/réseau/UI                                                                      |
+| Helius WS               | `ksp-onchain-transport-lib`              | lib                | Retenu       | `0.2.5`                         | LaserStream WebSocket comme extension du moteur standard |
-| Execution orchestration          | `ksp-execution-lib`                         | lib                     | N3                | Retenu                            | premier besoin d'exécution réelle | consomme `PreparedProgramExecution`; orchestre policy/simulation/signature/submission/confirmation/retry sans dépendre de `ksp-program-lib` ou du store |
+| Yellowstone             | `ksp-onchain-transport-lib`              | lib                | Pressenti    | `0.2.6`                         | client gRPC standard/provider-neutral                    |
-| Transport on-chain               | `ksp-onchain-transport-lib`                 | lib                     | N2                | Retenu                            | `0.2.x`                           | RPC/WS/providers et modèles de transport homogènes, sans dépendance store                                                                               |
+| Off-chain price         | `ksp-offchain-transport-lib`             | lib                | Retenu       | `0.2.7`                         | première abstraction/provider de prix SOL/USD, SOL/EUR   |
-| Transport off-chain              | `ksp-offchain-transport-lib`                | lib                     | N2                | Retenu, implémentation différable | premier besoin réel               | accès metadata, prix, quotes, routage et autres ressources hors blockchain                                                                              |
+| Price Desk              | nom à fixer                              | app                | Retenu       | `0.2.8`                         | visualisation/validation des prix                        |
-| Wallet                           | `ksp-wallet-lib`                            | lib                     | N2                | Retenu                            | `0.2.x`                           | format wallet KSP, lecture/protection/import/export, pubkey, secret/signature                                                                           |
+| Wire                    | `ksp-interface-lib`                      | lib                | Retenu       | `0.2.9`                         | façade wire officielle + API publique wire               |
-| Materializer API                 | `ksp-materializer-api`                      | API                     | N3 contrat        | Retenu                            | `0.3.x`                           | contrats publics/extensibles de matérialisation                                                                                                         |
+| Program API             | `ksp-program-api`                        | API                | Retenu       | `0.2.10`                        | contrats extensibles Program                             |
-| Materializer impl.               | `ksp-materializer-lib`                      | lib                     | N3                | Retenu                            | `0.3.x+`                          | materializers officiels KSP                                                                                                                             |
+| Program impl.           | `ksp-program-lib`                        | lib                | Retenu       | vertical slices ultérieurs      | implementations Program officielles                      |
-| Store API                        | `ksp-store-api`                             | API                     | N3 contrat        | Retenu                            | `0.3.x`                           | contrats backend-agnostic, modèles persistants et notifications de données persistées                                                                   |
+| Program extension       | `ksp-program-<name>-lib`                 | lib externe        | À la demande | dès besoin                      | implementation externe de `ksp-program-api`              |
-| Store impl.                      | `ksp-store-lib`                             | lib                     | N3                | Retenu                            | `0.3.x`                           | PostgreSQL de référence, migrations, repositories, queries, backlog/replay et notification backend                                                      |
+| Store API               | `ksp-store-api`                          | API                | Retenu       | `0.3.1`                         | contrats persistence backend-agnostic, RAW d'abord       |
-| Worker lifecycle                 | `ksp-worker-api`                            | API                     | N3 contrat        | Retenu                            | `0.3.x`                           | lifecycle commun des services continus                                                                                                                  |
+| Store PostgreSQL        | `ksp-store-lib`                          | lib                | Retenu       | `0.3.1`                         | backend PostgreSQL officiel, RAW d'abord                 |
-| Worker control                   | `ksp-worker-control-lib`                    | lib                     | N3                | Retenu                            | `0.3.x+`                          | gouvernance réutilisable de services workers autonomes pour apps spécialisées puis futurs managers/orchestrateurs                                       |
+| Job lifecycle           | `ksp-job-api`                            | API                | Retenu       | `0.3.3`                         | lifecycle des jobs terminables                           |
-| Live raw acquisition             | `ksp-worker-raw-retriever`                  | worker                  | N4                | Retenu                            | `0.3.x`                           | acquisition live/quasi-live -> raw persisté -> notification data                                                                                        |
+| Backfill                | `ksp-job-backfill`                       | job/lib à préciser | Retenu       | `0.3.3`                         | acquisition historique vers RAW                          |
-| Raw -> Core                      | `ksp-worker-core-processor`                 | worker                  | N4                | Futur retenu                      | `0.6.x`                           | transformer le raw persisté en Core canonique                                                                                                           |
+| Backfill Desk           | nom à fixer                              | app                | Retenu       | `0.3.4`                         | contrôle/inspection du backfill RAW                      |
-| Core -> generic mat.             | `ksp-worker-generic-materializer`           | worker                  | N4                | Futur retenu                      | `0.6.x`                           | produire la matérialisation/journal générique depuis le Core                                                                                            |
+| Worker lifecycle        | `ksp-worker-api`                         | API                | Retenu       | fin couche RAW                  | lifecycle des services continus                          |
-| Domain projection                | `ksp-worker-domain-projector`               | worker                  | N4                | Futur retenu, nom provisoire      | `0.6.x`                           | matérialiser/classer/stocker les projections spécialisées par domaine                                                                                   |
+| RAW worker              | `ksp-worker-raw-retriever` ou nom révisé | worker             | Retenu       | fin couche RAW                  | acquisition live vers RAW                                |
-| Job lifecycle                    | `ksp-job-api`                               | API                     | N3 contrat        | Retenu                            | `0.3.x`                           | lifecycle/progression commun des travaux déclenchés et terminables                                                                                      |
+| CORE processor          | nom à fixer                              | processor/lib      | Retenu       | couche CORE                     | normalisation Solana générique RAW -> CORE               |
-| Historical backfill              | `ksp-job-backfill`                          | job                     | N4                | Retenu                            | `0.3.x`                           | acquisition historique avec pagination, progression, checkpoint/reprise                                                                                 |
+| CORE worker             | nom à fixer                              | worker             | Retenu       | fin couche CORE                 | backlog RAW -> CORE continu                              |
-| Core replay                      | `ksp-job-replay-core`                       | job                     | N4                | Retenu                            | `0.3.x/0.6.x`                     | replay borné D1 -> D2 via le pipeline Core                                                                                                              |
+| Materializer API        | `ksp-materializer-api`                   | API                | Retenu       | premier groupe DECODE           | contrats extensibles matérialisation                     |
-| Generic materialization replay   | `ksp-job-replay-generic-materialization`    | job                     | N4                | Retenu                            | `0.3.x/0.6.x`                     | replay borné D2 -> D3 via le pipeline générique                                                                                                         |
+| Materializer impl.      | `ksp-materializer-lib`                   | lib                | Retenu       | premier groupe DECODE           | implementations officielles communes                     |
-| Domain projection replay         | `ksp-job-replay-domain-projection`          | job                     | N4                | Retenu                            | `0.3.x/0.6.x`                     | replay borné D3 -> D4 via le pipeline de projection                                                                                                     |
+| Execution policy        | `ksp-execution-policy-api`               | API                | Retenu       | premier vrai besoin execution   | décision/safety multi-contexte                           |
-| Other jobs                       | `ksp-job-<role>`                            | job                     | N4                | À la demande                      | `0.4.x+`                          | metadata, quotes et autres travaux ponctuels/historiques                                                                                                |
+| Execution orchestration | `ksp-execution-lib`                      | lib                | Retenu       | premier vrai cycle execution    | Program + policy + Wallet + transport                    |
-| Scenarios                        | `ksp-scenario-<domain>-lib`                 | lib                     | N3                | Retenu                            | `0.4.x+`                          | scénarios de validation spécialisés par domaine                                                                                                         |
+| Scenarios               | `ksp-scenario-<domain>-lib`              | lib                | Retenu       | vertical slices                 | validation métier/devnet par groupe                      |
-| Scenario common API              | `ksp-scenario-api`                          | API                     | —                 | Non retenu actuellement           | —                                 | préférer une norme de scénario souple plutôt qu'un trait commun contraignant                                                                            |
+| Scenario API            | `ksp-scenario-api`                       | API                | Non retenu   | —                               | norme souple avant trait commun                          |
-| Scenario demo apps               | `ksp-app-scenario-<domain>-<env>-desk-demo` | app                     | N4                | Retenu                            | `0.4.x+`                          | interface desktop appelant la crate scénario correspondante                                                                                             |
+| Market Desk             | `ksp-app-market-desk`                    | app                | Pressenti    | après Meteora/Raydium/Pump/Orca | tokens, pools, trades, liquidity, price, OHLC            |
-| Raw ingestion pipeline           | `ksp-pipeline-raw-ingestion-lib`            | lib                     | N3                | Retenu                            | `0.3.x`                           | conversion/persistence transport model -> D1 partagée par worker live et backfill                                                                       |
+| Trading Intelligence    | noms à définir                           | libs/jobs          | Futur        | après données stables           | features/signaux/anomalies/ML                            |
-| Core processing pipeline         | `ksp-pipeline-core-processing-lib`          | lib                     | N3                | Retenu                            | `0.3.x/0.6.x`                     | logique D1 -> D2 partagée par worker et replay, basée sur `ksp-program-api`                                                                             |
-| Generic materialization pipeline | `ksp-pipeline-generic-materialization-lib`  | lib                     | N3                | Retenu                            | `0.3.x/0.6.x`                     | logique D2 -> D3 partagée par worker et replay, basée sur `ksp-materializer-api`                                                                        |
-| Domain projection pipeline       | `ksp-pipeline-domain-projection-lib`        | lib                     | N3                | Retenu                            | `0.3.x/0.6.x`                     | logique D3 -> D4 partagée par worker et replay, basée sur `ksp-materializer-api`                                                                        |
-| Trading Intelligence             | noms à définir                              | API/libs/jobs           | N3+               | Futur retenu                      | `0.7.x`                           | statistiques, features, signaux, anomalies, backtests, ML                                                                                               |
-| Trading operation/app            | noms à définir                              | libs/apps               | N3/N4             | Futur retenu                      | après Trading Intelligence        | politique/automatisation de trading et application monoposte                                                                                            |
-| Solana explorer                  | noms à définir                              | libs/apps               | N3/N4             | Futur retenu                      | futur                             | exploration générale Solana                                                                                                                             |
-| DEX explorer                     | noms à définir                              | libs/apps               | N3/N4             | Futur retenu                      | futur                             | exploration/analyse DEX                                                                                                                                 |
 
-## APIs séparées retenues
+## Contrats séparés retenus
-
-Les couples suivants ont une justification d'extensibilité suffisante :
 
 ```text
-ksp-program-api        -> ksp-program-lib
+ksp-program-api
-ksp-materializer-api   -> ksp-materializer-lib
+ksp-materializer-api
-ksp-store-api          -> ksp-store-lib
+ksp-store-api
+ksp-worker-api
+ksp-job-api
+ksp-execution-policy-api
 ```
 
-Les APIs lifecycle sont également séparées :
+Pas de crates séparées actuellement pour :
 
 ```text
-ksp-worker-api         -> workers continus
+ksp-interface-api
-ksp-job-api            -> jobs terminables
+ksp-wallet-api
+ksp-onchain-transport-api
+ksp-offchain-transport-api
+ksp-scenario-api
+ksp-job-control-lib
+ksp-data-api
 ```
 
-Aucune API commune worker+job n'est prévue.
+## Transport
 
-## Execution policy et orchestration
+`ksp-onchain-transport-lib` doit couvrir l'intégralité des opérations documentées de la surface ciblée par chaque release. Les statuts deprecated/obsolete encore fonctionnels et unstable/experimental restent exposés avec warning runtime KSP.
 
-La frontière détaillée est définie dans [`007-EXECUTION_AND_POLICY.md`](007-EXECUTION_AND_POLICY.md).
+La Config standard Transport appartient à `ksp-config-lib`, qui adapte vers les settings publics du transport ; le transport ne dépend jamais de Config.
 
-Principes retenus :
+Les WebSockets supportent plusieurs sessions pour un même endpoint URL, mais un pool/scheduler automatique n'est créé qu'après besoin démontré.
 
-```text
+Les providers Yellowstone spécifiques restent des extensions futures ; le contrat standard est provider-neutral.
-PreparedProgramExecution
-        |
-        v
-ksp-execution-lib
-   |       |       |
- policy  wallet  onchain transport
-```
-
-- `ksp-execution-lib` dépend de `ksp-program-api`, pas de `ksp-program-lib` ;
-- une policy est explicitement fournie pour toute exécution réelle ;
-- la policy peut être évaluée à plusieurs checkpoints ;
-- une policy décide/contraint mais n'exécute pas de réseau/signature/UI ;
-- Program constraints, options caller et policy constraints restent trois sources distinctes ;
-- wallet/signers et transport/provider sont fournis par la composition supérieure ;
-- simulation/submission/status sont des primitives transport orchestrées par execution ;
-- signature est une capacité wallet orchestrée par execution ;
-- retry réseau identique et retry de lifecycle d'exécution restent distincts ;
-- une approbation externe peut suspendre/reprendre l'exécution sans faire dépendre la policy de l'UI ;
-- aucun accès Store depuis `ksp-execution-lib`.
-
-`ksp-logging-lib` est consommé transversalement par les crates runtime qui doivent logger, sans imposer une dépendance aux crates `*-api` déclaratives ni à `ksp-core-lib`.
-
-## Transport on-chain
-
-Aucune crate `ksp-onchain-transport-api` n'est prévue.
-
-`ksp-onchain-transport-lib` peut contenir plusieurs familles hétérogènes :
-
-- HTTP RPC ;
-- WebSocket RPC ;
-- Helius avancé ;
-- Yellowstone ;
-- autres providers/transports futurs.
-
-Les adapters providers doivent toutefois faire sortir de la crate des **modèles de transport homogènes par catégorie de donnée**, afin que les consommateurs n'aient pas à comprendre chaque réponse propriétaire.
-
-Ces modèles :
-
-- restent indépendants de `ksp-store-api` ;
-- conservent les informations raw/provenance nécessaires ;
-- ne réalisent aucun décodage métier/protocolaire ;
-- doivent être facilement et explicitement convertibles par `ksp-worker-raw-retriever` vers les modèles raw persistants de `ksp-store-api`.
-
-Les principes de cette frontière sont désormais fixés : transport et Store restent indépendants, et la conversion explicite transport -> D1 appartient au pipeline/composant de composition. Les DTO exacts seront définis avec les premières implémentations Transport/Store.
-
-## Transport off-chain
-
-Aucune crate `ksp-offchain-transport-api` ni trait global `OffchainTransport` n'est prévu.
-
-`ksp-offchain-transport-lib` regroupe volontairement des accès hétérogènes afin d'éviter une explosion de petites crates. Metadata externes, quotes, prix hors blockchain ou routage peuvent conserver des APIs/modules spécialisés à l'intérieur de cette crate sans prétendre partager une abstraction métier commune.
 
 ## Wallet
 
-Aucune crate `ksp-wallet-api` n'est prévue.
+Le format natif est `.kspwallet`.
 
-`ksp-wallet-lib` est propriétaire du format wallet KSP, des opérations de protection/import/export et de l'accès contrôlé aux capacités pubkey/secret/signature nécessaires aux couches supérieures.
+Les anciens temporary wallets JSON ne sont pas migrés.
 
-Les applications futures utilisant ce wallet restent des consommateurs de `ksp-wallet-lib`, pas des implémentations alternatives du contrat wallet.
+`WalletPolicy` est exclu du Wallet et relève de l'execution policy.
 
-## Workers
+Import/export reste extensible ; les formats supplémentaires sont suivis dans `docs/IDEAS.md`.
 
-### `ksp-worker-api`
+## Data plane
-
-`ksp-worker-api` est une **lifecycle API de services continus**.
-
-Elle pourra porter des contrats communs comme identité, état, health, start/stop/shutdown et événements de lifecycle. Une capacité optionnelle comme la reconfiguration à chaud ne doit devenir universelle que si plusieurs workers la partagent réellement.
-
-Elle ne contient aucun concept de progression/checkpoint terminal propre aux jobs.
-
-### `ksp-worker-control-lib`
-
-`ksp-worker-control-lib` est une implémentation réutilisable de gouvernance au-dessus de `ksp-worker-api`.
-
-Elle doit pouvoir être consommée par :
-
-- une application desktop manager spécialisée ;
-- une future application globale ;
-- un éventuel orchestrateur commun si un besoin opérationnel concret le justifie ;
-- des tools/tests lorsque pertinent.
-
-Les applications restent des interfaces et ne réimplémentent pas elles-mêmes registre, dispatch start/stop, agrégation d'état ou reconfiguration générique.
-
-### Packaging des workers
-
-Chaque package `ksp-worker-<role>` doit pouvoir fournir :
 
 ```text
-library target
+RAW -> CORE -> DECODE -> SPECIALIZED
-    -> logique/runtime service réutilisable
-
-binary target
-    -> bootstrap autonome mince
 ```
 
-Cette direction permet de tester/réutiliser la logique sans perdre la propriété « service indépendant ».
+- RAW : acquisition replayable ;
+- CORE : normalisation blockchain générique sans decoder Program ;
+- DECODE : interpretation Program + matérialisation générique/journal ;
+- SPECIALIZED : projections queryables de domaine.
 
-Le binaire autonome n'est pas une seconde implémentation du worker.
+## Progression des processors
 
-### Workers de processing
+RAW et CORE sont complétés couche par couche avec jobs/workers/apps utiles.
 
-Le modèle initial d'un unique W2 est remplacé par une chaîne de responsabilités plus étroites :
+À partir de DECODE, progression verticale par groupe :
 
 ```text
-raw persisted
+wire -> decode -> materialize -> specialized -> prepare -> policy -> execute -> scenario
-    |
-    v
-ksp-worker-core-processor
-    |
-    v
-canonical Core
-    |
-    v
-ksp-worker-generic-materializer
-    |
-    v
-generic materialization/journal
-    |
-    v
-ksp-worker-domain-projector
-    |
-    v
-domain projections
 ```
 
-Le nom `ksp-worker-domain-projector` est explicitement provisoire jusqu'à ce que les contrats de matérialisation spécialisée soient définis.
+Groupes prioritaires :
-
-## Jobs
-
-`ksp-job-api` est une **lifecycle API de travaux déclenchés et terminables**.
-
-Elle peut porter identité, état, progression, cancel, résultat et, lorsque pertinent, pause/resume/checkpoint.
-
-Aucune `ksp-job-control-lib` n'est prévue actuellement. Le fait que plusieurs jobs implémentent `ksp-job-api` suffit tant qu'aucune duplication concrète de gouvernance ne justifie une bibliothèque commune.
-
-## Notifications de données
-
-Les notifications de données restent indépendantes du lifecycle des workers et des jobs.
-
-Le même type de donnée persistée doit produire le même contrat de notification quelle que soit son origine :
 
 ```text
-worker live -----\
+Solana Core Programs
-job backfill -----+--> même notification de donnée
+SPL token/trading
-import -----------/
+token metadata
+Anchor
+Meteora
+Raydium
+Pump
+Orca
+Market Desk V1
+Jupiter/OKX routing
+Market Desk V2
+trading-adjacent
+general decoding
 ```
 
-`ksp-store-api` reste le propriétaire candidat de ces références/notifications lorsqu'elles signifient qu'une donnée persistée est disponible.
+Meteora vaults, Pump fees et autres satellites nécessaires restent dans leur groupe.
 
-Le transport de notification reste distinct du contrat de donnée.
+## Applications spécialisées
 
-## Scénarios et demos
+Les applications servent de validations/exploitations réelles sans absorber la logique des bibliothèques.
 
-Aucune crate monolithique de scénarios n'est prévue.
+Market Desk est progressive : V1 après les DEX prioritaires, puis enrichissement routing après Jupiter/OKX.
 
-Les scénarios vivent dans des crates spécialisées :
+## Questions restantes
 
-```text
+- noms exacts de Price Desk et Backfill Desk ;
-ksp-scenario-memo-lib
+- surface exacte Yellowstone après audit normatif de `0.2.6-pre.001` ;
-ksp-scenario-token-lib
+- nécessité future d'un pool automatique WS ;
-ksp-scenario-ata-lib
+- types exacts `ksp-program-api`/`ksp-materializer-api`/`ksp-store-api` ;
-ksp-scenario-token-2022-lib
+- nom/packaging précis du premier RAW worker et du CORE normalizer ;
-ksp-scenario-metadata-lib
+- granularité des workers DECODE/SPECIALIZED par groupe.
-ksp-scenario-spm-lib
-...
-```
-
-`ksp-scenario-api` n'est pas retenu actuellement. La norme commune est documentée dans `docs/rules/SCENARIO_CONVENTION.md` et peut évoluer avec les premières implémentations.
-
-Les applications de démonstration correspondantes suivent la forme :
-
-```text
-ksp-app-scenario-<domain>-<environment>-desk-demo
-```
-
-Exemples :
-
-```text
-ksp-app-scenario-memo-devnet-desk-demo
-ksp-app-scenario-token-2022-devnet-desk-demo
-ksp-app-scenario-metadata-devnet-desk-demo
-```
-
-Chaque application appelle la crate `ksp-scenario-<domain>-lib` correspondante et ne duplique pas son scénario. La crate scenario doit également pouvoir être appelée hors desktop.
-
-## Applications spécialisées et control plane
-
-Les applications spécialisées sont prioritaires sur une future application globale.
-
-Une app worker spécialisée passe par `ksp-worker-control-lib` / `ksp-worker-api` et ne manipule pas directement l'état interne du worker dans le Store.
-
-Le data plane est D1–D4. Le control plane porte start/stop/status/health/reconfigure et reste séparé des payloads de processing.
-
-Les workers doivent être exploitables comme services autonomes. Le mécanisme IPC exact reste à définir à la première implémentation manager/service ; aucun `ksp-ipc-api` générique n'est créé maintenant.
-
-Une future application globale est conservée dans `docs/IDEAS.md` seulement.
-
-## Pipelines
-
-`ksp-pipeline-lib` reste rejeté.
-
-Le premier besoin concret de réutilisation est maintenant identifié : worker live et job de replay/backfill doivent partager la même logique d'une frontière durable.
-
-Pipelines retenus :
-
-```text
-ksp-pipeline-raw-ingestion-lib
-ksp-pipeline-core-processing-lib
-ksp-pipeline-generic-materialization-lib
-ksp-pipeline-domain-projection-lib
-```
-
-Les pipelines sont backend/implementation agnostic autant que possible : ils dépendent des APIs (`ksp-store-api`, `ksp-program-api`, `ksp-materializer-api`) et reçoivent les implémentations concrètes par composition depuis worker/job.
-
-## Modèle opérationnel workers/jobs
-
-Le backlog de processing est défini par les inputs applicables moins les processing outcomes terminaux du processor/version/capability cible.
-
-L'absence d'output n'est pas une preuve d'absence de traitement.
-
-KSP retient :
-
-```text
-notification wake-up + periodic polling
-Store backlog = source de vérité
-claim/lease = ownership temporaire
-at-least-once + idempotence = sémantique de traitement
-```
-
-Le raw retriever expose une hot reconfiguration avec distinction desired/effective configuration.
-
-Les jobs de replay restent distincts des workers continus et réutilisent les mêmes pipelines.
-
-## Corrections issues de `pre.003`
-
-Le graphe confirme les principes suivants :
-
-- Program et Materializer restent indépendants du store et des I/O réseau ;
-- `ksp-execution-policy-api` et `ksp-execution-lib` sont retenus ;
-- `ksp-execution-lib` consomme `ksp-program-api`, pas l'implémentation officielle `ksp-program-lib` ;
-- `ksp-materializer-api` peut dépendre de `ksp-program-api`, mais ni Materializer API/lib ni Store API/lib ne se dépendent mutuellement ;
-- les workers/jobs spécialisés réalisent les conversions explicites entre modèles de transport, processing et persistence ;
-- aucun `ksp-data-api` global n'est introduit ;
-- `ksp-worker-control-lib` est retenu comme gouvernance workers réutilisable ; aucune `ksp-job-control-lib` n'est retenue.
-
-## Questions restantes après la fondation
-
-- types Rust exacts des contrats ouverts de `ksp-program-api` ;
-- DTO exacts des modèles transport et D1/D2/D3/D4 avec les premières implémentations concernées ;
-- schémas SQL, indexes, claims/leases et pagination du Store PostgreSQL ;
-- première implémentation manager/service : mécanisme IPC et proxy distant Worker ;
-- contexte requis par les projectors stateful ;
-- futur : orchestrateur commun seulement si un besoin opérationnel concret le justifie ; l'application globale reste un produit futur après validation des apps spécialisées.

docs/architecture/006-WIRE_AND_PROGRAM.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/006-WIRE_AND_PROGRAM.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Wire, Program API et implémentations Program
 
@@ -46,6 +46,21 @@ Les Program IDs fondamentaux restent possédés par `ksp-core-lib`.
 - policy/safety ;
 - lifecycle d'exécution réseau.
 
+## API publique de `ksp-interface-lib`
+
+`ksp-interface-lib` reste une seule crate pour l'instant : aucune `ksp-interface-api` séparée n'est créée.
+
+La façade doit néanmoins exposer une API publique wire stable et réutilisable par :
+
+```text
+ksp-program-lib
+external ksp-program-<name>-lib
+```
+
+Une implementation externe peut donc expérimenter contre les mêmes contrats wire publics avant intégration officielle dans KSP. Lorsqu'un wire externe devient officiel, son intégration dans `ksp-interface-lib` doit rester compatible avec l'API publique retenue, sauf évolution de contrat explicitement versionnée/documentée.
+
+Si une future contrainte de dépendances démontre qu'un split `ksp-interface-api` apporte une valeur réelle, il pourra être étudié selon `KSP-API-007`; la symétrie avec Program ne suffit pas.
+
 ## Propriété des codecs wire
 
 Pour le code KSP officiel, les dépendances directement utilisées pour encoder/décoder les formats wire, notamment `borsh`, `wincode` ou codecs équivalents, appartiennent normalement à `ksp-interface-lib`.
@@ -403,6 +418,18 @@ Les validations peuvent combiner selon le cas :
 
 Une crate externe provoquant volontairement une génération incompatible de dépendances fondamentales ne doit pas être ajoutée au workspace simplement pour faciliter un test si des fixtures/vecteurs indépendants permettent la même vérification.
 
+## Progression verticale par groupe
+
+Après les couches RAW/CORE, les Program implementations ne sont pas développées horizontalement comme une longue liste de decoders isolés. Chaque groupe prioritaire avance successivement :
+
+```text
+wire -> decode -> materialize -> specialized -> execution preparation -> policy -> execution -> scenario
+```
+
+Un composant satellite nécessaire à un protocole reste dans son groupe : Meteora vaults avec Meteora, Pump fee avec Pump, etc.
+
+Ordre prioritaire actuel : Solana Core Programs, SPL token/trading, token metadata, Anchor, Meteora, Raydium, Pump, Orca, routing, trading-adjacent puis décodage généraliste.
+
 ## Questions laissées ouvertes
 
 La première implémentation Program devra encore fixer précisément :
@@ -415,4 +442,4 @@ La première implémentation Program devra encore fixer précisément :
 - stratégie précise de warning/log pour opérations abandonnées ;
 - convention finale `dec` / `exec_prep`.
 
-La tranche suivante doit traiter `ksp-execution-policy-api` et `ksp-execution-lib` sans rouvrir les responsabilités Program définies ici.
+Les releases exactes d'introduction de `ksp-program-lib`, `ksp-execution-policy-api` et `ksp-execution-lib` suivent désormais les vertical slices définis par le roadmap ; les responsabilités Program décrites ici restent valables.

docs/architecture/007-EXECUTION_AND_POLICY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/007-EXECUTION_AND_POLICY.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Execution et Policy
 
@@ -311,6 +311,18 @@ ksp-execution-lib -X-> ksp-store-api
 ksp-execution-lib -X-> ksp-store-lib
 ```
 
+## Ownership des implementations de policy
+
+`ksp-execution-policy-api` est le contrat commun. Une crate générale `ksp-execution-policy-lib` n'est pas créée par symétrie.
+
+Une petite policy strictement propre à un scenario, un orchestrateur ou une application spécialisée peut être implémentée directement dans cette crate. Une ou plusieurs bibliothèques de policies communes ne sont introduites que lorsque plusieurs consommateurs démontrent une réutilisation réelle.
+
+Les anciennes règles historiques de type `WalletPolicy` qui concernent limites de dépense, réseau, programme, simulation ou autorisation sont déplacées conceptuellement vers cette frontière policy et non vers `ksp-wallet-lib`.
+
+## Execution dans les vertical slices
+
+L'exécution n'est pas reportée après « tous les decoders ». Pour chaque groupe Program prioritaire, les opérations pertinentes avancent après décodage/matérialisation jusqu'à préparation, policy, execution et scénarios Devnet lorsque le réseau/protocole permet une validation réelle.
+
 ## Questions laissées à l'implémentation
 
 - types Rust exacts des checkpoints et décisions de policy ;

docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md

@@ -1,614 +1,344 @@
 <!-- file: docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Data, Materialization et Store
 
 ## Objet
 
-Ce document constitue la sortie principale de `0.0.3-pre.006`.
+Ce document définit la chaîne durable KSP, la responsabilité du Store et les frontières de replay.
 
-Il définit les frontières durables de données KSP et précise :
+La nomenclature canonique est désormais :
-
-- les niveaux D1 à D4 ;
-- la séparation `ksp-materializer-api` / `ksp-materializer-lib` / Store ;
-- le rôle backend-agnostic de `ksp-store-api` ;
-- PostgreSQL comme implémentation de référence de `ksp-store-lib` ;
-- provenance et temporalités ;
-- idempotence et versionnement des processors ;
-- replay indépendant par frontière ;
-- sémantique des notifications de données persistées ;
-- stabilité différente entre niveaux structurants et projections spécialisées.
-
-Le lifecycle complet, batching, concurrence, backlog et reprise des workers/jobs sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
-
-## Nomenclature des niveaux durables
-
-Les niveaux de données ne réutilisent pas N1 à N4, déjà réservés aux couches architecturales KSP.
-
-La nomenclature durable retenue est :
 
 ```text
-D1 — Raw
+RAW -> CORE -> DECODE -> SPECIALIZED
-D2 — Core canonique
-D3 — Journal de matérialisation générique
-D4 — Projections spécialisées/queryables par domaine
 ```
 
-Flux général :
+Les aliases D1–D4 restent utilisés pour les niveaux persistés :
 
 ```text
-source on-chain
+D1 = RAW
-    |
+D2 = CORE
-    v
+D3 = DECODE / matérialisation générique décodée
-ksp-worker-raw-retriever
+D4 = SPECIALIZED
-    |
-    v
-D1 Raw
-    |
-    v
-ksp-worker-core-processor
-    |
-    v
-D2 Core canonique
-    |
-    v
-ksp-worker-generic-materializer
-    |
-    v
-D3 journal générique
-    |
-    v
-ksp-worker-domain-projector
-    |
-    v
-D4 projections de domaine
 ```
 
-Le nom `ksp-worker-domain-projector` reste révisable ; la frontière D3 -> D4 est, elle, retenue.
+Cette clarification remplace l'ancienne interprétation où D1 -> D2 pouvait déjà dépendre de `ksp-program-api`. **RAW et CORE sont indépendants de tout decoder Program.**
 
-# D1 — Raw
+## Principes structurants
+
+- le Store persiste des contrats de données ; il ne possède ni transport, ni decoder, ni materializer ;
+- chaque frontière durable peut être rejouée indépendamment ;
+- les données de provenance/versioning permettent de savoir quel processor a produit quel output ;
+- les couches dérivées ne rendent jamais obligatoire une nouvelle acquisition réseau lorsque l'input durable nécessaire existe déjà ;
+- D4 privilégie les faits métier génériques lorsqu'une normalisation inter-protocoles est pertinente.
+
+# D1 — RAW
 
 ## Mission
 
-D1 conserve l'acquisition suffisamment fidèlement pour permettre un nouveau processing sans redemander la donnée à la blockchain lorsque l'information nécessaire a déjà été capturée.
+RAW conserve l'acquisition suffisamment fidèlement pour reconstruire CORE sans redemander la donnée au provider lorsqu'elle a déjà été capturée.
 
-`raw` ne signifie pas nécessairement « enveloppe propriétaire du provider conservée sans aucune normalisation ». Le transport peut normaliser ses différentes sources vers des modèles KSP homogènes.
+Le transport peut normaliser plusieurs providers vers un modèle KSP homogène, mais D1 doit rester lossless pour les besoins de replay couverts.
 
-La persistance D1 doit toutefois rester **lossless pour les besoins de replay couverts** : toute information nécessaire à la reconstruction du Core doit être conservée, y compris le contenu brut et la provenance utile.
+D1 ne décode aucun programme Solana/SPL/Metaplex/DEX.
 
-## Frontière transport -> D1
+## Frontière Transport -> RAW
 
 ```text
-Solana RPC ------\
+HTTP / WS / gRPC / provider
-Helius -----------+--> modèle homogène ksp-onchain-transport-lib
+          |
-Yellowstone ------/
+          v
-                        |
+ksp-onchain-transport-lib
-                        v
+          |
-                conversion explicite
+          v
-                        |
+conversion explicite
-                        v
+          |
-              DTO D1 de ksp-store-api
+          v
+ksp-store-api RAW DTO
+          |
+          v
+ksp-store-lib
 ```
 
 `ksp-onchain-transport-lib` ne dépend ni de `ksp-store-api` ni de `ksp-store-lib`.
 
-La conversion appartient au composant de composition, principalement `ksp-worker-raw-retriever` ou `ksp-job-backfill`.
+## Provenance RAW
 
-## Provenance D1
+Selon la catégorie, D1 doit pouvoir conserver notamment :
 
-Selon la catégorie de donnée, D1 doit pouvoir conserver notamment :
+- cluster/network ;
-
+- slot/signature/pubkey/identité blockchain applicable ;
-- réseau ;
+- payload replayable ;
-- identité blockchain : slot, signature, pubkey ou autre identifiant applicable ;
-- contenu raw/replayable ;
 - provider ;
-- transport/source ;
+- endpoint/source/transport ;
-- rôle d'acquisition : live, backfill, import ou autre ;
+- rôle d'acquisition : live, backfill, import ;
-- instant d'observation/acquisition ;
+- instant d'observation ;
 - instant de persistence ;
-- hash/identité d'idempotence ;
+- identité/hash d'idempotence ;
-- informations de pagination/capture nécessaires à la reprise lorsque pertinentes.
+- cursor/page/range/checkpoint lorsque pertinent.
 
-`block_time` reste optionnel et n'est jamais inventé lorsqu'il n'est pas fourni ou reconstructible de manière fiable.
+# D2 — CORE
-
-# D2 — Core canonique
 
 ## Mission
 
-D2 contient les faits canoniques Solana produits à partir de D1.
+CORE est une **normalisation canonique générique de la blockchain Solana**.
 
-Le Core doit être suffisamment durable et général pour être rejoué vers les matérialisations futures sans repasser par l'acquisition ou le décodage raw.
+Cette couche doit fonctionner même si `ksp-program-api` et `ksp-program-lib` ne sont pas encore capables de décoder le moindre programme métier.
 
-Conceptuellement, D2 peut accueillir notamment :
+Exemples de faits CORE candidats :
 
-- transactions canoniques ;
+- slots ;
-- instructions top-level ;
+- blocks et block metadata ;
-- instructions CPI ;
+- signatures ;
-- comptes/états canoniques ;
+- transactions ;
-- résultats de décodage Program ouverts ;
+- messages legacy/versioned ;
-- événements/return data lorsqu'ils sont supportés ;
+- account keys et address lookups ;
-- autres faits génériques Solana qui appartiennent réellement au Core.
+- comptes et états bruts structurés génériquement ;
+- instructions top-level brutes ;
+- instructions CPI brutes ;
+- logs ;
+- transaction meta ;
+- balances/fees/rewards lorsqu'ils appartiennent au contrat blockchain générique ;
+- return data brute ;
+- relations structurelles transaction/message/instruction/account.
 
-## Top-level / CPI
+Un fait CORE peut contenir un `program_id`, des bytes et des indexes sans savoir que l'instruction représente un `Transfer`, un `Swap` ou une mutation Metadata.
 
-Les instructions top-level et CPI restent des faits distincts.
+## Frontière RAW -> CORE
-
-Leur modèle peut partager des champs, mais KSP ne doit pas les fusionner artificiellement lorsque leurs invariants ou requêtes diffèrent.
-
-La séparation physique exacte sera décidée dans la première release Store.
-
-## Frontière D1 -> D2
 
 ```text
-DTO D1 store
+D1 RAW
-    |
+   |
-    v
+   v
-ksp-worker-core-processor
+normalisation Solana générique
-    |
+   |
-    +--> conversion vers entrée ksp-program-api
+   v
-    |
+D2 CORE
-    +--> ksp-program-lib / extension compatible
-    |
-    +--> sortie Core ouverte
-    |
-    v
-conversion vers DTO D2 store
 ```
 
-`ksp-program-api` / `ksp-program-lib` restent indépendants du Store.
+Interdictions :
 
-## Provenance D2
+```text
+RAW -> CORE -X-> ksp-program-api
+RAW -> CORE -X-> ksp-program-lib
+RAW -> CORE -X-> ksp-materializer-api
+```
 
-D2 doit pouvoir relier un résultat à :
+Les codecs/wires génériques nécessaires à la structure Solana peuvent provenir de `ksp-interface-lib` lorsqu'ils appartiennent à la façade wire officielle, sans transformer cette étape en décodage Program.
+
+## Provenance CORE
+
+D2 doit pouvoir relier chaque résultat à :
 
 - son input D1 ;
-- l'identité/version du processor ;
+- l'identité/version du normalizer CORE ;
-- l'identité/version de l'implémentation Program/decoder lorsque pertinente ;
+- un hash logique d'input ;
-- la capacité de décodage utilisée ;
-- un hash de l'input logique ;
 - l'instant de processing/persistence ;
-- l'état de processing lorsqu'un lifecycle durable est nécessaire.
+- son état de processing durable lorsque nécessaire.
 
-# D3 — Journal de matérialisation générique
+# D3 — DECODE / matérialisation générique
 
 ## Mission
 
-D3 est un **journal durable**, pas une étape volatile.
+DECODE commence lorsque KSP interprète un `program_id`, un layout d'instruction, un compte ou un événement selon un contrat Program/protocole.
 
-Il conserve l'équivalent conceptuel obligatoire de l'ancien journal `k_sol_mat_outputs` de `ks-store`, sans figer encore le nom exact de la table KSP.
+La progression logique d'un groupe est :
-
-Il doit permettre de répondre à des questions telles que :
 
 ```text
-quel input D2 ?
+CORE
+  |
+  v
+decoder Program
+  |
+  v
+decoded facts
+  |
+  v
+materialisation générique / journal durable
+  |
+  v
+D3 DECODE
+```
+
+D3 conserve l'équivalent conceptuel obligatoire du journal générique de matérialisation de bot3 (`k_sol_mat_outputs`), sans imposer son ancien schéma ou son nom physique.
+
+Le journal doit pouvoir répondre au minimum :
+
+```text
+quel input CORE ?
+quel program/decoder ?
+quelle version ?
 quel materializer ?
 quelle version ?
 quel output logique ?
 quel type/domaine ?
 quel hash ?
 quel instant ?
-quel état courant/superseded/failed/replay ?
+quel état/superseded/failed/replay ?
 ```
 
-D3 permet notamment de reconstruire D4 après évolution d'un projector sans refaire D1 -> D2 ou D2 -> D3.
+Les types exacts de decoded facts et du journal sont décidés lorsque les premiers vertical slices Program existent.
 
-## Frontière D2 -> D3
+## Frontière CORE -> DECODE
 
 ```text
-D2 Core
+D2 CORE
    |
    v
-ksp-worker-generic-materializer
+ksp-program-api implementation
-   |
-   +--> conversion vers ksp-materializer-api
-   |
-   +--> GenericMaterializer
    |
    v
-generic materialization output
+decoded output
    |
    v
-conversion vers DTO D3 store
+ksp-materializer-api implementation
+   |
+   v
+D3 journal / decoded materialization
 ```
 
-Les noms Rust exacts ne sont pas figés.
+Les implémentations officielles pourront provenir de `ksp-program-lib` et `ksp-materializer-lib`; des implémentations externes compatibles restent possibles.
 
-## Extensibilité externe
+Program et Materializer ne dépendent pas du backend Store.
 
-Une implémentation externe de materializer doit pouvoir produire un output générique compatible avec D3 sans exiger une nouvelle table PostgreSQL spécialisée.
+# D4 — SPECIALIZED
-
-Cela rend possible :
-
-```text
-external materializer
-      |
-      v
-ksp-materializer-api
-      |
-      v
-D3 journal générique
-```
-
-avant une éventuelle intégration officielle complète en D4.
-
-# D4 — Projections spécialisées de domaine
 
 ## Mission
 
-D4 contient les représentations optimisées pour les requêtes métier, analytiques et produit.
+SPECIALIZED expose des projections queryables utiles aux applications, analyses et futurs modèles ML.
-
-Exemples futurs :
-
-- assets/tokens ;
-- metadata d'assets/tokens ;
-- Solana Program Metadata ;
-- liquidity pools ;
-- order books ;
-- swaps/trades ;
-- prices/volumes ;
-- positions ;
-- autres projections de domaine.
-
-## Faits canoniques, pas familles par protocole
-
-D4 reste organisé par **fait canonique**, pas par Program ID/protocole.
-
-Éviter par défaut :
-
-```text
-meteora_pools
-raydium_pools
-orca_pools
-```
-
-au profit d'une projection canonique telle que :
-
-```text
-liquidity_pools
-```
-
-avec provenance/identité du protocole lorsque nécessaire.
-
-La même règle s'applique aux swaps, order books et autres faits pouvant être normalisés.
-
-## Metadata
-
-Les metadata d'assets/tokens constituent une famille canonique commune pouvant recevoir des données provenant notamment :
-
-- Metaplex Token Metadata ;
-- Token-2022 Metadata.
-
-Solana Program Metadata reste une projection distincte car le domaine fonctionnel est différent.
-
-## Nouvelle projection externe
-
-Une nouvelle projection D4 relationnelle implique nécessairement un contrat de persistence et une implémentation backend.
-
-KSP ne masque pas cette réalité derrière une API de matérialisation « magique ».
-
-Une extension externe peut fonctionner jusqu'à D3 sans migration Store spécialisée. Pour obtenir une nouvelle projection D4 officielle, il faut intégrer :
-
-- le contrat DTO/repository approprié dans `ksp-store-api` ;
-- la migration/repository PostgreSQL dans `ksp-store-lib` ;
-- la conversion/projector appropriée dans le composant de processing.
-
-Un mécanisme de backend/projection entièrement externe pourra être étudié seulement si un besoin concret apparaît.
-
-# Stabilité des niveaux durables
-
-La direction retenue est :
-
-```text
-D1 — fortement stable
-D2 — fortement stable
-D3 — fortement stable
-D4 — volontairement plus évolutif
-```
-
-Après stabilisation de la première série Store réelle, les contrats D1/D2/D3 doivent changer seulement en cas :
-
-- d'erreur structurelle ;
-- d'omission majeure ;
-- de nécessité de compatibilité impossible à résoudre additivement.
-
-D4 peut évoluer plus librement lorsque de nouveaux décodeurs, materializers ou produits révèlent des besoins queryables supplémentaires.
-
-# `ksp-materializer-api`
-
-## Rôle
-
-Une seule crate publique est retenue :
-
-```text
-ksp-materializer-api
-```
-
-Elle expose les contrats de matérialisation réutilisables sans dépendre du Store.
-
-Deux capacités conceptuelles doivent pouvoir être distinguées :
-
-```text
-GenericMaterializer
-DomainProjector
-```
-
-Les noms exacts restent à valider.
-
-### GenericMaterializer
-
-Transforme une représentation Core/runtime en output générique persistable en D3.
-
-### DomainProjector
-
-Transforme un ou plusieurs inputs génériques/canoniques en représentation spécialisée de domaine destinée à D4.
-
-Le second contrat peut évoluer en fonction des premiers cas réels. La séparation des responsabilités est plus importante que le nom du trait.
-
-## Dépendances
-
-```text
-ksp-materializer-api
-    -> ksp-core-lib
-    -> ksp-program-api
-```
-
-Pas de dépendance vers Store.
-
-# `ksp-materializer-lib`
-
-`ksp-materializer-lib` contient les implémentations officielles KSP de `ksp-materializer-api`.
-
-Organisation conceptuelle possible :
-
-```text
-generic/
-    ...
-
-domain/
-    metadata/
-    token/
-    dex/
-    ...
-```
-
-La structure finale suivra les règles de domaine établies avec les premières implémentations.
-
-Interdictions :
-
-```text
-ksp-materializer-lib -X-> ksp-store-api
-ksp-materializer-lib -X-> ksp-store-lib
-```
-
-Un materializer transforme ; il ne persiste pas directement.
-
-Le worker/job/pipeline spécialisé relie la transformation à la persistence.
-
-# `ksp-store-api`
-
-## Rôle
-
-`ksp-store-api` expose la frontière backend-agnostic de persistence KSP.
-
-Il possède les contrats persistants correspondant aux niveaux durables :
-
-```text
-raw
-core
-materialization
-domain
-```
-
-La structure exacte des modules Rust sera définie avec la première implémentation.
-
-`ksp-store-api` ne dépend pas de Program, Materializer ou Transport.
-
-## Contrats génériques et contrats de domaine
-
-D1/D2/D3 doivent rester génériques et fortement structurants.
-
-D4 peut croître progressivement avec les domaines officiellement supportés.
-
-Cette différence est volontaire : l'API Store doit pouvoir ajouter de nouvelles projections queryables sans déstabiliser les contrats de replay historiques.
-
-# `ksp-store-lib`
-
-`ksp-store-lib` est l'implémentation officielle de référence de `ksp-store-api`.
-
-PostgreSQL est le backend de référence prévu.
-
-La crate possède notamment :
-
-- configuration backend/connexion ;
-- pool/transactions backend ;
-- migrations ;
-- repositories ;
-- queries ;
-- persistence D1/D2/D3/D4 ;
-- primitives de backlog/replay nécessaires au backend ;
-- mécanismes PostgreSQL de notification lorsqu'ils sont retenus.
-
-Les autres crates KSP ne contournent pas `ksp-store-lib` pour exécuter directement leurs propres opérations PostgreSQL.
-
-Un second backend n'est pas créé abstraitement ; il devra justifier l'évolution de l'architecture lorsqu'un besoin réel apparaît.
-
-# Temporalités
-
-Les temporalités blockchain et locales sont distinctes.
-
-Exemples blockchain :
-
-```text
-slot
-block_time: Option<...>
-```
-
-Exemples locaux :
-
-```text
-observed_at
-acquired_at
-persisted_at
-processed_at
-materialized_at
-projected_at
-```
-
-Toutes ne doivent pas nécessairement être présentes dans chaque DTO/table. Leur sémantique doit cependant être explicite lorsqu'elles existent.
-
-Aucune date locale ne remplace silencieusement un `block_time` absent.
-
-# Provenance
-
-Un niveau dérivé doit permettre de remonter à son input durable et au processor qui l'a produit.
-
-## D1
-
-Provenance d'acquisition :
-
-- network ;
-- provider/source ;
-- transport ;
-- rôle d'acquisition ;
-- identité blockchain ;
-- temporalités d'observation/persistence.
-
-## D2
-
-En plus :
-
-- input D1 ;
-- processor/decoder identity ;
-- processor/decoder version ;
-- input hash ;
-- processing time/state.
-
-## D3
-
-En plus :
-
-- input D2 ;
-- materializer identity/version ;
-- output identity/type/domain ;
-- output/input hash ;
-- materialization time/state.
-
-## D4
-
-En plus :
-
-- input(s) D3 ou références canoniques explicitement définies ;
-- projector identity/version ;
-- projection time/state.
-
-La représentation exacte de la provenance sera conçue pour éviter de répéter inutilement de gros payloads.
-
-# Idempotence et versionnement
-
-Chaque frontière dérivée doit pouvoir rejouer le même input sans créer de doublons logiquement distincts.
-
-Principe conceptuel :
-
-```text
-same logical input
-+ same processor identity
-+ same processor version
-+ same logical output identity
-= same durable result
-```
-
-Une nouvelle version du processor doit pouvoir coexister avec ou superséder le résultat précédent selon la politique du niveau.
-
-Le système doit pouvoir représenter selon besoin des états tels que :
-
-```text
-current
-superseded
-pending
-failed
-replay
-```
-
-Les noms, colonnes et contraintes SQL exacts seront décidés avec la première implémentation.
-
-L'idempotence ne doit pas reposer uniquement sur l'espoir qu'une notification soit livrée une seule fois.
-
-# Replay
-
-Les replays sont séparés par frontière durable :
-
-```text
-D1 -> D2
-D2 -> D3
-D3 -> D4
-```
-
-Ils doivent pouvoir être exécutés indépendamment.
 
 Exemples :
 
-- nouveau decoder/Core processor : rejouer D1 -> D2 ;
+- token/asset state ;
-- nouveau materializer générique : rejouer D2 -> D3 ;
+- metadata canonique d'asset ;
-- nouvelle version d'un projector : rejouer D3 -> D4.
+- pools/markets ;
+- reserves/liquidity ;
+- positions ;
+- swaps/trades ;
+- fees ;
+- observations de prix ;
+- OHLC/candles ;
+- routes et legs ;
+- faits trading-adjacent ;
+- projections d'autres domaines futurs.
 
-Il ne doit pas être nécessaire de refaire toute la chaîne lorsqu'un niveau inférieur inchangé contient déjà l'information requise.
+## Faits métier génériques
 
-Les replays sont des **jobs bornés**, pas des modes cachés des workers live.
+Les projections de trading ne sont pas séparées automatiquement par protocole.
 
-Les jobs de replay retenus sont `ksp-job-replay-core`, `ksp-job-replay-generic-materialization` et `ksp-job-replay-domain-projection`.
+Préférer lorsque possible :
-
-# Notifications de données persistées
-
-## Contrat
-
-`ksp-store-api` est le propriétaire du contrat canonique lorsqu'une notification signifie :
-
-> une donnée durable de telle catégorie/référence est disponible.
-
-Le même type de donnée utilise le même format de notification quelle que soit son origine :
 
 ```text
-worker live
+liquidity_pools
-backfill job
+trades
-import
+positions
-replay
+price_observations
-autre source
+ohlc
+routes
+route_legs
 ```
 
-## Notification != source de vérité
+plutôt que :
-
-Une notification est un **signal de réveil/accélération**, jamais la source de vérité du backlog.
-
-Elle peut être :
-
-- perdue ;
-- dupliquée ;
-- retardée ;
-- reçue après un restart.
-
-Le consumer doit toujours pouvoir reconstruire son travail depuis le Store.
-
-Exemple conceptuel :
 
 ```text
-notification RawAvailable
+meteora_trades
-       |
+raydium_trades
-       v
+orca_trades
-wake-up core worker
+pump_trades
-       |
-       v
-store query:
-"quels inputs D1 ne sont pas encore traités
- par CoreProcessor version X ?"
 ```
 
-Le Store, l'idempotence et les checkpoints durables constituent la vérité.
+Les champs réellement protocol-specific peuvent être conservés dans une extension ou une projection dédiée uniquement lorsqu'un besoin de requête/invariant le justifie.
 
-Cette règle évite d'exiger immédiatement un broker exactly-once.
+## Metadata
 
-## Ordre de publication
+La direction reste :
 
-Une donnée n'est annoncée disponible qu'après persistence réussie :
+- projection canonique commune pour metadata d'assets/tokens alimentée par Metaplex Token Metadata et Token-2022 Metadata ;
+- SPM reste distinct et sera redéveloppé plus tard avec le décodage généraliste.
+
+## OHLC
+
+Les candles sont des projections SPECIALIZED calculées à partir des trades/price observations persistés.
+
+Une application marché lit les OHLC matérialisés ; elle ne reparcourt pas toutes les transactions pour reconstruire les candles à chaque affichage.
+
+# Vertical slices Program
+
+RAW et CORE sont développés horizontalement.
+
+À partir de DECODE, la progression est verticale par groupe :
+
+```text
+wire
+ -> decode
+ -> generic materialization / D3
+ -> specialized projection / D4 si utile
+ -> execution preparation
+ -> execution policy
+ -> execution
+ -> Devnet scenarios / validation
+```
+
+Un groupe doit atteindre une cohérence verticale suffisante avant que le groupe suivant devienne prioritaire.
+
+Les composants satellites nécessaires à un protocole appartiennent à son groupe : Pump fees avec Pump, Meteora vaults avec Meteora, etc.
+
+# `ksp-store-api`
+
+`ksp-store-api` est backend-agnostic et porte les contrats nécessaires aux consommateurs.
+
+La première implementation `0.3.1` est volontairement **RAW-only** : elle ne crée pas prématurément les contrats physiques D2/D3/D4.
+
+Les surfaces CORE/DECODE/SPECIALIZED sont ajoutées quand leurs couches sont réellement ouvertes.
+
+# `ksp-store-lib`
+
+`ksp-store-lib` fournit PostgreSQL comme backend officiel de référence derrière `ksp-store-api`.
+
+Il possède :
+
+- migrations ;
+- SQL ;
+- transactions ;
+- mapping backend ;
+- pagination ;
+- claim/lease lorsque nécessaire ;
+- notifications backend si retenues.
+
+Il ne possède pas :
+
+- transport réseau ;
+- decoder Program ;
+- materializer ;
+- orchestration de worker/job.
+
+# `ksp-materializer-api` et `ksp-materializer-lib`
+
+Ils sont introduits seulement lorsque le premier groupe DECODE démontre le contrat réel.
+
+`ksp-materializer-api` porte les contrats extensibles ; `ksp-materializer-lib` contient les implementations officielles communes.
+
+Une projection très locale/spécifique peut rester dans son groupe si la création d'une implémentation commune séparée n'apporte pas de réutilisation réelle.
+
+# Replay
+
+Les frontières durables restent replayables indépendamment :
+
+```text
+RAW -> CORE
+CORE -> DECODE
+DECODE -> SPECIALIZED
+```
+
+Un replay d'une couche dérivée ne doit pas refaire arbitrairement les couches précédentes.
+
+# Notifications persistées
+
+Le Store reste source de vérité du backlog.
+
+Les notifications ne sont qu'un wake-up : elles peuvent être perdues ou dupliquées.
+
+Ordre :
 
 ```text
 persist
@@ -616,118 +346,35 @@ commit
 notify
 ```
 
-et non :
+Le consumer reconstruit toujours son backlog depuis le Store avec les versions de processor et les marqueurs d'idempotence.
-
-```text
-notify
-persist
-```
-
-## Payload
-
-La notification privilégie une référence durable compacte plutôt que la duplication de tout le payload :
-
-- catégorie/type ;
-- réseau ;
-- identifiant/range/cursor durable ;
-- autres informations minimales nécessaires au consumer.
-
-Les noms de DTO exacts restent à définir.
-
-## Mécanisme de diffusion
-
-Le contrat est indépendant du mécanisme.
-
-Candidats :
-
-```text
-channel in-process
-PostgreSQL LISTEN/NOTIFY
-IPC
-broker externe
-```
-
-`ksp-store-lib` peut fournir PostgreSQL LISTEN/NOTIFY comme mécanisme de référence si cela répond au premier besoin.
-
-Le mécanisme initial de référence et la reprise opérationnelle sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
 
 # Acquisition live et backfill
 
-`ksp-worker-raw-retriever` et `ksp-job-backfill` diffèrent par leur lifecycle/orchestration mais produisent le **même contrat D1** pour la même catégorie de donnée.
+Live et backfill alimentent la même frontière RAW :
 
 ```text
-live source ----------\
+live worker ----\
-                       +--> D1 Raw
+                 +--> RAW persistence
-historical backfill --/
+backfill job ----/
 ```
 
-Cela garantit que le processing downstream ne dépend pas de la manière dont la donnée a été acquise.
+Ils ne dupliquent pas le contrat durable.
 
-Le backfill n'est pas un mode historique du worker live.
+# Stabilité
 
-# Workers de processing
+La stabilité cible est différente selon la couche :
 
-Les frontières de responsabilité sont désormais :
+- RAW : fortement stable après mise en production ;
-
+- CORE : fortement stable après validation de la normalisation Solana générique ;
-```text
+- DECODE : extensible par nouveaux Program/versions ;
-ksp-worker-raw-retriever
+- SPECIALIZED : plus évolutif selon les besoins de query, trading et analytics.
-    transport -> D1
-
-ksp-worker-core-processor
-    D1 -> D2
-
-ksp-worker-generic-materializer
-    D2 -> D3
-
-ksp-worker-domain-projector
-    D3 -> D4
-```
-
-Chaque worker :
-
-- peut utiliser les notifications pour réduire la latence ;
-- doit pouvoir reconstruire son backlog depuis le Store ;
-- écrit seulement le niveau durable dont il est propriétaire ;
-- ne transforme pas silencieusement plusieurs frontières en une étape monolithique.
-
-Le lifecycle, la concurrence, les cursors/checkpoints et la hot reconfiguration sont détaillés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
-
-# Projections de trading et autres domaines
-
-Le trading reste une priorité produit mais ne détermine pas la structure D1/D2/D3.
-
-D4 doit accueillir progressivement des faits canoniques de nombreux domaines :
-
-- token ;
-- metadata ;
-- staking ;
-- programmes ;
-- trading/DEX ;
-- autres domaines futurs.
-
-Pour le trading, les materializers/projectors doivent normaliser les noms et structures propres aux protocoles vers des faits communs lorsque les invariants le permettent.
 
 # Questions laissées ouvertes
 
-La première implémentation Store devra encore fixer :
+- schémas SQL exacts RAW puis CORE ;
-
+- représentation persistable exacte d'un decoded output ;
-- schémas SQL et noms exacts des tables ;
+- contrat exact du journal D3 ;
-- clés/idempotence exactes ;
+- granularité des projectors SPECIALIZED ;
-- représentation des hashes ;
+- politique de supersession/versioning des outputs ;
-- états de processing exacts ;
+- fenêtres OHLC initiales ;
-- temporalités obligatoires/optionnelles par table ;
+- mécanisme de contexte pour les projections stateful.
-- format exact des DTO D1/D2/D3 ;
-- structure des repositories/transactions backend ;
-- pagination/cursors ;
-- conversion u64/slot/PostgreSQL ;
-- stratégie des migrations initiales.
-
-Les sujets opérationnels worker/job ont été précisés dans `009-ACQUISITION_WORKERS_AND_JOBS.md`.
-
-Restent à définir à l'implémentation :
-
-- schémas SQL et contraintes exactes ;
-- format concret des DTO D1/D2/D3/D4 ;
-- claim/lease PostgreSQL ;
-- contexte des projectors stateful ;
-- mécanisme IPC des managers de services autonomes.

docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->
 
 # Applications, services, scenarios et control plane
 
@@ -47,6 +47,12 @@ Elle ne doit pas réimplémenter :
 - lifecycle interne d'un worker/job ;
 - logique de pipeline réutilisable.
 
+# Applications de validation par couche
+
+KSP peut ajouter une petite application spécialisée à la fin d'une couche RAW ou CORE lorsque cela permet de valider et exploiter réellement la couche avant de passer à la suivante. Ces applications lisent les contrats KSP et ne recopient pas les processors dans Tauri.
+
+À partir des vertical slices Program, les applications restent attachées aux besoins réels : demos de scenarios pour l'exécution et Market Desk pour les projections de marché.
+
 # Priorité aux applications spécialisées
 
 KSP ne planifie pas actuellement de cockpit desktop global.
@@ -151,11 +157,12 @@ Exemples conceptuels :
 
 ```text
 ksp-worker-raw-retriever
-ksp-worker-core-processor
+future CORE worker
-ksp-worker-generic-materializer
+future group-specific DECODE/SPECIALIZED workers when justified
-ksp-worker-domain-projector
 ```
 
+RAW et CORE reçoivent leurs workers à la fin de leur couche respective. Les workers DECODE/SPECIALIZED ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
+
 Le binaire doit rester mince.
 
 Il ne duplique pas le pipeline ni la logique de worker contenue dans la cible bibliothèque du même package.
@@ -189,21 +196,26 @@ core-processor -X-> generic-materializer
 generic-materializer -X-> domain-projector
 ```
 
-Le data plane reste :
+Le data plane durable reste :
 
 ```text
-W1 -> D1
+transport / acquisition
-      |
+        |
-      v
+        v
-     W2 -> D2
+      D1 RAW
-            |
+        |
-            v
+        v
-           W3 -> D3
+      D2 CORE
-                  |
+        |
-                  v
+        v
-                 W4 -> D4
+      D3 DECODE
+        |
+        v
+   D4 SPECIALIZED
 ```
 
+Ce schéma décrit les **frontières de données**, pas quatre workers globaux imposés. RAW et CORE peuvent disposer de workers horizontaux propres à leur couche. À partir de DECODE, la granularité des workers/processors émerge des groupes fonctionnels verticaux réellement introduits ; plusieurs groupes peuvent donc posséder des lifecycle hosts distincts sans qu'un `W3` ou `W4` universel existe.
+
 Les notifications accélèrent le réveil mais ne créent pas une connexion fonctionnelle worker-to-worker.
 
 Cette indépendance permet arrêt, restart ou mise à jour d'un worker sans arrêter volontairement les autres.
@@ -232,7 +244,7 @@ Le data plane transporte/persiste les données Solana et les résultats de proce
 ksp-onchain-transport-lib
         |
         v
-D1 -> D2 -> D3 -> D4
+RAW -> CORE -> DECODE -> SPECIALIZED
 ```
 
 avec notifications de données persistées comme wake-up.
@@ -469,6 +481,16 @@ worker status
 
 Une app spécialisée peut éditer une configuration puis demander son application, mais ne doit pas considérer l'écriture du document comme la preuve que le worker l'a appliquée.
 
+# Market Desk progressive
+
+Après les groupes Meteora/Raydium/Pump/Orca, KSP prévoit une première application spécialisée candidate `ksp-app-market-desk`.
+
+V1 peut afficher tokens, pools/markets, liquidité, trades/swaps, prix, volumes, OHLC et activité live/récente à partir des projections SPECIALIZED et des contrats KSP. Elle ne dépend pas directement des SDK/protocoles DEX pour reconstruire leurs modèles dans l'UI.
+
+Après Jupiter/OKX, la même application est enrichie avec routes, legs, DEX impliqués, fees/slippage et comparaison quote/execution lorsqu'elle existe.
+
+Les OHLC sont matérialisés dans SPECIALIZED et consommés par l'application; ils ne sont pas recalculés à partir de tout l'historique lors de chaque rendu.
+
 # Future orchestrator
 
 Un orchestrateur global pourra devenir utile lorsque plusieurs services/managers/jobs devront être coordonnés.
@@ -522,7 +544,7 @@ control/application adapters
 Data plane séparé :
 
 ```text
-transport -> D1 -> D2 -> D3 -> D4
+transport -> RAW -> CORE -> DECODE -> SPECIALIZED
 ```
 
 Aucun payload de processing n'a besoin de transiter via l'UI/control plane.

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 24 -->
+<!-- version: 28 -->
 
 # Plans KSP
 
@@ -14,7 +14,8 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 - [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à `0.1.1-rel.001`.
 - [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
 - [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`.
-- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan actif de `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` avant toute implémentation Tauri fonctionnelle.
+- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan historique clôturé de la release stable `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` puis consolidé jusqu'à `0.1.4-rel.001`.
+- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan historique clôturé de la release stable `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002`, audité par `pre.003` puis publié par `rel.001`; il fixe l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program et le prompt `0.2.1`.
 
 Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
 

docs/plans/001-V0_0_3_PLAN.md

@@ -1,8 +1,11 @@
 <!-- file: docs/plans/001-V0_0_3_PLAN.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Plan KSP 0.0.3
 
+> **Note de supersession — `0.2.0-pre.002`**  
+> Ce document conserve le cadrage historique établi pendant `0.0.3`. Les mentions ci-dessous de quatre pipelines fixes, de `ksp-worker-generic-materializer`, de `ksp-worker-domain-projector` ou d'un Core processing dépendant du décodage Program décrivent l'état de décision de cette ancienne release et **ne constituent plus l'architecture courante**. Depuis `0.2.0-pre.002`, les documents normatifs/actifs sont `docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md`, `docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md`, `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, `docs/plans/007-V0_2_0_SERIES_PLANNING.md` et les règles associées. Le modèle courant est `RAW -> CORE -> DECODE -> SPECIALIZED`, RAW/CORE ne dépendent pas d'un decoder Program, et les capacités de DECODE/SPECIALIZED sont introduites verticalement groupe par groupe.
+
 ## Mission
 
 Transformer le brainstorming KSP en architecture, règles, inventaire et plan suffisamment précis pour ouvrir la première série fonctionnelle `0.1.x` sans développement fonctionnel prématuré.
@@ -15,7 +18,7 @@ Transformer le brainstorming KSP en architecture, règles, inventaire et plan su
 
 Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy), `pre.006` (Data/Materialization/Store), `pre.007` (Acquisition/Workers/Jobs), `pre.008` (Apps/Services/Scenarios/Control) et `pre.009` (Functional Release Sequence) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
 
-## Décisions structurantes actuelles
+## Décisions structurantes à la clôture de `0.0.3` — historique
 
 - `0.1.x`, `0.2.x`, etc. sont des séries fonctionnelles, pas des unités de session.
 - Chaque release concrète d'une série est dimensionnée séparément.

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 25 -->
+<!-- version: 29 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -349,120 +349,207 @@ Par défaut :
 - prompt de la release suivante ;
 - vérification de cohérence des versions.
 
-# Série `0.2.x` — ordre candidat uniquement
+# Série `0.2.x` — accès Solana, Wallet et contrats initiaux
 
-`0.2.x` ouvre les capacités Solana N2.
+`0.2.0` est publiée stable par `0.2.0-rel.001`. `pre.002` a fixé le début de la séquence fonctionnelle suivante et `pre.003` en a réalisé l'audit final de cohérence :
-
-L'ordre exact des numéros n'est **pas figé** en `0.0.3`.
-
-Ordre candidat à réévaluer à l'approche de la série :
 
 ```text
-wallet foundation
+0.2.1  on-chain transport HTTP foundation
-    -> wallet specialized app
+0.2.2  wallet foundation (.kspwallet)
-
+0.2.3  Wallet Desk
-on-chain transport foundation
+0.2.4  standard Solana WebSocket
-    -> specialized transport/demo validation
+0.2.5  Helius LaserStream WebSocket
-
+0.2.6  Yellowstone gRPC standard foundation
-interface/wire foundation
+0.2.7  off-chain price transport
-    -> first concrete Program surface
+0.2.8  price visualization desk
-
+0.2.9  interface/wire foundation
-program-api / program-lib
+0.2.10 program-api foundation
-    -> first real decoder + ProgramExecutionPreparer + registry validation
-
-execution-policy-api / execution-lib
-    -> first real execution cycle
-
-scenario/demo validating the complete path
 ```
 
-Wallet, Transport et Interface sont en grande partie indépendants ; leur ordre précis peut donc être réordonné selon le premier cas fonctionnel choisi.
+Cette séquence est motivée par les dépendances fonctionnelles : un Wallet Desk utile doit pouvoir lire le solde du wallet, donc HTTP précède Wallet ; les transports live arrivent ensuite ; Interface/Program sont préparés avant les couches de données décodées.
 
-`ksp-offchain-transport-lib` reste need-driven.
+## `0.2.1` — HTTP Solana foundation
 
-# Série `0.3.x` — ordre candidat uniquement
+Mission : créer `ksp-onchain-transport-lib` avec une surface HTTP JSON-RPC complète et indépendante de Config/Store/Program.
 
-Direction :
+Inclure :
+
+- settings publics transport ;
+- endpoint/provider/cluster ;
+- pools logiques ;
+- rôles/capabilities/request kinds ;
+- priorités/limites/concurrence ;
+- timeout/retry/backoff ;
+- JSON-RPC ;
+- méthodes read et write/execution technique ;
+- statut centralisé `stable/deprecated/unstable` ;
+- warning runtime KSP pour deprecated/obsolete encore fonctionnel et unstable/experimental ;
+- document Config standard Transport + adapter dans `ksp-config-lib`, sans dépendance Transport -> Config.
+
+La documentation officielle actuelle de la surface ciblée doit être inventoriée exhaustivement dans `pre.001`.
+
+## `0.2.2` — Wallet foundation
+
+Mission : créer `ksp-wallet-lib` et le format `.kspwallet`.
+
+Inclure protection du secret, pubkey/identity, signature, import/export extensible, changement de mot de passe et publication sûre.
+
+Exclure : temporary wallet JSON historique et `WalletPolicy`.
+
+## `0.2.3` — Wallet Desk
+
+Mission : valider Config composite + `.kspwallet` + transport HTTP dans une application Tauri mince.
+
+Le solde d'un wallet constitue un premier cas de validation réseau obligatoire.
+
+## `0.2.4` — WebSocket Solana standard
+
+Mission : couvrir la surface WebSocket standard officielle ciblée.
+
+Une URL peut avoir plusieurs sessions physiques ; une session peut avoir plusieurs subscriptions. Un pool automatique de sessions est reporté jusqu'à besoin concret.
+
+## `0.2.5` — Helius LaserStream WebSocket
+
+Mission : étendre le moteur WebSocket standard avec les opérations/filtres/capabilities Helius ciblés sans copier le client.
+
+## `0.2.6` — Yellowstone gRPC standard
+
+Mission : introduire un backend Yellowstone standard/provider-neutral.
+
+Le `pre.001` est un gate de sizing : inventorier toute la surface normative cible et scinder la release avant implémentation si sa clôture dans une session paraît incertaine.
+
+Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après les priorités fondatrices.
+
+## `0.2.7` / `0.2.8` — Off-chain price + app
+
+`0.2.7` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
+
+`0.2.8` ajoute une petite application desk de visualisation/validation.
+
+Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.
+
+## `0.2.9` — Interface foundation
+
+`ksp-interface-lib` devient la façade wire officielle et expose une API publique wire utilisable par les implementations officielles et externes.
+
+Aucune `ksp-interface-api` séparée n'est retenue pour l'instant.
+
+## `0.2.10` — Program API foundation
+
+Introduire `ksp-program-api`, sans suffixe `-lib`, comme contrat d'extension Program.
+
+`ksp-program-lib` et les vertical slices réels arrivent plus tard.
+
+# Architecture durable : RAW -> CORE -> DECODE -> SPECIALIZED
+
+La chaîne de données est :
 
 ```text
-store-api + PostgreSQL store foundation
+D1 RAW
-    |
+ -> D2 CORE
-    v
+ -> D3 DECODE
-D1 raw persistence
+ -> D4 SPECIALIZED
-    |
-    v
-specialized Store app
-    |
-    v
-worker-api / job-api
-    |
-    v
-raw-ingestion pipeline
-    |
-    +--> raw-retriever service
-    |
-    +--> backfill job
 ```
 
-Les contrats Materializer et les frontières D2/D3/D4 sont introduits lorsque les sorties Program/Core réelles nécessaires existent.
+RAW et CORE ne nécessitent aucun decoder Program.
 
-Store/D1/acquisition peuvent donc être validés avant une matérialisation complète.
+`RAW -> CORE` est une normalisation générique Solana ; le premier decoder intervient à `CORE -> DECODE`.
 
-# Séries suivantes
+# Série `0.3.x` — RAW / acquisition persistée
 
-Les directions restent celles du roadmap :
+Début décidé :
 
 ```text
-0.4.x  Core/SPL/metadata + scenarios/demos
+0.3.1  ksp-store-api + ksp-store-lib, RAW only
-0.5.x  Anchor + protocoles trading
+0.3.2  ksp-interface-lib, wires génériques acquisition/CORE
-0.6.x  processing autonome D1 -> D4
+0.3.3  ksp-job-api + backfill
-0.7.x  Trading Intelligence
+0.3.4  application backfill/RAW
-0.8.x+ trading opérationnel + explorers + expansion produits
 ```
 
-Ces séries sont des objectifs fonctionnels, pas un calendrier contractuel.
+La suite de la série termine la couche RAW avec worker/service live et outils d'exploitation utiles avant l'ouverture de CORE.
+
+`0.3.1` ne doit pas créer par anticipation les modèles/tables DECODE/SPECIALIZED.
+
+# Série CORE suivante
+
+Objectif : rendre CORE exploitable sans aucun decoder Program :
+
+```text
+RAW persisted
+ -> Solana generic normalization
+ -> CORE persistence
+ -> RAW->CORE replay/backfill
+ -> CORE worker/service
+ -> CORE inspection/control app
+```
+
+# Séries DECODE/SPECIALIZED/EXECUTION suivantes
+
+À partir du décodage, KSP progresse par vertical slices complets et non par grandes couches de crates isolées :
+
+```text
+wire
+ -> decode
+ -> materialize
+ -> specialized projection si utile
+ -> execution preparation
+ -> execution policy
+ -> execute
+ -> Devnet scenario
+```
+
+Ordre prioritaire :
+
+```text
+Solana Core Programs
+ -> SPL token/trading
+ -> token metadata
+ -> Anchor
+ -> Meteora
+ -> Raydium
+ -> Pump
+ -> Orca
+ -> Market Desk V1
+ -> Jupiter/OKX routing
+ -> Market Desk V2
+ -> trading-adjacent
+ -> general decoding
+```
+
+Un programme satellite nécessaire reste dans son groupe protocolaire : Pump fee avec Pump, Meteora vaults avec Meteora, etc.
+
+SPM est reporté au décodage généraliste ultérieur.
+
+# Market Desk
+
+Après les DEX prioritaires, introduire une petite `ksp-app-market-desk` consommant les projections KSP pour afficher tokens, pools, liquidité, trades, prix, volumes et OHLC.
+
+Après Jupiter/OKX, enrichir la même app avec routes, legs, DEX impliqués, fees/slippage et quote/execution lorsque disponible.
+
+L'app ne réimplémente pas les SDK/protocoles DEX ; elle consomme les faits SPECIALIZED normalisés.
+
+# Discipline de sizing
+
+Chaque prerelease vise environ 15–20 minutes de travail effectif.
+
+Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule session de chat. Si `pre.001` montre que ce n'est pas réaliste, scinder la release avant implémentation fonctionnelle lourde.
 
 # Progression de la série `0.1.x`
 
-La première release fonctionnelle est :
+Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
+
+# Clôture stable de `0.2.0` et ouverture de `0.2.1`
+
+`0.2.0` a été ouverte par :
 
 ```text
-0.1.1 — Core foundation
-```
-
-Son prompt historique d'ouverture reste :
-
-```text
-prompts/001-V0_1_1_START_PROMPT.md
-```
-
-`0.1.1-rel.001` publie la surface Core stable après validation complète de `pre.005`. Le commit de release reçoit le tag `v0.1.1`. La release suivante s'ouvre avec :
-
-```text
-0.1.2 — Logging foundation
-prompts/002-V0_1_2_START_PROMPT.md
-```
-
-## Ouverture de `0.2.0`
-
-Après publication stable de `0.1.4`, la session suivante s’ouvre avec :
-
-```text
-0.2.0-pre.001
 prompts/005-V0_2_0_START_PROMPT.md
 ```
 
-`0.2.0` est une **release intermédiaire de cadrage de la série `0.2.x`**. Sa mission n'est pas de choisir immédiatement un premier composant N2 à implémenter, mais de reprendre méthodiquement les capacités pertinentes de `khadhroony-bot3` et de définir le plan de migration/refondation de la série.
+`0.2.0-pre.001` a construit la première cartographie. `0.2.0-pre.002` a fixé la trajectoire ci-dessus. `0.2.0-pre.003` corrige les décisions résiduelles supersédées, complète les fiches de release et finalise :
 
-La série `0.2.0` doit notamment produire :
+```text
-
+prompts/006-V0_2_1_START_PROMPT.md
-- un inventaire des fonctionnalités `khadhroony-bot3` pertinentes pour `0.2.x` ;
+```
-- pour chaque capacité, une décision explicite `reprendre / adapter / refondre / abandonner / ajouter` ;
-- les écarts entre les contrats historiques et les règles KSP déjà stabilisées en `0.1.x` ;
-- une cartographie des dépendances entre Wallet, transport on-chain, Interface/wire, Program API/Program, policy/execution et les éventuels besoins off-chain ;
-- les nouvelles fonctionnalités nécessaires qui n'existaient pas dans bot3 ou dont le contrat doit être modifié ;
-- le découpage concret du reste de `0.2.x` en releases bornées `0.2.1`, `0.2.2`, etc., avec ordre, objectifs, dépendances, hors-périmètre et critères de clôture ;
-- le prompt de démarrage de la première release fonctionnelle résultant de ce découpage.
-
-Le document directeur attendu pour cette session est `docs/plans/007-V0_2_0_SERIES_PLANNING.md`. Les numéros et périmètres des releases `0.2.1+` ne deviennent contractuels qu'après validation de ce plan.
 
+`0.2.0-rel.001` publie ce cadrage sous la version stable `0.2.0`. Après validation du commit de release et création du tag `v0.2.0`, le prompt `0.2.1` devient le point d'entrée actif de la série.

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md -->
-<!-- version: 25 -->
+<!-- version: 26 -->
 
 # Plan `0.1.4` — `ksp-app-config-desk`
 
@@ -228,7 +228,7 @@ Le layout frontend reprend la convention éprouvée de bot3 : les sources web so
 Les artefacts frontend construits doivent être séparés des sources. Pour `ksp-app-config-desk`, la destination contractuelle est fixée à :
 
 ```text
-../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
+../../../builds/khadhroony-solana-project/ksp-app-config-desk/dist
 ```
 
 Cette valeur est utilisée par `build.frontendDist` dans `tauri.conf.json`. `vite.config.ts` utilise la même destination comme `build.outDir` depuis son introduction en `pre.005`. Elle remplace le `../dist`/`../../dist` historique du gabarit bot3.

docs/plans/007-V0_2_0_SERIES_PLANNING.md

@@ -0,0 +1,731 @@
+<!-- file: docs/plans/007-V0_2_0_SERIES_PLANNING.md -->
+<!-- version: 5 -->
+
+# Plan `0.2.0` — audit bot3 et planification de la série `0.2.x`
+
+> **Statut : plan historique clôturé par `0.2.0-rel.001`.** La première release fonctionnelle suivante est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, ouverte avec `prompts/006-V0_2_1_START_PROMPT.md`.
+
+## 1. Statut et objectif
+
+`0.2.0` est une release intermédiaire de transition, d'audit et de planification. Elle ne livre pas directement une nouvelle capacité Solana complète ; elle transforme l'expérience de `khadhroony-bot3` en une trajectoire KSP cohérente, bornée et compatible avec les règles stabilisées en `0.1.x`.
+
+Base KSP attendue à l'ouverture de `0.2.0` :
+
+```text
+v0.1.4
+ksp-core-lib
+ksp-logging-lib
+ksp-config-lib
+ksp-app-config-desk
+```
+
+Snapshot bot3 principal audité pendant `0.2.0` :
+
+```text
+khadhroony-bot3_v0.5.3-pre.005-fix010.zip
+```
+
+Les fondations déjà refondues en `0.1.x` ne sont pas remigrées. Elles servent de contraintes pour juger les capacités historiques.
+
+## 2. Discipline de découpage
+
+KSP applique désormais deux garde-fous cumulatifs :
+
+1. une prerelease vise environ **15 à 20 minutes de travail effectif** ;
+2. une release fonctionnelle concrète doit être dimensionnée pour pouvoir être **ouverte, développée, validée et clôturée dans une seule session de chat**.
+
+Une release fonctionnelle ne doit pas être laissée volontairement ouverte pour être continuée dans une autre session.
+
+Le `pre.001` de chaque release sert donc aussi de **gate de dimensionnement**. Si l'inventaire réel montre que la release ne pourra vraisemblablement pas être clôturée dans la session, elle est scindée avant de commencer l'implémentation fonctionnelle lourde.
+
+Un nouveau besoin planifié produit une nouvelle prerelease. Un défaut livré dans une tranche existante produit un `fix.NNN` et n'est pas réécrit silencieusement.
+
+## 3. Méthode d'audit bot3
+
+Chaque capacité historique est étudiée en séparant cinq dimensions :
+
+1. **fonctionnalité** — besoin réellement utile ;
+2. **implémentation historique** — code et organisation bot3 ;
+3. **contrat public** — types, traits, invariants et comportements observables utiles ;
+4. **dépendance externe** — crate, protocole ou provider tiers ;
+5. **convention de projet** — choix local qui n'est pas intrinsèque au besoin.
+
+Les statuts de décision sont :
+
+- `reprendre` — reprendre le besoin/contrat utile ;
+- `adapter` — conserver le besoin avec ajustements de frontière/API ;
+- `refondre` — conserver le besoin mais remplacer l'architecture historique ;
+- `abandonner` — ne pas migrer ;
+- `ajouter` — besoin KSP absent ou insuffisant dans bot3.
+
+`reprendre` ne signifie jamais « copier mécaniquement le code ».
+
+## 4. Décisions stabilisées par `0.2.0-pre.002` / `pre.003`
+
+### 4.1 Ordre fonctionnel initial de la série
+
+Le premier besoin Wallet a montré qu'une application Wallet réellement testable doit pouvoir lire le solde d'une adresse. Le transport HTTP Solana doit donc précéder le Wallet.
+
+Le début de série est désormais ordonné ainsi :
+
+```text
+0.2.1  ksp-onchain-transport-lib — HTTP Solana foundation
+0.2.2  ksp-wallet-lib — format natif .kspwallet
+0.2.3  ksp-app-wallet-desk — Wallet + Config composite + HTTP
+0.2.4  ksp-onchain-transport-lib — WebSocket Solana standard
+0.2.5  ksp-onchain-transport-lib — Helius LaserStream WebSocket
+0.2.6  ksp-onchain-transport-lib — Yellowstone gRPC standard foundation
+0.2.7  ksp-offchain-transport-lib — première surface prix
+0.2.8  application desk de visualisation des prix
+0.2.9  ksp-interface-lib — première surface wire/API publique
+0.2.10 ksp-program-api — première API extensible Program
+```
+
+Les providers Yellowstone avancés ou spécifiques ne sont pas prioritaires dans cette première séquence. Ils seront ajoutés plus tard lorsque le besoin opérationnel le justifiera.
+
+### 4.2 Frontière Config / Transport
+
+`ksp-onchain-transport-lib` **ne dépend pas de `ksp-config-lib`**.
+
+Le transport possède ses contrats runtime publics : endpoints, pools, rôles, limites, timeouts, retry/backoff et autres settings réellement nécessaires.
+
+Lorsque KSP fournit un document standard Transport, son ownership reste dans `ksp-config-lib`, sur le même principe que Config -> Logging :
+
+```text
+config/std.transport.json
+        |
+        v
+ksp-config-lib
+        |
+        | adapter vers contrats publics Transport
+        v
+ksp-onchain-transport-lib
+```
+
+La dépendance inverse est interdite :
+
+```text
+ksp-onchain-transport-lib -X-> ksp-config-lib
+```
+
+Les applications, workers et jobs peuvent aussi construire directement les settings publics du transport sans utiliser Config.
+
+### 4.3 Couverture documentaire complète du transport
+
+Pour toute surface de transport officiellement ciblée par une release, KSP doit inventorier puis implémenter **toutes les méthodes/opérations exposées par la documentation normative sélectionnée**, sauf impossibilité technique explicitement documentée.
+
+Chaque méthode/opération est classée au minimum :
+
+```text
+Stable
+Deprecated / Obsolete mais encore fonctionnelle
+Unstable / Experimental
+```
+
+Règles runtime :
+
+- `Stable` : comportement normal ;
+- `Deprecated/Obsolete` encore fonctionnelle : API conservée + `warn` via `ksp-logging-lib` lors de son utilisation ;
+- `Unstable/Experimental` : API disponible + `warn` via `ksp-logging-lib` lors de son utilisation.
+
+La metadata de statut doit être centralisée afin d'éviter des warnings codés en dur de manière dispersée.
+
+Une méthode supprimée du protocole et réellement non utilisable n'est pas simulée artificiellement ; son historique peut rester documenté.
+
+### 4.4 HTTP : pools et rôles
+
+Le transport HTTP doit reprendre/refondre les besoins utiles de bot3 :
+
+- JSON-RPC ;
+- endpoints nommés ;
+- provider/cluster metadata ;
+- activation/désactivation ;
+- pool logique d'endpoints ;
+- rôles ;
+- priorités ;
+- request kinds/capabilities ;
+- rate limits et burst lorsque configurés ;
+- concurrence maximale ;
+- pause/backoff après limitation ;
+- timeouts ;
+- retry transport borné ;
+- health/snapshots utiles ;
+- méthodes read **et** write/execution technique documentées.
+
+Le pool HTTP est un pool **logique d'endpoints/clients**. KSP ne réimplémente pas un gestionnaire bas niveau de sockets que la bibliothèque HTTP sait déjà gérer.
+
+### 4.5 WebSocket : session avant pool automatique
+
+Une URL WebSocket doit pouvoir avoir plusieurs sessions physiques simultanées :
+
+```text
+endpoint URL
+    1 -> N sessions
+
+session
+    1 -> N subscriptions
+```
+
+Cette capacité est nécessaire pour permettre ultérieurement l'isolation de familles de subscriptions, des limites provider différentes, des reconnects indépendants ou une répartition de charge.
+
+En revanche, `0.2.4` ne doit pas créer par anticipation un scheduler/pool automatique complexe de sessions tant qu'un besoin concret ne le démontre pas.
+
+Les concepts attendus sont d'abord du type :
+
+```text
+WsEndpoint
+WsSession
+WsSessionId
+WsSubscription
+WsSubscriptionId
+```
+
+Un éventuel `WsSessionPool`/routing automatique reste need-driven.
+
+### 4.6 Helius LaserStream WebSocket
+
+`0.2.5` n'est pas une copie du client WebSocket standard.
+
+Les extensions Helius doivent réutiliser le moteur/session/lifecycle WebSocket construit en `0.2.4` et ajouter uniquement les contrats, filtres, notifications et capabilities spécifiques nécessaires.
+
+Le modèle multi-session d'une même URL reste identique.
+
+### 4.7 Yellowstone gRPC
+
+`0.2.6` introduit un premier backend/client Yellowstone gRPC standard et provider-neutral.
+
+La release ne doit pas figer l'architecture autour de Helius, Triton, ERPC, Chainstack, Shyft ou d'un autre provider. Un provider disponible peut servir à la validation réseau, mais il reste un **environnement de test**, pas le propriétaire du contrat KSP.
+
+Le `pre.001` de `0.2.6` devra inventorier la surface normative Yellowstone réellement actuelle et appliquer le gate de dimensionnement. Si la couverture complète de la surface ciblée ne tient pas dans une release clôturable dans la session, elle sera divisée avant implémentation.
+
+Les adaptations/provider profiles plus avancés sont reportés après les fondations prioritaires.
+
+### 4.8 Fiches de releases `0.2.1+`
+
+Ces fiches complètent la simple séquence numérique. Elles sont **souples** : le `pre.001` de chaque release refait le sizing sur les dépendances et documentations réellement actuelles. Une estimation ne justifie jamais d'ouvrir une release dont la clôture dans la même session paraît incertaine.
+
+#### `0.2.1` — HTTP Solana foundation
+
+- **Mission :** créer `ksp-onchain-transport-lib` avec JSON-RPC HTTP Solana complet, settings publics, pool logique d'endpoints, rôles/capabilities/limites et adapter Config -> Transport.
+- **Périmètre :** index HTTP officiel courant, méthodes deprecated/obsolete encore réellement utilisables, éventuelles méthodes HTTP unstable/experimental documentées, read/write technique, timeouts, retry/backoff, health et observabilité.
+- **Hors périmètre :** Wallet, WebSocket, LaserStream, gRPC, Store, Program, orchestration d'exécution.
+- **Dépendances :** fondations `0.1.x`; `ksp-config-lib` peut dépendre des contrats Transport pour l'adapter, jamais l'inverse.
+- **Clôture :** matrice documentaire exhaustive et testée, ownership propre, warnings de statut, pools/rôles validés, README/USAGE et prompt `0.2.2`.
+- **Estimation souple :** environ 8–12 prereleases courtes **si** le gate `pre.001` confirme qu'elles restent clôturables dans une seule session ; sinon scinder avant implémentation lourde.
+
+#### `0.2.2` — Wallet foundation
+
+- **Mission :** créer `ksp-wallet-lib` et le format natif `.kspwallet`.
+- **Périmètre :** création/ouverture, protection du secret, identité/pubkey, signature, changement de mot de passe, atomicité/no-clobber, import/export extensible et premiers formats réellement validés.
+- **Hors périmètre :** `WalletPolicy`, wallet JSON temporaire bot2/bot3, UI Tauri, lecture de solde réseau.
+- **Dépendances :** Core/Logging et primitives crypto/signature nécessaires ; aucun besoin de dépendre de Transport pour le cœur Wallet.
+- **Clôture :** format documenté/testé, secret non exposé, import/export round-trip retenu, README/USAGE et prompt Wallet Desk.
+- **Estimation souple :** environ 5–8 prereleases.
+
+#### `0.2.3` — `ksp-app-wallet-desk`
+
+- **Mission :** valider en Tauri Config composite + Wallet + HTTP.
+- **Périmètre :** sélection/ouverture de wallet, identité/pubkey, affichage du solde réel via `getBalance`, opérations Wallet utiles à la première UI, instrumentation Logging et modèle Tauri Config Desk.
+- **Hors périmètre :** WebSocket, trading, execution policy, duplication de cryptographie ou JSON-RPC dans l'app.
+- **Dépendances :** `0.2.1`, `0.2.2`, Config Desk/Tauri conventions.
+- **Clôture :** flux opérateur bout en bout sur un endpoint réel configurable, secrets protégés, build Tauri final exécuté en dernière opération de validation.
+- **Estimation souple :** environ 5–8 prereleases.
+
+#### `0.2.4` — WebSocket Solana standard
+
+- **Mission :** ajouter la surface WebSocket Solana standard complète au transport.
+- **Périmètre :** sessions persistantes, subscriptions/unsubscriptions/notifications documentées, reconnexion bornée, plusieurs sessions possibles sur une même URL, plusieurs subscriptions par session.
+- **Hors périmètre :** scheduler/pool automatique complexe de sessions, Helius-specific, Yellowstone.
+- **Dépendances :** `0.2.1` et contrats Transport déjà stabilisés.
+- **Clôture :** matrice WS exhaustive, lifecycle/reconnect/tests réseau opt-in et warnings pour toute surface unstable/deprecated concernée.
+- **Estimation souple :** environ 5–8 prereleases.
+
+#### `0.2.5` — Helius LaserStream WebSocket
+
+- **Mission :** étendre le moteur WS standard avec la surface Helius ciblée sans dupliquer le client.
+- **Périmètre :** opérations/filtres/notifications/capabilities Helius documentés et réellement disponibles au moment de la release.
+- **Hors périmètre :** gRPC LaserStream, autres providers, shred delivery.
+- **Dépendances :** `0.2.4`.
+- **Clôture :** extensions isolées du moteur commun, matrice Helius, tests opt-in selon credentials disponibles, absence de secret dans les logs.
+- **Estimation souple :** environ 3–5 prereleases.
+
+#### `0.2.6` — Yellowstone gRPC standard foundation
+
+- **Mission :** introduire un client/backend Yellowstone standard et provider-neutral.
+- **Périmètre :** surface normative retenue à `pre.001`, connexion/auth metadata générique, stream/subscription, filtres et lifecycle nécessaires.
+- **Hors périmètre :** profils commerciaux spécifiques Helius/Triton/ERPC/Chainstack/Shyft, shred/deshred et optimisations provider-only.
+- **Dépendances :** transport foundation ; aucun provider ne devient propriétaire du contrat.
+- **Clôture :** matrice protocolaire, test contre au moins un endpoint réellement accessible lorsque possible, comportement provider-neutral documenté.
+- **Estimation souple :** environ 4–7 prereleases, avec gate de découpage obligatoire si la surface normative courante dépasse ce qui est raisonnablement clôturable dans la session.
+
+#### `0.2.7` — Off-chain price transport
+
+- **Mission :** créer `ksp-offchain-transport-lib` sur un premier besoin réel de prix.
+- **Périmètre :** abstraction de lecture de prix, premier provider, au minimum SOL/USD et SOL/EUR, erreurs/timeouts/observabilité et settings publics nécessaires.
+- **Hors périmètre :** metadata HTTP/IPFS/Arweave, quotes/routing, agrégation multi-provider complexe.
+- **Dépendances :** fondations Core/Logging ; indépendante du transport on-chain sauf composition applicative.
+- **Clôture :** provider interchangeable derrière le contrat retenu, prix typés/testés, README/USAGE.
+- **Estimation souple :** environ 3–5 prereleases.
+
+#### `0.2.8` — Price Desk
+
+- **Mission :** valider le transport off-chain dans une petite application Tauri.
+- **Périmètre :** Config, sélection/refresh des paires supportées, affichage des prix et provenance/état utiles.
+- **Hors périmètre :** Market Desk DEX/OHLC, trading et metadata.
+- **Dépendances :** `0.2.7` + conventions Tauri stabilisées.
+- **Clôture :** UI mince fonctionnelle, refresh observable, erreurs sûres et build Tauri final.
+- **Estimation souple :** environ 3–5 prereleases.
+
+#### `0.2.9` — `ksp-interface-lib` foundation
+
+- **Mission :** ouvrir la façade wire officielle KSP et son API publique utilisable aussi par des crates externes.
+- **Périmètre :** organisation wire, règles réexport/wrapper/réimplémentation compatible, premiers types/interfaces Solana réellement nécessaires et canaries de compatibilité.
+- **Hors périmètre :** inventaire exhaustif de tous les protocoles Solana/SPL/Metaplex, Program implementations complètes.
+- **Dépendances :** Core et dépendances wire externes explicitement retenues/centralisées au workspace.
+- **Clôture :** API publique cohérente avec les implémentations internes, aucune dépendance métier externe inutile dans les couches supérieures, README/USAGE.
+- **Estimation souple :** environ 4–7 prereleases.
+
+#### `0.2.10` — `ksp-program-api` foundation
+
+- **Mission :** introduire le contrat extensible Program avant les vertical slices réels.
+- **Périmètre :** identité/capabilities, contrats de décodage et préparation d'exécution nécessaires à une implémentation externe, support/deprecation machine-readable et extension ouverte.
+- **Hors périmètre :** `ksp-program-lib` exhaustif, materializers, execution engine, scénarios.
+- **Dépendances :** Core + `ksp-interface-lib` lorsque les contrats wire le nécessitent.
+- **Clôture :** une implémentation externe fictive/test démontre que l'API n'impose pas `ksp-program-lib`; contrats documentés et prompt de la série suivante préparé.
+- **Estimation souple :** environ 3–5 prereleases.
+
+### 4.9 Audit final `0.2.0-pre.003`
+
+L'audit final de la base Git `0.2.0-pre.002` a relevé et corrige les écarts suivants avant release stable :
+
+- collisions d'identifiants normatifs dans `RULES_KSP.md` (`KSP-TRANSPORT-001`, `KSP-DATA-001`, `KSP-DATA-002`) ;
+- ancienne règle `KSP-JOB-009` imposant encore trois jobs de replay globaux incompatibles avec la progression verticale décidée ;
+- ancien diagramme `W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4` dans `010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md`, encore susceptible d'être lu comme quatre workers globaux imposés ; il est remplacé par les frontières durables D1–D4 et une granularité worker need-driven ;
+- entrées `IDEAS.md` encore formulées autour de `generic-materialization` / `domain-projection` et d'un type global `DomainProjector` ;
+- TODO Wallet bot3 utiles non encore reportés explicitement : Backpack, Trust Wallet, Solflare keystore, Base app/ex-Coinbase Wallet et distinction Coinbase Developer Platform ;
+- absence dans le plan directeur des fiches mission/périmètre/hors-périmètre/dépendances/clôture/estimation demandées pour chaque release `0.2.1+`.
+
+Un spot-check externe effectué le **2026-08-17** sur la documentation officielle Solana observe 52 méthodes dans l'index HTTP courant et 14 noms dans la section officielle Deprecated Methods. L'inventaire bot3 contient les 52 noms de l'index courant, mais pas la surface deprecated séparée. Cette observation confirme l'intérêt de réutiliser l'inventaire fonctionnel bot3 tout en imposant à `0.2.1-pre.001` un nouvel audit officiel complet ; **les nombres observés ici ne deviennent pas un contrat durable**.
+
+## 5. Wallet
+
+### 5.1 `0.2.2` — format natif `.kspwallet`
+
+Le format KSP devient :
+
+```text
+.kspwallet
+```
+
+L'ancien `.kswallet` de bot3 est une référence historique, pas le nom KSP final.
+
+Les fonctionnalités utiles à reprendre/refondre comprennent :
+
+- création ;
+- ouverture/déverrouillage ;
+- identité publique/pubkey sans exposition du secret ;
+- secret chiffré ;
+- signature ;
+- mot de passe ;
+- changement de mot de passe sans changement de keypair ;
+- publication atomique/no-clobber ;
+- redaction/zeroization adaptées ;
+- alias/organisation ;
+- import/export ;
+- inspection d'un format externe sans import lorsque pertinent ;
+- migrations/conversions utiles.
+
+### 5.2 Abandon du wallet temporaire JSON
+
+Le `TemporaryWalletStore`/wallet JSON temporaire de bot3 est un héritage de bot2 utilisé principalement pour les anciens scénarios.
+
+Il n'est pas migré dans KSP.
+
+Les futurs scénarios utilisent de vrais `.kspwallet`, y compris des wallets dédiés Devnet/tests si nécessaire.
+
+### 5.3 `WalletPolicy`
+
+`WalletPolicy` ne fait pas partie de `ksp-wallet-lib`.
+
+Les règles de dépense, réseau, programme, simulation, limites ou autorisations appartiennent à la future execution policy :
+
+```text
+ksp-execution-policy-api
+```
+
+Une policy petite et spécifique à un scenario/orchestrateur peut être implémentée directement dans sa crate. Une ou plusieurs bibliothèques de policies communes ne seront créées que lorsque des comportements réellement réutilisables le justifieront.
+
+### 5.4 Import/export extensible
+
+`0.2.2` doit conserver une architecture d'import/export extensible et fournir les formats réellement nécessaires à sa validation.
+
+Les formats additionnels à étudier restent dans `docs/IDEAS.md` tant qu'ils ne sont pas engagés. Le projet ne doit pas ajouter toutes leurs dépendances « au cas où ».
+
+## 6. `0.2.3` — Wallet Desk
+
+`ksp-app-wallet-desk` est une application Tauri mince construite selon le modèle validé par Config Desk.
+
+Elle doit valider ensemble :
+
+```text
+ksp-config-lib
++ configuration composite
++ ksp-wallet-lib
++ ksp-onchain-transport-lib HTTP figé par 0.2.1
+```
+
+La première version doit au minimum permettre d'observer l'identité d'un wallet et son solde via le transport HTTP afin que le Wallet ne soit pas validé uniquement hors réseau.
+
+L'application ne réimplémente ni cryptographie Wallet, ni JSON-RPC, ni Config.
+
+## 7. Off-chain transport
+
+### 7.1 Première surface volontairement petite
+
+`0.2.7` introduit `ksp-offchain-transport-lib` avec un premier besoin réel : récupération de prix, au minimum :
+
+```text
+SOL/USD
+SOL/EUR
+```
+
+La bibliothèque doit séparer le besoin « lire un prix » de l'API propriétaire du premier provider retenu.
+
+La première release n'a pas à introduire immédiatement IPFS, Arweave, metadata HTTP, quotes/routing ou tous les providers imaginables.
+
+### 7.2 Application prix
+
+`0.2.8` introduit une petite application desk utilisant Config + `ksp-offchain-transport-lib` pour visualiser les prix et valider la capacité hors chaîne dans une UI réelle.
+
+Les readers/retrievers metadata HTTP/IPFS/Arweave arriveront lorsqu'un groupe Metadata en aura réellement besoin.
+
+## 8. `ksp-interface-lib`
+
+### 8.1 Une seule crate pour l'instant
+
+`ksp-interface-lib` reste la façade wire officielle KSP.
+
+Aucune crate `ksp-interface-api` séparée n'est décidée actuellement.
+
+La bibliothèque doit toutefois exposer une **API publique wire suffisamment propre** pour qu'une crate Program externe puisse utiliser les mêmes contrats que les implémentations officielles KSP.
+
+Ainsi :
+
+```text
+ksp-interface-lib
+    = implémentations/réexports wire officiels
+    + API publique wire réutilisable
+```
+
+Une extension externe peut expérimenter contre cette API avant intégration officielle dans KSP.
+
+Si une future contrainte de dépendance démontre qu'un split `ksp-interface-api` est réellement nécessaire, la décision pourra être revue selon `KSP-API-007`. La symétrie de nommage ne suffit pas.
+
+### 8.2 Interfaces officielles et wires compatibles
+
+La politique reste :
+
+- réutiliser/réexporter de manière contrôlée une interface officielle suffisamment stable et compatible ;
+- wrapper lorsqu'une frontière publique KSP est nécessaire ;
+- posséder/réimplémenter une définition wire compatible lorsqu'une bibliothèque protocolaire externe est instable, ancienne, lourde ou impose des générations de dépendances incompatibles ;
+- supporter au besoin des anciens wires réellement observables sans forcer le workspace entier à utiliser les anciennes bibliothèques.
+
+Metaplex Token Metadata reste un exemple important de wire à posséder/compatibiliser plutôt que d'imposer directement `mpl-token-metadata` aux couches supérieures.
+
+## 9. `ksp-program-api`
+
+La nomenclature canonique est :
+
+```text
+ksp-program-api
+ksp-program-lib
+```
+
+et jamais `ksp-program-api-lib`.
+
+`ksp-program-api` est la crate de contrats extensibles. `ksp-program-lib` utilisera et implémentera ces contrats.
+
+Une future crate externe pourra également implémenter `ksp-program-api` sans dépendre de `ksp-program-lib`.
+
+`0.2.10` ouvre uniquement la première API Program ; les implémentations Program réelles sont décalées vers la progression verticale ultérieure.
+
+## 10. Architecture de données canonique
+
+La progression durable KSP est désormais exprimée comme :
+
+```text
+RAW
+ ↓
+CORE
+ ↓
+DECODE
+ ↓
+SPECIALIZED
+```
+
+Les aliases durables D1–D4 restent utilisables :
+
+```text
+D1 = RAW
+D2 = CORE
+D3 = DECODE / matérialisation générique décodée
+D4 = SPECIALIZED
+```
+
+### 10.1 RAW
+
+Acquisition suffisamment fidèle et replayable, avec provenance.
+
+Aucun décodage Program n'est requis.
+
+### 10.2 CORE
+
+Normalisation canonique **générique de la blockchain Solana** : blocs, slots, signatures, transactions/messages, comptes, instructions brutes, CPI, logs, meta et relations structurelles générales.
+
+CORE ne dépend pas du décodage d'un programme SPL/Metaplex/DEX.
+
+La transformation `RAW -> CORE` doit fonctionner même si aucun decoder Program n'existe.
+
+### 10.3 DECODE
+
+À partir de CORE commencent les interprétations Program/protocole.
+
+La frontière couvre successivement, selon le groupe :
+
+```text
+decoding
+    -> materialisation générique / journal durable
+```
+
+D3 conserve suffisamment de provenance/versioning pour rejouer les projections spécialisées sans refaire l'acquisition.
+
+### 10.4 SPECIALIZED
+
+D4 contient les projections queryables spécialisées : token facts, metadata assets, pools, trades/swaps, positions, liquidité, prix, OHLC, routes et autres faits de domaine.
+
+Les modèles spécialisés sont conçus par **faits métier génériques** lorsqu'une normalisation inter-protocoles est pertinente ; ils ne sont pas automatiquement découpés en tables `meteora_*`, `raydium_*`, etc.
+
+## 11. Ordre de développement par couches
+
+### 11.1 RAW et CORE : progression horizontale
+
+Les deux premières couches ne nécessitent pas de décodage Program.
+
+KSP peut donc les construire horizontalement jusqu'à disposer, pour chaque couche, de ses outils d'exploitation :
+
+```text
+persistence
+replay/backfill
+worker/service lorsque nécessaire
+application de contrôle/validation lorsque utile
+```
+
+Le principe est : terminer une couche exploitable avant d'ouvrir la suivante.
+
+### 11.2 À partir de DECODE : progression verticale par groupe
+
+À partir du premier groupe Program, KSP ne doit pas développer tous les decoders, puis tous les materializers, puis toutes les executions.
+
+Chaque groupe progresse verticalement :
+
+```text
+interfaces/wires nécessaires
+    -> decoding
+    -> materialisation générique
+    -> materialisation/projection SPECIALIZED si utile
+    -> préparation d'exécution
+    -> execution policy nécessaire
+    -> exécution
+    -> scénarios Devnet / validation
+```
+
+Puis seulement le groupe prioritaire suivant devient le centre du travail.
+
+Cette règle évite une grande surface horizontalement incomplète.
+
+## 12. Ordre prioritaire des groupes Program
+
+L'ordre fonctionnel pressenti après RAW/CORE est :
+
+1. **Solana Core Programs** utilisés transversalement ;
+2. **SPL orienté token/trading** : Token, ATA, Token-2022 et extensions pertinentes ;
+3. **Metadata orientées token** : Metaplex Token Metadata + metadata Token-2022 ;
+4. **Anchor** nécessaire aux protocoles suivants ;
+5. **Meteora** ;
+6. **Raydium** ;
+7. **Pump** ;
+8. **Orca** ;
+9. première **Market Desk** ;
+10. **routing** : Jupiter puis OKX et autres besoins réels ;
+11. enrichissement Market Desk ;
+12. programmes **trading-adjacent** indépendants ;
+13. reste du décodage généraliste Solana.
+
+L'ordre exact entre Meteora/Raydium/Pump/Orca pourra être ajusté selon le trafic, les données réellement observées et les possibilités de validation au moment de leur ouverture, sans casser la règle de vertical slice.
+
+SPM est volontairement repoussé vers le décodage généraliste ultérieur ; il n'est pas inclus dans le premier groupe metadata token.
+
+## 13. Programmes satellites d'un protocole
+
+Un composant nécessaire à la compréhension ou au fonctionnement d'un protocole reste **dans le groupe de ce protocole**, même s'il n'est pas lui-même l'AMM/DEX principal.
+
+Exemples :
+
+```text
+Meteora
+    + vaults nécessaires
+    + fee/state programs nécessaires
+    + positions/bin arrays/auxiliaires
+
+Pump
+    + fee program
+    + launch/bonding/pool/state auxiliaire
+```
+
+Même principe pour Raydium, Orca et les futurs protocoles.
+
+La catégorie `trading-adjacent` ne sert jamais de poubelle pour reporter les satellites d'un protocole déjà ciblé.
+
+`trading-adjacent` désigne des programmes indépendants utiles au trading : oracles, vesting/locks indépendants, lifecycle token, signaux/risk ou autres capacités transversales.
+
+## 14. Market Desk progressive
+
+Une petite application marché spécialisée doit apparaître **après le premier ensemble Meteora/Raydium/Pump/Orca**, avant le routing si le vertical slice DEX fournit déjà suffisamment de données utiles.
+
+Nom candidat actuel :
+
+```text
+ksp-app-market-desk
+```
+
+La V1 pourra visualiser notamment :
+
+- tokens ;
+- pools/markets ;
+- protocoles ;
+- liquidité ;
+- swaps/trades ;
+- volumes ;
+- prix ;
+- OHLC/candles ;
+- activité récente/live lorsque disponible ;
+- provenance/diagnostics utiles.
+
+L'application consomme les faits KSP normalisés/spécialisés. Elle ne réimplémente pas un client Meteora/Raydium/Pump/Orca dans l'UI.
+
+Les OHLC appartiennent aux matérialisations/projections SPECIALIZED : l'application les lit ; elle ne reconstruit pas toutes les candles à chaque rendu.
+
+Après Jupiter/OKX, la même application est enrichie avec :
+
+- routes ;
+- legs ;
+- DEX utilisés ;
+- quote vs execution lorsque disponible ;
+- fees/slippage ;
+- activité cross-DEX/routée.
+
+Plus tard elle pourra accueillir trading-adjacent, anomalies, indicateurs et outputs ML sans devenir prématurément l'application globale de KSP.
+
+## 15. Nouvelle trajectoire `0.3.x+`
+
+### `0.3.x` — RAW / acquisition persistée
+
+Début actuellement retenu :
+
+```text
+0.3.1  ksp-store-api + ksp-store-lib — modèles/persistence RAW uniquement
+0.3.2  ksp-interface-lib — extension des wires génériques nécessaires à acquisition/CORE
+0.3.3  ksp-job-api + ksp-job-backfill
+0.3.4  application spécialisée de backfill
+```
+
+La suite de `0.3.x` doit terminer la couche RAW avec les workers/services/apps utiles avant l'ouverture de CORE.
+
+`0.3.1` ne doit pas introduire prématurément les tables DECODE/SPECIALIZED.
+
+### Série suivante — CORE
+
+Après RAW :
+
+```text
+RAW -> CORE normalization
+persistence CORE
+replay RAW -> CORE
+worker/service CORE
+application de contrôle CORE
+```
+
+Cette couche reste indépendante des decoders Program.
+
+### Séries suivantes — vertical slices DECODE/SPECIALIZED/EXECUTION
+
+À partir de Solana Core Programs puis SPL/Metadata/Anchor/DEX, les séries seront découpées selon la taille réelle de chaque groupe et la règle « une release = une session ».
+
+Il est volontairement prématuré de figer maintenant chaque numéro jusqu'aux DEX.
+
+## 16. Matrice synthétique de décision
+
+| Capacité                        | Source bot3                     | Statut               | Propriétaire KSP                       | Release candidate      |
+|---------------------------------|---------------------------------|----------------------|----------------------------------------|------------------------|
+| HTTP JSON-RPC standard          | `ks-onchain-transport`          | refondre             | `ksp-onchain-transport-lib`            | `0.2.1`                |
+| Config transport standard       | `ks-config` transport           | adapter/refondre     | `ksp-config-lib` -> contrats Transport | `0.2.1`                |
+| Pools/rôles HTTP                | `ks-onchain-transport`          | reprendre/adapter    | `ksp-onchain-transport-lib`            | `0.2.1`                |
+| Wallet natif                    | `ks-wallet`                     | adapter/refondre     | `ksp-wallet-lib`                       | `0.2.2`                |
+| `.kswallet`                     | bot3                            | abandonner comme nom | `.kspwallet`                           | `0.2.2`                |
+| Temporary wallet JSON           | bot2/bot3                       | abandonner           | aucun                                  | —                      |
+| `WalletPolicy`                  | `ks-wallet`                     | déplacer/refondre    | execution policy                       | plus tard              |
+| Wallet Desk                     | desktop bot3 dispersé           | refondre             | `ksp-app-wallet-desk`                  | `0.2.3`                |
+| WebSocket standard              | `ks-onchain-transport`          | refondre             | `ksp-onchain-transport-lib`            | `0.2.4`                |
+| Multi-session même URL          | besoin KSP                      | ajouter              | `ksp-onchain-transport-lib`            | `0.2.4`                |
+| Pool automatique de sessions WS | —                               | à démontrer          | transport si besoin                    | IDEAS                  |
+| Helius LaserStream WS           | absent/incomplet bot3           | ajouter              | `ksp-onchain-transport-lib`            | `0.2.5`                |
+| Yellowstone gRPC                | absent                          | ajouter              | `ksp-onchain-transport-lib`            | `0.2.6`                |
+| Providers gRPC spécifiques      | absent                          | ajouter plus tard    | adapters/capabilities Transport        | IDEAS/futur            |
+| Prix SOL/USD, SOL/EUR           | absent                          | ajouter              | `ksp-offchain-transport-lib`           | `0.2.7`                |
+| Price Desk                      | absent                          | ajouter              | app spécialisée                        | `0.2.8`                |
+| Wire officiel                   | dispersé dans `ks-lib`/deps     | refondre             | `ksp-interface-lib`                    | `0.2.9`                |
+| API wire publique               | absent comme frontière claire   | ajouter              | `ksp-interface-lib`                    | `0.2.9`                |
+| Program extension contract      | `ks-lib` decoder/executor       | refondre             | `ksp-program-api`                      | `0.2.10`               |
+| Store RAW                       | `ks-store`                      | refondre             | `ksp-store-api`/`ksp-store-lib`        | `0.3.1`                |
+| Backfill                        | bot3 pipelines/jobs historiques | refondre             | `ksp-job-api` + job concret            | `0.3.3`                |
+| Market Desk                     | absent comme app KSP dédiée     | ajouter              | app spécialisée                        | après DEX prioritaires |
+
+## 17. Clôture de `0.2.0`
+
+`pre.001` a ouvert la méthode et la cartographie.
+
+`pre.002` a fixé la direction fonctionnelle principale de `0.2.x`, la stratégie RAW/CORE/DECODE/SPECIALIZED, la progression verticale Program, le dimensionnement de session et le premier prompt `0.2.1`.
+
+`pre.003` est la **dernière prerelease planifiée de `0.2.0`**. Elle réalise l'audit de cohérence final, corrige les règles résiduelles supersédées, complète les fiches de release demandées par le prompt d'ouverture, préserve les TODO bot3 utiles et finalise le prompt `0.2.1`.
+
+Aucune `pre.004` n'est prévue. Elle ne serait créée que si la validation de `pre.003` révélait un nouveau défaut ou une omission substantielle qui ne peut pas être honnêtement corrigée dans `rel.001`.
+
+`0.2.0-rel.001` publie le cadrage sans nouvelle décision architecturale :
+
+- `workspace.package.version = 0.2.0` ;
+- `0.2.0` est marqué stable dans ROADMAP/indices/plans ;
+- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
+- `deltas/0.2.0/rel.001.md` enregistre la publication ;
+- les validations finales de `pre.003` communiquées par le user sont reportées dans la matrice de clôture ;
+- le commit attendu est `v0.2.0-rel.001`, puis le tag stable Git `v0.2.0` ;
+- le prompt `0.2.1` reste inchangé et devient le prochain point d'entrée après le tag stable.
+
+La matrice de clôture durable est `docs/validation/002-V0_2_0_SERIES_PLANNING.md`.
+
+## 18. Première release fonctionnelle décidée : `0.2.1`
+
+La première release fonctionnelle de la série est désormais :
+
+```text
+0.2.1 — ksp-onchain-transport-lib / Solana HTTP foundation
+```
+
+Sa mission est de fournir la première frontière réseau Solana KSP réellement exploitable par Wallet, applications futures, acquisition RAW et execution technique ultérieure.
+
+Le prompt finalisé est :
+
+```text
+prompts/006-V0_2_1_START_PROMPT.md
+```
+
+Son contenu est finalisé par `0.2.0-pre.003`. Il devient le prompt de reprise applicable dès publication/tag stable de `v0.2.0`.

docs/rules/PROMPT_STRUCTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/PROMPT_STRUCTURE.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Structure des prompts KSP
 
@@ -41,6 +41,10 @@ Exemple : si `0.1.1` devient trop large, créer `0.1.2` plutôt que forcer tout
 
 Une série complète peut naturellement s'étendre sur de nombreuses sessions.
 
+Une **release concrète**, en revanche, doit être planifiée pour être ouverte et clôturée dans une seule session de chat. Une version volontairement laissée ouverte pour être reprise dans une autre session n'est pas un découpage acceptable.
+
+Si `pre.001` révèle qu'une clôture dans la session est incertaine, la release est scindée **avant l'implémentation fonctionnelle lourde**. Cette contrainte s'ajoute au budget de 15–20 minutes par prerelease ; elle ne le remplace pas.
+
 ## Structure recommandée d'un prompt
 
 1. Identité de la série et de la release concrète visée ;

docs/rules/RULES_DEPENDENCIES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_DEPENDENCIES.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Règles des dépendances KSP
 
@@ -88,26 +88,27 @@ Elles complètent les règles Rust générales et le graphe de `docs/architectur
 - **DEP-TRANSPORT-002** — Les providers on-chain normalisent leurs réponses dans des modèles KSP homogènes par catégorie de données avant exposition aux consommateurs.
 - **DEP-TRANSPORT-003** — Les modèles de transport ne réalisent pas de décodage métier/protocolaire et doivent rester facilement convertibles en DTO raw persistants.
 - **DEP-TRANSPORT-004** — Aucun `ksp-onchain-transport-api` ou `ksp-offchain-transport-api` global n'est créé dans l'architecture actuelle.
+- **DEP-TRANSPORT-005** — `ksp-onchain-transport-lib` et `ksp-offchain-transport-lib` ne dépendent pas de `ksp-config-lib` : ils possèdent leurs settings/runtime contracts publics, tandis qu'une couche de composition ou un adaptateur appartenant à Config traduit les documents de configuration vers ces contrats.
 
 ## Pipelines spécialisés
 
 - **DEP-PIPE-001** — KSP ne crée pas de `ksp-pipeline-lib` monolithique.
-- **DEP-PIPE-002** — Les pipelines spécialisés retenus pour les frontières durables sont `ksp-pipeline-raw-ingestion-lib`, `ksp-pipeline-core-processing-lib`, `ksp-pipeline-generic-materialization-lib` et `ksp-pipeline-domain-projection-lib`.
+- **DEP-PIPE-002** — Les frontières canoniques de processing sont `RAW -> CORE -> DECODE -> SPECIALIZED`. Une crate pipeline dédiée n'est créée que lorsqu'une logique doit réellement être réutilisée entre plusieurs lifecycle hosts (worker/job/app/test) ; aucune liste globale de quatre crates pipeline n'est imposée par symétrie.
 - **DEP-PIPE-003** — Un pipeline de processing dépend des APIs nécessaires à sa frontière et non des implémentations officielles correspondantes lorsque l'API permet l'injection/composition.
 - **DEP-PIPE-004** — Les pipelines spécialisés ne dépendent pas de `ksp-worker-api` ou `ksp-job-api`; worker et job possèdent le lifecycle.
 - **DEP-PIPE-005** — Worker live et job de replay/backfill réutilisent le même pipeline pour une même frontière durable afin d'éviter la duplication de logique.
 - **DEP-PIPE-006** — Le pipeline raw ingestion peut dépendre des modèles homogènes de `ksp-onchain-transport-lib` et de `ksp-store-api`, mais pas de `ksp-store-lib`.
-- **DEP-PIPE-007** — Le pipeline Core processing dépend de `ksp-program-api` et non de `ksp-program-lib`.
+- **DEP-PIPE-007** — La transformation `RAW -> CORE` est Solana-générique et ne dépend ni de `ksp-program-api`, ni de `ksp-program-lib`, ni de `ksp-materializer-api`; les premiers contrats Program interviennent seulement à partir de `CORE -> DECODE`.
-- **DEP-PIPE-008** — Les pipelines de matérialisation/projection dépendent de `ksp-materializer-api` et non de `ksp-materializer-lib`.
+- **DEP-PIPE-008** — À partir de `CORE -> DECODE`, les pipelines/processors verticaux peuvent dépendre de `ksp-program-api` et de `ksp-materializer-api` selon leur rôle, sans dépendre par défaut des implémentations officielles correspondantes lorsque l'injection/composition suffit. `DECODE -> SPECIALIZED` utilise de même les contrats de matérialisation/projection nécessaires sans imposer une implémentation globale unique.
 
 ## Worker / Job lifecycle
 
 - **DEP-WORKER-001** — `ksp-worker-control-lib` dépend de `ksp-worker-api` et ne dépend pas de `ksp-job-api`.
 - **DEP-WORKER-002** — Les workers de processing reconstruisent leur backlog depuis `ksp-store-api`/Store ; une notification ne suffit pas à prouver qu'un input a été traité.
-- **DEP-WORKER-003** — Les workers concrets peuvent dépendre de `ksp-store-lib` et des implémentations officielles Program/Materializer nécessaires à la composition.
+- **DEP-WORKER-003** — La logique réutilisable d'un worker/job dépend en priorité des APIs KSP (`ksp-store-api`, `ksp-program-api`, `ksp-materializer-api`, etc.) et reçoit les implémentations par composition. Le binaire/service mince peut câbler `ksp-store-lib` ou les implémentations officielles nécessaires sans transférer cet ownership à la logique du worker/job.
 - **DEP-JOB-001** — `ksp-job-api` ne dépend ni de `ksp-worker-api` ni de `ksp-worker-control-lib`.
 - **DEP-JOB-002** — Un orchestrateur futur peut consommer séparément les APIs/contrôles workers et jobs sans introduire un lifecycle parent commun.
-- **DEP-JOB-003** — Les jobs de replay réutilisent les pipelines des workers correspondants au lieu de dupliquer la logique D1 -> D2, D2 -> D3 ou D3 -> D4.
+- **DEP-JOB-003** — Lorsqu'une même transformation existe en live et en replay, jobs et workers réutilisent la même logique de transformation au lieu de dupliquer `RAW -> CORE`, `CORE -> DECODE` ou `DECODE -> SPECIALIZED`.
 
 ## Services, applications et control plane
 

docs/rules/RULES_KSP.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_KSP.md -->
-<!-- version: 30 -->
+<!-- version: 32 -->
 
 # Règles spécifiques à KSP
 
@@ -136,7 +136,7 @@
 - **KSP-WORKER-005** — `ksp-worker-raw-retriever` est le worker d'acquisition raw live/quasi-live. Il ne décode pas, ne matérialise pas et ne réalise pas de replay/backfill historique.
 - **KSP-WORKER-006** — `ksp-worker-raw-retriever` persiste les données raw puis notifie leur disponibilité selon les contrats de données normalisés.
 - **KSP-WORKER-007** — `ksp-worker-raw-retriever` doit pouvoir faire évoluer à chaud les listeners et la sélection des données qu'il rapatrie/stocke.
-- **KSP-WORKER-008** — Les workers de processing actuellement retenus sont `ksp-worker-core-processor`, `ksp-worker-generic-materializer` et `ksp-worker-domain-projector`; le dernier nom reste provisoire.
+- **KSP-WORKER-008** — Les workers de processing ne sont pas figés à l'avance sous une chaîne globale `core -> generic materializer -> domain projector`. RAW et CORE peuvent disposer de workers horizontaux propres à leur couche ; à partir de DECODE, les workers/processors sont introduits au besoin avec chaque groupe fonctionnel vertical afin que décodage, matérialisation, projection spécialisée et validation d'exécution évoluent ensemble.
 - **KSP-WORKER-009** — Les workers de processing utilisent notification comme wake-up mais reconstruisent leur backlog depuis le Store.
 - **KSP-WORKER-010** — `ksp-worker-raw-retriever` distingue une configuration desired et une configuration effective lors des reconfigurations à chaud.
 - **KSP-WORKER-011** — Un cursor de scan est une optimisation ; les processing outcomes durables constituent la preuve qu'un input a été traité pour un processor/version/capability.
@@ -156,7 +156,7 @@
 - **KSP-JOB-006** — D'autres jobs peuvent être introduits pour metadata, quotes ou autres travaux ponctuels lorsqu'un besoin réel le justifie.
 - **KSP-JOB-007** — Aucune `ksp-job-control-lib` commune n'est prévue actuellement ; elle ne sera créée que si une duplication concrète entre plusieurs jobs le justifie.
 - **KSP-JOB-008** — Le contrôle/gouvernance des jobs reste séparé du contrôle des workers.
-- **KSP-JOB-009** — Les jobs de replay retenus sont `ksp-job-replay-core`, `ksp-job-replay-generic-materialization` et `ksp-job-replay-domain-projection`.
+- **KSP-JOB-009** — Aucun inventaire global de jobs de replay DECODE/SPECIALIZED n'est figé à l'avance. `RAW -> CORE` peut introduire un job de replay Core lorsque la couche CORE est ouverte ; à partir de DECODE, les jobs de replay sont introduits avec les groupes/capacités verticaux qui en ont réellement besoin, sans imposer des jobs génériques `generic-materialization` / `domain-projection` pour tout Solana.
 - **KSP-JOB-010** — Les jobs de replay réutilisent exactement le pipeline spécialisé de la frontière correspondante.
 - **KSP-JOB-011** — Le backfill conserve un checkpoint de progression dans la source historique en plus des outcomes de persistence D1.
 - **KSP-JOB-012** — Replay normal/reprise et force replay sont deux intentions distinctes ; un force replay conserve provenance/historique et ne supprime pas silencieusement le résultat courant.
@@ -176,7 +176,7 @@
 ## Pipelines et scénarios
 
 - **KSP-PIPE-001** — KSP ne crée pas de `ksp-pipeline-lib` monolithique.
-- **KSP-PIPE-002** — Les quatre pipelines spécialisés retenus pour les frontières durables sont raw ingestion, Core processing, generic materialization et domain projection.
+- **KSP-PIPE-002** — Les frontières canoniques de données/processing sont `RAW -> CORE -> DECODE -> SPECIALIZED`. Les pipelines RAW et CORE peuvent être développés horizontalement jusqu'à leur acquisition/persistence/replay/worker/app ; à partir de DECODE, KSP progresse par groupes fonctionnels verticaux et ne pré-déclare pas une chaîne globale de crates pipeline pour tous les protocoles.
 - **KSP-PIPE-003** — Un pipeline spécialisé contient la logique réutilisable d'une frontière mais aucun lifecycle worker/job.
 - **KSP-PIPE-004** — Les pipelines utilisent les APIs Program/Materializer/Store lorsque ces frontières doivent être injectables ; les implémentations officielles sont composées par workers/jobs.
 - **KSP-PIPE-005** — Le traitement est at-least-once avec persistence idempotente et outcomes durables, plutôt qu'une promesse exactly-once distribuée.
@@ -253,3 +253,7 @@
 - **KSP-REL-013** — Toute bibliothèque KSP considérée comme complétée possède un `USAGE.md` durable, sans notes de version, présentant sa surface publique et un exemple d'utilisation pour chaque API publique destinée à être consommée directement ; plusieurs APIs étroitement liées peuvent partager un même exemple lorsque leur usage réel est composé. Les changements de release appartiennent au changelog/delta, pas au guide d'utilisation.
 - **KSP-REL-014** — Toute application/binaire Tauri KSP considéré comme complété possède un `USAGE.md` durable décrivant ses fenêtres, leurs objectifs, leurs flux principaux et leur utilisation opérateur.
 - **KSP-REL-015** — Une application Tauri complétée ne crée `PRESENTATION.md` que si elle possède réellement une vue de présentation embarquée ; dans ce cas le fichier est finalisé comme contenu UI sans liens navigables et reste distinct du `README.md` et du `USAGE.md`.
+- **KSP-REL-016** — Une prerelease vise environ 15 à 20 minutes de travail effectif. Le `pre.001` dimensionne aussi la release concrète entière : une release doit pouvoir être ouverte, développée, validée et clôturée dans une seule session de chat. Si cette clôture paraît incertaine, la release est scindée avant l'implémentation fonctionnelle lourde ; une version volontairement répartie sur plusieurs sessions est interdite.
+- **KSP-TRANSPORT-006** — Pour une surface de transport explicitement ciblée, KSP inventorie et implémente toutes les méthodes/opérations exposées par la documentation normative retenue, sauf impossibilité technique explicitement documentée. L'inventaire couvre aussi les sections officielles séparées `deprecated`/`obsolete` et `unstable`/`experimental` lorsqu'elles existent. Les opérations deprecated/obsolete encore réellement fonctionnelles et unstable/experimental restent utilisables mais émettent un `warn` via `ksp-logging-lib` à chaque utilisation concernée ; leur statut est décrit par une metadata centralisée et non par des warnings dispersés.
+- **KSP-FLOW-001** — La progression durable canonique est `RAW -> CORE -> DECODE -> SPECIALIZED`. RAW et CORE ne nécessitent aucun decoder Program ; le passage RAW -> CORE reste une normalisation générique de la blockchain Solana. À partir de DECODE, KSP progresse verticalement par groupe fonctionnel à travers wire, décodage, matérialisation, projection spécialisée si utile, préparation d'exécution, policy, exécution et scénarios de validation.
+- **KSP-FLOW-002** — Un programme ou composant satellite nécessaire à la compréhension, la matérialisation ou l'exécution correcte d'un protocole appartient au groupe de ce protocole. Il n'est pas reporté artificiellement dans une catégorie `trading-adjacent`.

docs/validation/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/000-README.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->
 
 # Validations KSP
 
@@ -10,3 +10,4 @@ Les deltas restent l’historique autoritatif des livraisons ; une matrice de va
 Documents :
 
 - [`001-V0_1_4_CONFIG_DESKTOP.md`](001-V0_1_4_CONFIG_DESKTOP.md) — matrice finale de `0.1.4 — ksp-app-config-desk`.
+- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — matrice finale de la release stable `0.2.0`, avec audit de cohérence et preuves opérateur de `pre.003`.

docs/validation/002-V0_2_0_SERIES_PLANNING.md

@@ -0,0 +1,197 @@
+<!-- file: docs/validation/002-V0_2_0_SERIES_PLANNING.md -->
+<!-- version: 3 -->
+
+# Validation `0.2.0` — audit bot3 et planification de la série `0.2.x`
+
+## Objet
+
+Cette matrice synthétise l'audit final de `0.2.0`, les preuves opérateur de `pre.003` et la clôture publiée par `0.2.0-rel.001` conformément au cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md`.
+
+Elle ne remplace ni `docs/plans/007-V0_2_0_SERIES_PLANNING.md` ni les deltas `0.2.0`.
+
+## Base auditée
+
+```text
+KSP : khadhroony-solana-project_v0.2.0-pre.002-full-from-git.zip
+bot3 : khadhroony-bot3_v0.5.3-pre.005-fix010.zip
+```
+
+Audit final réalisé le :
+
+```text
+2026-08-17
+```
+
+## Matrice de clôture
+
+| Critère                                                                                         | Statut après `pre.003` | Preuve / décision                                                                                                    |
+|-------------------------------------------------------------------------------------------------|------------------------|----------------------------------------------------------------------------------------------------------------------|
+| Méthode d'audit bot3 définie                                                                    | OK                     | `007`, sections 1–3                                                                                                  |
+| Cartographie Wallet / Transport / Interface / Program / scenarios                               | OK                     | `007`, matrice section 16 + architecture KSP                                                                         |
+| Distinction fonctionnalité / implémentation / contrat / dépendance / convention                 | OK                     | `007`, section 3                                                                                                     |
+| Matrice reprendre / adapter / refondre / abandonner / ajouter                                   | OK                     | `007`, section 16                                                                                                    |
+| Config reste propriétaire exclusif de Config/env                                                | OK                     | Transport ne dépend pas de Config ; adapter Config -> Transport                                                      |
+| Logging reste façade runtime                                                                    | OK                     | warnings Transport imposés via `ksp-logging-lib`                                                                     |
+| Wallet temporaire bot2/bot3 abandonné                                                           | OK                     | `.kspwallet` devient le format natif ; scenarios futurs utilisent de vrais wallets                                   |
+| `WalletPolicy` sortie du Wallet                                                                 | OK                     | future `ksp-execution-policy-api` / policy contextuelle                                                              |
+| TODO import/export bot3 utiles préservés                                                        | OK                     | `IDEAS.md` inclut Solana CLI/Base58, Phantom, Solflare/keystore, Backpack, Trust Wallet, Base app et distinction CDP |
+| Ordre `0.2.1+` justifié par dépendances                                                         | OK                     | HTTP précède Wallet/Wallet Desk ; transports live puis off-chain puis Interface/Program                              |
+| Chaque release `0.2.1+` possède mission/périmètre/hors-périmètre/dépendances/clôture/estimation | OK                     | `007`, section 4.8                                                                                                   |
+| Discipline ~15–20 min/prerelease                                                                | OK                     | règles release/prompt                                                                                                |
+| Une release concrète = une seule session de chat                                                | OK                     | gate de sizing obligatoire à `pre.001`                                                                               |
+| Transport couvre toute documentation normative ciblée                                           | OK                     | règle `KSP-TRANSPORT-006`                                                                                            |
+| Deprecated/obsolete encore fonctionnel => `warn`                                                | OK                     | règle `KSP-TRANSPORT-006`                                                                                            |
+| Unstable/experimental => `warn`                                                                 | OK                     | règle `KSP-TRANSPORT-006`                                                                                            |
+| RAW -> CORE indépendant de Program decoding                                                     | OK                     | règles/architecture corrigées depuis `pre.002`                                                                       |
+| Pipeline durable RAW -> CORE -> DECODE -> SPECIALIZED                                           | OK                     | architecture 008/009, plans 002/007                                                                                  |
+| RAW et CORE progressent horizontalement                                                         | OK                     | workers/jobs/apps ajoutés à la fin de chaque couche selon besoin                                                     |
+| DECODE+ progresse verticalement groupe par groupe                                               | OK                     | `KSP-FLOW-001`                                                                                                       |
+| Satellites protocole restent dans leur groupe                                                   | OK                     | `KSP-FLOW-002`                                                                                                       |
+| Ancienne chaîne globale materializer/projector supprimée comme décision active                  | OK                     | `KSP-WORKER-008`, `KSP-JOB-009` corrigé, IDEAS requalifié                                                            |
+| Ordre Program orienté trading défini                                                            | OK                     | Core -> SPL token -> metadata -> Anchor -> Meteora/Raydium/Pump/Orca -> routing -> trading-adjacent -> généraliste   |
+| Market Desk progressive prévue                                                                  | OK                     | V1 après DEX prioritaires, enrichissement après routing                                                              |
+| Première release fonctionnelle décidée                                                          | OK                     | `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`                                                         |
+| Prompt `0.2.1` finalisé                                                                         | OK                     | `prompts/006-V0_2_1_START_PROMPT.md` version 2                                                                       |
+| Collisions d'identifiants normatifs                                                             | CORRIGÉ                | `KSP-TRANSPORT-006`, `KSP-FLOW-001/002`; les IDs notification existants restent inchangés                            |
+| Jobs de replay globaux historiques                                                              | CORRIGÉ                | aucune liste DECODE/SPECIALIZED globale figée ; replay introduit par frontière/groupe réel                           |
+
+## Spot-check Transport HTTP avant `0.2.1`
+
+Ce contrôle n'est **pas** la matrice normative de `0.2.1`; il sert uniquement à vérifier que le sizing du prompt est crédible et que bot3 ne constitue pas la source de vérité.
+
+### Documentation Solana observée le 2026-08-17
+
+Index HTTP officiel :
+
+```text
+https://solana.com/docs/rpc/http
+```
+
+Le spot-check recense **52 méthodes dans l'index HTTP courant**.
+
+La documentation Solana possède aussi une section `Deprecated Methods` séparée. Le spot-check observe **14 noms deprecated** dans cette section. Une page deprecated peut indiquer une suppression attendue dans une ancienne génération de `solana-core`; `0.2.1-pre.001` doit donc vérifier la disponibilité runtime actuelle avant de conclure qu'elle reste supportable.
+
+Exemple de source officielle :
+
+```text
+https://solana.com/docs/rpc/deprecated/getrecentblockhash
+```
+
+### Comparaison bot3
+
+`ks-onchain-transport/src/standard_methods.rs` contient les **52 noms de l'index HTTP courant** observé lors de ce spot-check, mais ne contient pas les 14 anciennes méthodes deprecated séparées.
+
+Cette égalité de noms ne signifie pas égalité de contrat : bot3 distingue notamment des méthodes avec typed adapter et des méthodes seulement enregistrées/raw JSON. KSP doit auditer request/response/status/tests méthode par méthode.
+
+Conclusion :
+
+- l'existant bot3 est une bonne source d'inventaire et de comportements historiques ;
+- il n'est pas la norme ;
+- `0.2.1-pre.001` doit refaire la matrice depuis la documentation officielle du jour ;
+- la section deprecated séparée doit être inspectée explicitement ;
+- si le nombre réel de méthodes + niveau de typage + pools/config rendent `0.2.1` trop risquée pour une seule session, la release est redécoupée **avant** l'implémentation lourde.
+
+## Écarts trouvés dans `pre.002` et corrigés par `pre.003`
+
+### IDs normatifs dupliqués
+
+`RULES_KSP.md` réutilisait :
+
+```text
+KSP-TRANSPORT-001
+KSP-DATA-001
+KSP-DATA-002
+```
+
+pour deux décisions différentes chacune.
+
+Correction :
+
+```text
+KSP-TRANSPORT-001  conserve la décision de ne pas créer ksp-onchain-transport-api
+KSP-TRANSPORT-006  porte la couverture documentaire exhaustive
+KSP-DATA-001/002   restent les règles historiques de notification de données
+KSP-FLOW-001/002   portent la progression durable et les satellites de protocole
+```
+
+### Replay jobs supersédés
+
+`KSP-JOB-009` imposait encore :
+
+```text
+ksp-job-replay-core
+ksp-job-replay-generic-materialization
+ksp-job-replay-domain-projection
+```
+
+La règle est remplacée par une introduction need-driven des replays : CORE lorsqu'il existe, puis groupes/capacités verticaux à partir de DECODE.
+
+### Diagramme workers encore trop figé
+
+`docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md` conservait encore un schéma `W1 -> D1 -> W2 -> D2 -> W3 -> D3 -> W4 -> D4`. Même sans noms concrets, il pouvait réintroduire l'idée de quatre workers globaux correspondant mécaniquement aux quatre niveaux durables. `pre.003` le remplace par un diagramme des **frontières de données D1–D4** et précise que RAW/CORE peuvent avoir leurs workers horizontaux tandis que DECODE/SPECIALIZED utilisent des workers/processors need-driven par groupe vertical.
+
+### IDEAS Wallet incomplet
+
+Le TODO bot3 conservait plusieurs cibles étudiées mais non implémentées. Elles sont maintenant explicitement reportées dans KSP sans en faire des engagements prématurés : Backpack, Trust Wallet, Solflare Keystore, Base app/ex-Coinbase Wallet et distinction Coinbase Developer Platform.
+
+### Plan directeur incomplet sur les releases
+
+Le prompt `0.2.0` demandait pour chaque release `0.2.1+` : mission, périmètre, hors-périmètre, dépendances, critères de clôture et estimation souple des prereleases. `pre.002` n'avait pas encore regroupé ces six dimensions pour toutes les releases. `pre.003` ajoute les fiches correspondantes dans `007`.
+
+## Anomalie historique non bloquante
+
+Le scan global des headers Markdown détecte un ancien delta déjà livré :
+
+```text
+deltas/0.1.4/pre.016-fix.002.md
+```
+
+qui ne possède pas les deux commentaires d'en-tête `file/version` utilisés par la convention actuelle. Ce fichier appartient à l'historique publié `0.1.4` et n'est **pas réécrit silencieusement** dans `0.2.0-pre.003`, conformément à la règle d'immutabilité pratique des deltas livrés. Cette anomalie ne modifie aucune règle/architecture active et ne bloque pas `0.2.0`.
+
+## Preuves opérateur finales de `pre.003`
+
+Le user a communiqué le 2026-08-17, sur le commit :
+
+```text
+e721464a7c2cbf4c564757061a2a44dd7913facb
+v0.2.0-pre.003
+```
+
+les validations suivantes avec succès :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+Résultats synthétiques :
+
+- `cargo check --workspace` : succès ;
+- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ;
+- `cargo test --workspace` : **241 tests réussis**, aucun échec ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement `ignored` ;
+- `git diff --check` : aucune sortie ;
+- `git status --short` : aucune sortie, working tree propre ;
+- `git log -1 --oneline --decorate` confirme `e721464 (HEAD -> master, origin/master) v0.2.0-pre.003`.
+
+Aucun écart supplémentaire n'a été révélé par cette validation. Aucune `pre.004` n'est donc requise.
+
+## Statut de clôture
+
+`0.2.0-rel.001` publie le cadrage sous `workspace.package.version = "0.2.0"` sans développement N2 ni nouvelle décision architecturale.
+
+Après validation du delta stable, les identifiants Git attendus sont :
+
+```text
+commit : v0.2.0-rel.001
+tag    : v0.2.0
+```
+
+La release suivante s'ouvre avec :
+
+```text
+prompts/006-V0_2_1_START_PROMPT.md
+```

prompts/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: prompts/000-README.md -->
-<!-- version: 8 -->
+<!-- version: 10 -->
 
 # Prompts KSP
 
@@ -26,3 +26,5 @@ Le prompt générique `0.1.x` a été affiné pendant `0.0.3` puis remplacé par
 - [`003-V0_1_3_START_PROMPT.md`](003-V0_1_3_START_PROMPT.md) — prompt historique destiné à ouvrir `0.1.3 — Configuration foundation` après publication stable de `0.1.2` ;
 - [`004-V0_1_4_START_PROMPT.md`](004-V0_1_4_START_PROMPT.md) — prompt final destiné à ouvrir `0.1.4 — ksp-app-config-desk` après publication stable de `0.1.3`.
 - [`005-V0_2_0_START_PROMPT.md`](005-V0_2_0_START_PROMPT.md) — prompt de reprise préparé à la clôture de `0.1.4`; il ouvre `0.2.0-pre.001`, release intermédiaire d'audit de `khadhroony-bot3`, de comparaison avec KSP et de planification/découpage du reste de `0.2.x`.
+
+- [`006-V0_2_1_START_PROMPT.md`](006-V0_2_1_START_PROMPT.md) — prompt finalisé par `0.2.0-pre.003`, destiné à ouvrir `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation` après publication stable de `0.2.0`; il impose l'audit exhaustif des surfaces HTTP courantes et deprecated/unstable officiellement documentées, la séparation Config/Transport, les pools/rôles et le gate de sizing « une release = une session ».

prompts/006-V0_2_1_START_PROMPT.md

@@ -0,0 +1,667 @@
+<!-- file: prompts/006-V0_2_1_START_PROMPT.md -->
+<!-- version: 2 -->
+
+# Prompt de démarrage `0.2.1` — `ksp-onchain-transport-lib` HTTP Solana foundation
+
+> **Statut : finalisé par `0.2.0-pre.003`.** Utiliser ce prompt uniquement après publication stable/tag `v0.2.0`; toute information externe temporelle doit être revérifiée à l'ouverture de `0.2.1-pre.001`.
+
+## 1. Contexte de reprise
+
+La base attendue est la release stable `v0.2.0` de `khadhroony-solana-project`.
+
+`0.2.0` a audité `khadhroony-bot3`, refondu la roadmap et décidé que la première capacité fonctionnelle de `0.2.x` doit être le transport HTTP Solana, car les capacités suivantes — en particulier `ksp-wallet-lib` puis `ksp-app-wallet-desk` — doivent pouvoir interroger réellement le réseau, par exemple pour lire le solde d'un wallet.
+
+Les fondations stables à préserver sont :
+
+```text
+ksp-core-lib
+ksp-logging-lib
+ksp-config-lib
+ksp-app-config-desk
+```
+
+La release à ouvrir est :
+
+```text
+0.2.1 — ksp-onchain-transport-lib / Solana HTTP foundation
+```
+
+La première tranche est :
+
+```text
+0.2.1-pre.001
+```
+
+`pre.001` est une tranche d'**audit, conception, inventaire exhaustif et dimensionnement**. Elle ne doit pas devenir automatiquement une grosse implémentation.
+
+## 2. Mission de `0.2.1`
+
+Créer la première version stable de `ksp-onchain-transport-lib` pour le transport **HTTP JSON-RPC Solana**, avec une API publique KSP indépendante de Config, du Store et des futures couches Program.
+
+La release doit fournir :
+
+- transport HTTP async ;
+- JSON-RPC 2.0 ;
+- settings runtime publics possédés par le transport ;
+- endpoints nommés ;
+- metadata provider/cluster ;
+- pools logiques d'endpoints ;
+- rôles/capabilities/request kinds ;
+- priorités ;
+- limites de débit/burst/concurrence lorsque configurées ;
+- timeout ;
+- retry/backoff transport borné ;
+- observabilité via `ksp-logging-lib` ;
+- toutes les méthodes HTTP exposées par la documentation normative Solana ciblée par la release ;
+- méthodes read et méthodes write/execution technique ;
+- classification centralisée des méthodes selon leur statut documentaire ;
+- warnings runtime pour méthodes deprecated/obsolete encore fonctionnelles et unstable/experimental ;
+- premier document Config standard Transport dans `ksp-config-lib` et adapter Config -> settings publics Transport ;
+- tests, fixtures, documentation `README.md`/`USAGE.md` et preuve de complétude de la surface.
+
+`0.2.1` doit être un transport générique KSP utilisable directement par une bibliothèque, une application, un job ou un worker. Il ne doit pas être conçu uniquement pour Wallet Desk.
+
+## 3. Sources de vérité internes obligatoires
+
+Avant toute modification, relire au minimum :
+
+```text
+ROADMAP.md
+docs/000-README.md
+docs/IDEAS.md
+
+docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
+docs/plans/007-V0_2_0_SERIES_PLANNING.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/008-DATA_MATERIALIZATION_AND_STORE.md
+docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
+
+docs/rules/RULES_KSP.md
+docs/rules/RULES_DEPENDENCIES.md
+docs/rules/RULES_RUST.md
+docs/rules/PROMPT_STRUCTURE.md
+docs/rules/VERSION_WORKFLOW.md
+docs/rules/FILE_CONTRACTS.md
+```
+
+Relire également les contrats publics actuels de :
+
+```text
+crates/ksp-core-lib
+crates/ksp-logging-lib
+crates/ksp-config-lib
+```
+
+Ne pas supposer leurs APIs à partir de bot3.
+
+## 4. Référence historique bot3
+
+Auditer la dernière archive bot3 fournie disponible, en particulier :
+
+```text
+ks-onchain-transport/
+ks-config/src/transport.rs
+ks-config/src/settings.rs
+kb-app-demo-desktop/src/demo_http.rs
+kb-app-demo-desktop/src/demo_transport.rs
+```
+
+Sur `ks-onchain-transport`, examiner au minimum :
+
+```text
+client.rs
+endpoint_role.rs
+execution_rpc.rs
+get_signatures_for_address.rs
+get_transaction.rs
+http_client.rs
+http_pool.rs
+json_rpc.rs
+standard_http.rs
+standard_http_accounts.rs
+standard_http_blocks.rs
+standard_http_cluster.rs
+standard_http_economics.rs
+standard_http_tokens.rs
+standard_http_transactions.rs
+standard_methods.rs
+validation.rs
+README.md
+USAGE.md
+TODO.md
+```
+
+Bot3 est une **source fonctionnelle et historique**, pas une source normative d'architecture.
+
+Reprendre les besoins/invariants utiles ; ne pas reproduire :
+
+- dépendance publique Transport -> Config ;
+- dépendance vers `ks-lib`/modèles canoniques ;
+- appels directs `tracing` ;
+- DTOs couplés au futur Store ;
+- anciens stacks de dépendances uniquement parce qu'ils existent ;
+- duplication inutile de modèles ou de codecs.
+
+## 5. Sources externes normatives
+
+Au début de `pre.001`, consulter la documentation **officielle et actuelle** de Solana pour JSON-RPC HTTP et identifier précisément la surface normative de la release.
+
+L'inventaire doit couvrir explicitement :
+
+- l'index HTTP courant ;
+- la section officielle `Deprecated Methods` même lorsqu'elle est séparée de l'index courant ;
+- toute surface HTTP `unstable` / `experimental` officiellement documentée ;
+- la disponibilité runtime réelle d'une méthode deprecated/obsolete avant de décider qu'elle reste supportable.
+
+Le spot-check documentaire de clôture de `0.2.0` a observé 52 méthodes dans l'index HTTP courant du 2026-08-17 et 14 noms dans la section officielle Deprecated Methods. **Ces nombres ne sont pas un contrat** : `0.2.1-pre.001` doit refaire l'inventaire depuis les sources officielles du jour.
+
+Ne pas utiliser une liste mémorisée ou la liste bot3 comme vérité.
+
+Pour chaque méthode HTTP documentée, relever au minimum :
+
+```text
+nom RPC
+catégorie
+paramètres
+config/commitment/encoding éventuels
+forme du résultat
+erreurs/nullable/optional importants
+statut documentaire
+stable | deprecated/obsolete | unstable/experimental
+notes/version minimum éventuelles
+lien/source normative
+tests nécessaires
+```
+
+Vérifier également les spécifications/projets officiels nécessaires pour JSON-RPC et les crates externes retenues.
+
+Lorsque la documentation officielle Solana et une implementation/provider divergent, documenter l'écart au lieu de modifier silencieusement le contrat standard.
+
+## 6. Règle de couverture exhaustive
+
+`0.2.1` ne se limite pas aux méthodes actuellement utilisées par Wallet ou bot3.
+
+Pour la surface Solana HTTP officiellement ciblée :
+
+> **toute méthode exposée par la documentation normative doit être implémentée, sauf impossibilité technique explicitement documentée et validée.**
+
+Le `pre.001` doit créer une matrice de conformité durable, par exemple dans le plan `0.2.1` ou un document de validation dédié, permettant de vérifier qu'aucune méthode n'a été oubliée.
+
+Une méthode ne peut pas être déclarée couverte uniquement parce qu'un appel JSON générique existe : la release doit décider quelle surface publique typée/générique KSP est réellement promise et tester ce contrat.
+
+## 7. Méthodes deprecated, obsolete et unstable
+
+Chaque méthode possède une metadata de statut centralisée, conceptuellement :
+
+```text
+Stable
+Deprecated
+Unstable
+```
+
+Les noms Rust exacts sont décidés en `pre.001`.
+
+### Deprecated / obsolete mais encore fonctionnelle
+
+- implémenter/conserver la méthode ;
+- ne pas la masquer ;
+- émettre un `warn` via `ksp-logging-lib` lorsqu'elle est utilisée ;
+- inclure méthode, statut et contexte sûr dans le log ;
+- ne jamais logguer de secrets/tokens/provider credentials.
+
+### Unstable / experimental
+
+- implémenter la méthode lorsqu'elle appartient à la documentation ciblée ;
+- émettre un `warn` via `ksp-logging-lib` à l'utilisation ;
+- documenter que son contrat externe peut évoluer.
+
+### Méthode réellement supprimée/non fonctionnelle
+
+Ne pas simuler un succès. Documenter l'historique et l'absence de support runtime si la méthode n'existe plus dans la surface normative actuelle.
+
+Les warnings ne doivent pas être dispersés à la main dans chaque méthode si une metadata/descripteur commun permet de garantir le comportement de manière centralisée.
+
+## 8. Frontière Config / Transport
+
+### Règle absolue
+
+```text
+ksp-onchain-transport-lib -X-> ksp-config-lib
+```
+
+Le transport doit pouvoir être construit et testé sans Config.
+
+Il possède ses settings publics, conceptuellement :
+
+```text
+HttpTransportSettings
+HttpEndpointSettings
+EndpointRoleSettings
+RetrySettings
+PoolSettings
+...
+```
+
+Les noms/types exacts ne sont pas imposés par ce prompt.
+
+### Document standard Config
+
+`0.2.1` doit également introduire dans `ksp-config-lib` le premier document standard Transport HTTP et son schema, selon le moteur Config déjà stabilisé.
+
+Direction :
+
+```text
+config/std.transport.json
+config/schemas/std.transport.schema.json
+config/examples/std.transport.example.json      # si la convention Config l'exige/retient
+```
+
+Les `file_id` exacts suivent les conventions `ksp-config-lib` et sont décidés après audit des documents existants.
+
+Le document Config :
+
+- peut contenir plusieurs profils ;
+- sélectionne/configure endpoints, rôles et paramètres HTTP ;
+- utilise les placeholders d'environnement KSP pour URLs/tokens seulement selon le mécanisme Config existant ;
+- ne lit jamais directement l'environnement dans Transport ;
+- doit être extensible plus tard à WS/gRPC sans préremplir aujourd'hui des champs sans implementation ;
+- reste manageable par Config Desk grâce au moteur générique existant, sans développer une UI Transport dédiée dans `0.2.1`.
+
+Adapter :
+
+```text
+ksp-config-lib -> ksp-onchain-transport-lib public settings
+```
+
+La dépendance inverse reste interdite.
+
+Toute nouvelle variable d'environnement réellement utilisée est ajoutée à `.env.example` dans la même tranche, avec commentaire et namespace correct.
+
+## 9. Pools, rôles et capabilities
+
+Reprendre/refondre l'idée utile de bot3 sans figer ses structures exactes.
+
+Un endpoint HTTP doit pouvoir déclarer :
+
+- identité/name ;
+- enabled ;
+- provider ;
+- cluster/network ;
+- URL ;
+- timeout/settings connexion ;
+- rôles/capabilities ;
+- priorités ;
+- limites applicables.
+
+Un rôle peut porter selon le design retenu :
+
+- request kinds/méthodes supportées ;
+- priorité ;
+- requests per second ;
+- burst ;
+- max concurrent requests ;
+- pause après rate-limit ;
+- autres limites réellement justifiées.
+
+Ne pas créer une enum centrale fermée si des rôles configurables/string descriptors permettent une extension plus propre.
+
+Le pool HTTP sélectionne un **endpoint/client logique**, pas une socket brute.
+
+Le client HTTP sous-jacent reste propriétaire de son propre pooling de connexions réseau.
+
+Le `pre.001` doit décider explicitement :
+
+- stratégie de sélection ;
+- comportement si aucun endpoint ne satisfait le rôle/méthode ;
+- comportement sur endpoint disabled ;
+- round-robin/priority/fallback éventuel ;
+- gestion d'un endpoint rate-limited ;
+- health/snapshot nécessaires ;
+- thread-safety/concurrence.
+
+## 10. Retry, timeout et erreurs
+
+Distinguer strictement :
+
+### Retry transport
+
+Peut concerner une requête HTTP qui n'a pas obtenu de résultat exploitable en raison d'un problème transport/provider clairement retryable.
+
+### Retry d'exécution métier
+
+N'appartient pas à `0.2.1` et ne doit pas être inventé dans Transport.
+
+Le transport ne doit jamais décider de renvoyer une transaction Solana sur la seule base d'une erreur métier ou d'un timeout ambigu.
+
+Définir une classification d'erreurs KSP suffisamment précise pour distinguer au minimum :
+
+- invalid settings ;
+- endpoint selection ;
+- connection/HTTP ;
+- timeout ;
+- rate-limit ;
+- JSON encode/decode ;
+- JSON-RPC protocol ;
+- RPC application error ;
+- unsupported/deprecated status si nécessaire ;
+- invalid response/invariant.
+
+Utiliser le type d'erreur KSP existant ; ne pas créer une deuxième hiérarchie publique incompatible.
+
+## 11. Modèles et ownership des types
+
+`0.2.1` ne doit pas dépendre du futur Store, de `ksp-program-api` ou de modèles DECODE/SPECIALIZED.
+
+Les réponses du transport appartiennent au domaine Transport ou utilisent les primitives KSP/bas niveau explicitement admises.
+
+Ne pas reproduire le couplage bot3 :
+
+```text
+getTransaction -> ks_lib::MdCanonicalTransaction
+```
+
+Le transport doit préserver les informations nécessaires à la future persistence RAW et à la normalisation CORE sans effectuer lui-même ces transformations.
+
+Le `pre.001` doit inventorier les méthodes dont les réponses nécessitent une décision de représentation importante, notamment transactions/messages/accounts/blocks/token amounts/statuses, et fixer l'ownership avant code massif.
+
+Éviter `solana-client` ou un SDK haut niveau uniquement pour obtenir des DTOs si cela réintroduit un graphe massif et empêche KSP de posséder son contrat transport. Toute dépendance Solana supplémentaire doit être justifiée par un besoin précis et compatible avec le firewall KSP.
+
+## 12. Dépendances externes
+
+Toutes les dépendances tierces communes sont déclarées au `Cargo.toml` racine sous `[workspace.dependencies]`, puis consommées avec `.workspace = true`.
+
+Avant ajout, `pre.001` doit vérifier les versions actuelles et le graphe de dépendances des candidates.
+
+Bot3 utilisait notamment :
+
+```text
+reqwest
+serde
+serde_json
+tokio
+base64
+bs58
+```
+
+Cette liste est une référence d'audit, **pas une décision automatique**.
+
+Ne pas ajouter dans `0.2.1` les dépendances WebSocket/gRPC réservées aux releases suivantes, sauf nécessité technique démontrée pour le build HTTP.
+
+Exécuter les `cargo tree` pertinents après ajout :
+
+```bash
+cargo tree -p ksp-onchain-transport-lib
+cargo tree -p ksp-onchain-transport-lib -d
+cargo tree -p ksp-onchain-transport-lib -e features
+cargo tree -p ksp-onchain-transport-lib -e normal
+```
+
+et auditer les doublons réellement significatifs.
+
+## 13. Logging et observabilité
+
+`ksp-onchain-transport-lib` utilise `ksp-logging-lib` et ne dépend pas directement de `tracing` pour ses événements KSP.
+
+Target attendu : nom Cargo de la crate.
+
+Événements utiles à couvrir :
+
+- création client/pool ;
+- sélection endpoint/role ;
+- start/end d'une requête aux niveaux debug/trace appropriés ;
+- retry ;
+- timeout ;
+- rate-limit/backoff ;
+- endpoint unavailable/degraded ;
+- RPC error ;
+- méthode deprecated/unstable utilisée ;
+- snapshots/health importants.
+
+Ne jamais logguer :
+
+- API key ;
+- token provider ;
+- URL contenant un secret non redacted ;
+- transaction/signature payload sensible sans raison explicite ;
+- contenu massif de réponses par défaut.
+
+Les informations provenant de `reqwest` ou d'autres dépendances sont réémises sous le target KSP lorsque réellement utiles ; ne pas ouvrir globalement leurs targets.
+
+## 14. Tests obligatoires
+
+### Tests unitaires
+
+Prévoir au minimum :
+
+- validation settings ;
+- endpoint/role matching ;
+- pool selection ;
+- priority/fallback ;
+- limiter/concurrence ;
+- retry/backoff borné ;
+- JSON-RPC request/response ;
+- RPC error mapping ;
+- nullable/optional responses ;
+- method status metadata ;
+- warning path deprecated/unstable ;
+- aucune fuite de secret dans Debug/loggable snapshots.
+
+### Tests par méthodes
+
+Chaque méthode documentée doit être couverte par au moins une preuve adaptée :
+
+- request serialization ;
+- response deserialization ;
+- paramètres/configs ;
+- cas optional/null/error importants.
+
+Utiliser des fixtures déterministes lorsque le réseau n'apporte aucune valeur au test.
+
+### Tests réseau opt-in
+
+Prévoir un petit nombre de smoke tests Devnet/Mainnet non destructifs si nécessaire pour démontrer l'interop réelle, sans rendre la suite par défaut dépendante d'Internet ou d'une clé provider.
+
+Les tests réseau nécessitant un provider/secret doivent être opt-in et utiliser Config/env via les mécanismes KSP, jamais des secrets versionnés.
+
+### Canaries architecturales
+
+Ajouter des tests/audits empêchant au minimum :
+
+```text
+ksp-onchain-transport-lib -> ksp-config-lib
+ksp-onchain-transport-lib -> ksp-store-*
+ksp-onchain-transport-lib -> ksp-program-*
+direct tracing ownership
+```
+
+et vérifiant la complétude de la matrice de méthodes si elle peut être automatisée.
+
+## 15. Hors périmètre strict de `0.2.1`
+
+Ne pas ouvrir :
+
+- WebSocket Solana — `0.2.4` ;
+- Helius LaserStream WebSocket — `0.2.5` ;
+- Yellowstone gRPC — `0.2.6` ;
+- providers gRPC avancés ;
+- Wallet — `0.2.2` ;
+- Wallet Desk — `0.2.3` ;
+- Store/persistence RAW — `0.3.1` ;
+- decoders Program ;
+- `ksp-interface-lib` fonctionnel complet ;
+- materializers ;
+- execution policy ;
+- orchestration d'exécution métier ;
+- worker/job d'acquisition ;
+- Tauri app Transport dédiée ;
+- trading/DEX/ML.
+
+Une méthode HTTP permettant techniquement `sendTransaction`, `simulateTransaction`, `requestAirdrop` ou autre opération write peut appartenir au **transport standard** et doit être implémentée si documentée ; cela ne signifie pas que `0.2.1` construit l'orchestration d'exécution KSP.
+
+## 16. Première mission : `0.2.1-pre.001`
+
+`pre.001` doit livrer un plan détaillé de `0.2.1`, candidat :
+
+```text
+docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md
+```
+
+Il doit contenir au minimum :
+
+1. audit exact de la base stable `v0.2.0` ;
+2. audit détaillé de `ks-onchain-transport` bot3 ;
+3. inventaire **exhaustif** des méthodes HTTP Solana documentées actuellement, y compris les index current/deprecated/unstable séparés ;
+4. comparaison nom par nom avec l'inventaire bot3 afin d'identifier ajouts, suppressions, méthodes historiques non reprises et niveau de contrat réel (`typed` vs raw/generic) ;
+5. statut `stable/deprecated/unstable` de chaque méthode ;
+6. matrice méthode -> module/API KSP -> request -> response -> tests -> prerelease candidate ;
+7. inventaire des contrats bot3 utiles à reprendre/adapter/refondre/abandonner ;
+8. décision exacte sur les settings publics Transport ;
+9. décision exacte pools/rôles/capabilities/priority/rate-limit/concurrence ;
+10. stratégie retry/backoff/timeout ;
+11. stratégie d'erreurs ;
+12. ownership des modèles de réponse difficiles ;
+13. dépendances externes retenues après vérification de versions/features ;
+14. design du document `std.transport` et de l'adapter Config -> Transport ;
+15. nouvelles variables `.env.example` réellement nécessaires, sans secret concret ;
+16. architecture de tests/fixtures/smoke tests ;
+17. canaries de dépendances/ownership ;
+18. hors-périmètre confirmés ;
+19. critères de clôture ;
+20. prévision souple des prereleases ;
+21. **gate de sizing de la release entière**.
+
+### Gate de sizing obligatoire
+
+À la fin de `pre.001`, répondre explicitement :
+
+```text
+La release 0.2.1 peut-elle raisonnablement être entièrement clôturée dans cette session de chat
+avec des prereleases de ~15–20 minutes ?
+```
+
+Si la réponse est non ou incertaine, **ne pas commencer la grosse implémentation**. Scinder immédiatement le périmètre en plusieurs releases `0.2.x`, mettre à jour ROADMAP/plan/prompt, puis seulement commencer la première release réduite.
+
+La contrainte de couverture documentaire exhaustive ne doit jamais être contournée en masquant des méthodes pour faire tenir artificiellement la release.
+
+## 17. Prévision souple initiale des prereleases
+
+Cette prévision est un point de départ et doit être recalibrée par `pre.001` à partir de la matrice réelle des méthodes.
+
+### `pre.001` — audit, matrice exhaustive, architecture et sizing
+
+Aucune grosse implementation.
+
+### `pre.002` — crate foundation + settings + JSON-RPC + method descriptors
+
+Candidat :
+
+- package/workspace ;
+- contrats settings ;
+- validation ;
+- JSON-RPC envelope/error ;
+- metadata de méthode/status ;
+- base Logging.
+
+### Tranches méthodes HTTP
+
+Répartir les méthodes par familles cohérentes **après inventaire officiel**, par exemple accounts/cluster, blocks/transactions, tokens/economics, write/execution technique ou toute meilleure découpe révélée par la documentation.
+
+Aucune de ces tranches ne doit dépasser le budget 15–20 minutes ; ajouter des prereleases si nécessaire **uniquement si la release entière reste clôturable dans la session**.
+
+### Tranche pools/rôles/resilience
+
+- pools ;
+- role matching ;
+- priority/fallback ;
+- rate-limit ;
+- concurrency ;
+- retry/backoff ;
+- health/snapshots.
+
+### Tranche Config standard
+
+- schema/document/example ;
+- registration/file IDs ;
+- adapter Config -> Transport ;
+- env inventory ;
+- intégration tests.
+
+### Dernière prerelease
+
+- matrice de complétude 100 % de la surface ciblée ;
+- tests ciblés et workspace ;
+- cargo tree audits ;
+- README/USAGE ;
+- documentation durable ;
+- cleanup/TODO ;
+- prompt `0.2.2` Wallet ;
+- préparation `rel.001`.
+
+## 18. Validation de chaque tranche Rust
+
+Après toute modification Rust :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+```
+
+Pendant le développement :
+
+```bash
+cargo test -p ksp-onchain-transport-lib
+cargo test -p ksp-config-lib     # lorsque Config est modifié
+```
+
+`cargo test --workspace` est exécuté aux frontières globales prévues par les règles, notamment ouverture/fermeture de version et validation finale.
+
+Exécuter les `cargo tree` pertinents pour les crates modifiées.
+
+Ne jamais déclarer une commande réussie si elle n'a pas été exécutée.
+
+## 19. Critères de clôture `0.2.1`
+
+La release ne peut pas être déclarée stable tant que :
+
+- `ksp-onchain-transport-lib` existe comme crate KSP propre ;
+- aucune dépendance Transport -> Config/Store/Program n'existe ;
+- les settings publics sont documentés ;
+- le document Config Transport + adapter fonctionnent sans inverser l'ownership ;
+- toutes les méthodes de la surface HTTP Solana normative ciblée sont présentes dans la matrice ;
+- toutes les méthodes supportables ciblées sont implémentées ;
+- deprecated/obsolete encore fonctionnel et unstable/experimental émettent le warning KSP prévu ;
+- pools/rôles/priority/limites/timeouts/retry retenus sont testés ;
+- les réponses restent transport/raw-compatible et ne produisent pas des modèles Program/Store ;
+- aucun secret/provider token n'est loggué ;
+- les tests ciblés passent ;
+- les validations workspace finales passent ;
+- le graphe de dépendances est audité ;
+- `README.md` et `USAGE.md` sont complets ;
+- TODO/hors scope sont fermés ou reportés explicitement ;
+- le prompt final `0.2.2` est prêt ;
+- la release entière a été clôturée dans la session qui l'a ouverte.
+
+## 20. Release suivante
+
+La release suivante prévue est :
+
+```text
+0.2.2 — ksp-wallet-lib / .kspwallet foundation
+```
+
+Elle devra utiliser les fondations N1 mais **ne pas dépendre du transport** pour son cœur cryptographique/format.
+
+Le transport `0.2.1` sera ensuite composé avec Wallet dans `0.2.3 — ksp-app-wallet-desk` pour afficher notamment le solde réseau du wallet.
+
+## Instruction d'ouverture
+
+Commencer `0.2.1-pre.001` par la relecture des sources internes, l'audit exact du transport bot3 et la consultation de la documentation officielle Solana HTTP actuelle.
+
+Construire ensuite la matrice exhaustive des méthodes et le plan `008` **avant toute grosse migration/implémentation**.
+
+Ne pas copier `ks-onchain-transport` tel quel, ne pas introduire WebSocket/Yellowstone par anticipation, ne pas coupler Transport à Config, et ne pas commencer une release dont le sizing ne garantit pas raisonnablement la clôture dans cette même session.