v0.2.0-pre.002

ROADMAP.md

@@ -1,11 +1,9 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 21 -->
+<!-- version: 22 -->
 
 # 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.
-
-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.
+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.
 
 ## 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,99 +30,125 @@ 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.1.2` — Introduire `ksp-logging-lib` comme façade KSP de `tracing`, `tracing-appender` et `tracing-subscriber`.
-- [X] `0.1.3` — Stabiliser `ksp-config-lib` : documents, profils, résolution, validation, environnement KSP/KSPB, management/persistence et adapter Logging.
-- [X] `0.1.4` — Introduire `ksp-app-config-desk` pour valider réellement Config et la frontière Tauri.
+- [/] `0.2.0` — Auditer bot3, fixer l'ordre de `0.2.x`, actualiser l'architecture et préparer `0.2.1`.
+- [X] `0.2.0-pre.001` — Méthode d'audit, cartographie initiale et matrice provisoire.
+- [/] `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`.
 
-`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 :
 
-`0.2.0-pre.001` ouvre ce travail avec la méthode d'audit, une première cartographie de Wallet/Transport/Interface/Program/Execution/scenarios et une matrice initiale. Aucun numéro `0.2.1+` n'est encore figé ; le plan actif est `docs/plans/007-V0_2_0_SERIES_PLANNING.md`.
+```text
+RAW -> CORE -> DECODE -> SPECIALIZED
+```
 
-### Capacités à répartir dans les releases fonctionnelles suivantes
+- **RAW** et **CORE** ne nécessitent aucun décodage Program.
+- À 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.
+- À 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-onchain-transport-lib` avec des modèles de transport homogènes indépendants du store.
-- [ ] Introduire `ksp-wallet-lib` et `ksp-app-wallet-desk`.
-- [ ] Développer la première surface utile de `ksp-interface-lib`.
-- [ ] 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 — RAW / acquisition persistée
 
-## 0.3.x — Données, stockage et acquisition raw
+- [ ] `0.3.1` — Introduire `ksp-store-api` + `ksp-store-lib` avec PostgreSQL de référence et **modèles/persistence RAW uniquement**.
+- [ ] `0.3.2` — Étendre `ksp-interface-lib` avec les wires génériques nécessaires aux acquisitions et à la future normalisation CORE.
+- [ ] `0.3.3` — Introduire `ksp-job-api` et un job de backfill historique concret.
+- [ ] `0.3.4` — Introduire une application spécialisée de backfill/inspection RAW.
+- [ ] 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-materializer-api` / `ksp-materializer-lib`.
-- [ ] Introduire `ksp-store-api` / `ksp-store-lib` avec PostgreSQL de référence.
-- [ ] Établir les niveaux durables D1 Raw, D2 Core, D3 journal de matérialisation générique et D4 projections de domaine.
-- [ ] Garantir des replays indépendants D1 -> D2, D2 -> D3 et D3 -> D4.
-- [ ] Introduire `ksp-app-store-desk`.
-- [ ] 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.
+## Série CORE suivante
 
-## 0.4.x — Baseline Solana, SPL et metadata
+- [ ] Définir la persistence CORE canonique Solana générique.
+- [ ] Implémenter `RAW -> CORE` sans decoder Program : blocs, slots, signatures, transactions/messages, comptes, instructions/CPI brutes, logs/meta et relations structurelles.
+- [ ] Ajouter replay/backfill RAW -> CORE.
+- [ ] Ajouter worker/service CORE.
+- [ ] Ajouter l'application de contrôle/inspection CORE utile.
 
-- [ ] Ajouter progressivement les decoders et `ProgramExecutionPreparer` Core/SPL nécessaires.
-- [ ] Ajouter Token, Token-2022, ATA et metadata utiles.
-- [ ] Introduire `ksp-offchain-transport-lib` au plus tard au premier besoin externe.
-- [ ] Ajouter materializers et jobs ponctuels nécessaires.
-- [ ] Ajouter les crates `ksp-scenario-<domain>-lib` spécialisées.
-- [ ] 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é.
+## Séries DECODE/SPECIALIZED/EXECUTION — progression verticale
 
-## 0.5.x — Anchor et protocoles trading
+### Priorité 1 — Solana Core Programs
 
-- [ ] Introduire Anchor.
-- [ ] É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.
+- [ ] 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.
 
-## 0.6.x — Processing autonome et orchestration
+### Priorité 2 — SPL token/trading
 
-- [ ] Introduire `ksp-worker-core-processor` pour D1 Raw -> D2 Core canonique.
-- [ ] 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.
+- [ ] SPL Token.
+- [ ] Associated Token Account.
+- [ ] Token-2022 et extensions pertinentes.
+- [ ] Pour chaque famille : decode -> materialize -> specialized -> prepare -> policy -> execute -> scenarios.
 
-## 0.7.x — Trading Intelligence
+### Priorité 3 — Metadata token
 
-- [ ] Statistiques et métriques.
-- [ ] 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 contrats sont stables.
-
-## 0.8.x et suivantes — Trading opérationnel et expansion produits
-
-- [ ] 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.
+- [ ] XGBoost puis autres modèles lorsque les données et 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.
+- [ ] Étudier plus tard les autres applications Wallet : mobile, extensions navigateur et web.