# Roadmap KSP 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 - `[ ]` — prévu / non commencé ; - `[/]` — en cours ; - `[X]` — réalisé et validé ; - `[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**. - Cette règle fixe une durée maximale par release, pas une obligation de changer de session après chaque release : si une release est clôturée plus vite que prévu, la même session peut ouvrir puis clôturer la release suivante si son propre sizing reste positif et si toutes les frontières version/delta/validation sont conservées. - 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. - [X] `0.0.2` — Installer le squelette minimal et les règles initiales. - [X] `0.0.3` — Définir domaines, composants, dépendances, contrats, workers/jobs/scénarios/apps et plan global. - [X] Sélectionner `0.1.1` comme première release fonctionnelle et produire son prompt quasi-final. - [X] Clôturer la fondation avec documentation, validations et prompt final ; release stable `0.0.3` validée. ## 0.1.x — Fondations N1 - [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. ## 0.2.x — Accès Solana, Wallet et contrats d'extension initiaux ### Cadrage - [X] `0.2.0` — Audit bot3, ordre fonctionnel de `0.2.x`, architecture durable, discipline de sizing et pipeline RAW/CORE/DECODE/SPECIALIZED stabilisés. - [X] `0.2.1` — HTTP foundation stable : matrice 52+14, runtime/routing/résilience/exécution HTTP, 4 canaris typés, `std.transport`, adapter Config -> Transport, canaries de clôture, smoke Devnet opt-in et documentation durable validés ; les 48 wrappers typés restants sont reportés à `0.2.2`–`0.2.4`. ### Releases fonctionnelles décidées/pressenties - [X] `0.2.1` — **HTTP transport foundation réduite par le gate `pre.001`** : crate/settings/JSON-RPC/registry 52 current + 14 deprecated historiques, pool/rôles/limites/retry, Config adapter, documentation et 4 méthodes typées canari (`getBalance`, `getGenesisHash`, `getHealth`, `getVersion`) publiés stables. - [X] `0.2.2` — HTTP Accounts + Tokens + Cluster : 22 wrappers typés (5 Accounts + 5 Tokens + 12 Cluster), canaries de complétude 52+14, smoke Devnet Transport pur et smoke historique Config -> Transport validés, documentation durable et prompt `0.2.3` publiés stables. - [X] `0.2.3` — HTTP Transactions stable : 11/11 wrappers typés publiés, classification `8 Read / 2 WriteSubmission / 1 Simulation`, no-resend ambigu prouvé pour les write submissions, `KSP-TRANSPORT-007` réaudité conforme sur les 37 wrappers HTTP courants, graphes Cargo et deux smokes Devnet validés ; `0.2.4` reprend les 15 Blocks/Economics restants. - [/] `0.2.4` — HTTP Blocks + Economics + compliance HTTP finale en cours : `pre.001` confirme le scope exact 10 + 5, Agave stable `v4.2.1`, `KSP-TRANSPORT-007` et un gate de sizing positif avant implémentation. - [ ] `0.2.5` — Introduire `ksp-wallet-lib`, le format `.kspwallet`, la gestion sûre des secrets et une architecture d'import/export extensible ; exclure `WalletPolicy`. - [ ] `0.2.6` — Introduire `ksp-app-wallet-desk` utilisant Config composite + Wallet + transport HTTP, notamment pour afficher l'identité et le solde d'un wallet. - [ ] `0.2.7` — Étendre `ksp-onchain-transport-lib` au WebSocket Solana standard complet ; permettre plusieurs sessions sur une même URL sans imposer encore un pool automatique complexe. - [ ] `0.2.8` — Ajouter Helius LaserStream WebSocket comme extension du moteur WebSocket standard, sans duplication de client. - [ ] `0.2.9` — Ajouter une première fondation Yellowstone gRPC standard/provider-neutral ; dimensionner la surface exacte à `pre.001` selon la documentation normative actuelle. - [ ] `0.2.10` — Introduire `ksp-offchain-transport-lib` avec un premier lecteur de prix, au minimum SOL/USD et SOL/EUR. - [ ] `0.2.11` — Introduire une petite application desk de visualisation des prix. - [ ] `0.2.12` — Introduire la première surface de `ksp-interface-lib`, comprenant une API wire publique utilisable par les implémentations officielles et externes. - [ ] `0.2.13` — Introduire `ksp-program-api` comme premier contrat Program extensible, sans imposer encore `ksp-program-lib` complet. ### Règles Transport pour toute la série - [ ] 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. ## Architecture de données — progression canonique La chaîne durable cible est : ```text RAW -> CORE -> DECODE -> SPECIALIZED ``` - **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. ## 0.3.x — RAW / acquisition persistée - [ ] `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. ## Série CORE suivante - [ ] 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. ## Séries DECODE/SPECIALIZED/EXECUTION — progression verticale ### Priorité 1 — Solana Core Programs - [ ] 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. ### Priorité 2 — SPL token/trading - [ ] SPL Token. - [ ] Associated Token Account. - [ ] Token-2022 et extensions pertinentes. - [ ] Pour chaque famille : decode -> materialize -> specialized -> prepare -> policy -> execute -> scenarios. ### Priorité 3 — Metadata token - [ ] 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. - [ ] 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.