156 lines
9.0 KiB
Markdown
156 lines
9.0 KiB
Markdown
<!-- file: ROADMAP.md -->
|
|
<!-- version: 23 -->
|
|
|
|
# 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**.
|
|
- 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
|
|
|
|
- [/] `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.
|
|
- [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`.
|
|
- [/] `0.2.0-pre.003` — Audit de cohérence final : corriger les règles résiduelles supersédées, compléter les fiches `0.2.1+`, préserver les TODO bot3 utiles et finaliser le prompt `0.2.1`.
|
|
|
|
### Releases fonctionnelles décidées/pressenties
|
|
|
|
- [ ] `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.
|
|
|
|
### 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.
|