200 lines
9.0 KiB
Markdown
200 lines
9.0 KiB
Markdown
<!-- file: ROADMAP.md -->
|
|
<!-- version: 4 -->
|
|
|
|
# Roadmap KSP
|
|
|
|
Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues pour y parvenir. Il ne remplace ni les plans détaillés de version ni les deltas de livraison.
|
|
|
|
## Légende
|
|
|
|
- `[ ]` — prévu / non commencé ;
|
|
- `[/]` — en cours ;
|
|
- `[X]` — réalisé et validé ;
|
|
- `[C]` — annulé ;
|
|
- `[R]` — reporté vers une autre phase ou version.
|
|
|
|
Une case `[X]` signifie que l'étape est considérée terminée selon ses critères de validation, et pas seulement qu'une modification a été écrite.
|
|
|
|
## 0.0.x — Fondation de Khadhroony Solana Project
|
|
|
|
### Objectifs
|
|
|
|
Définir l'identité, les règles, les conventions, l'architecture initiale et le mode de travail de KSP avant le début du développement fonctionnel. La phase doit aboutir à un workspace initial cohérent, à un plan global suffisamment précis pour guider les premières versions de développement et à un prompt de reprise permettant d'ouvrir `0.1.x` sans réinventer les décisions fondatrices.
|
|
|
|
### Étapes
|
|
|
|
- [X] `0.0.1` — Initialiser le dépôt avec le `.gitignore` de base.
|
|
- [X] `0.0.2` — Installer le squelette minimal, les règles initiales et les documents de cadrage nécessaires.
|
|
- [/] `0.0.3` — Définir les objectifs produits, domaines fonctionnels, couches, responsabilités, dépendances, contrats publics, applications/workers/jobs/demos et plan global de développement.
|
|
- [/] Construire progressivement le prompt de démarrage `0.1.x`.
|
|
- [ ] Clôturer la phase fondatrice avec les documents finaux, le squelette nécessaire et le prompt final permettant d'ouvrir `0.1.x`.
|
|
|
|
### Status
|
|
|
|
En cours.
|
|
|
|
## 0.1.x — Fondations KSP
|
|
|
|
### Objectifs
|
|
|
|
Construire les premières fondations réellement transversales et valider le principe selon lequel une application spécialisée reste une interface au-dessus de la bibliothèque qu'elle manipule.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Stabiliser les premiers contrats de `ksp-core-lib`, dont le type d'erreur commun et les Program IDs.
|
|
- [ ] Introduire `ksp-logging-lib`.
|
|
- [ ] Introduire `ksp-config-lib`.
|
|
- [ ] Introduire `ksp-app-config-desk` comme interface de lecture/modification des paramètres autorisés.
|
|
- [ ] Définir suffisamment tôt les premiers contrats publics nécessaires aux couches suivantes sans implémenter prématurément leurs fonctionnalités.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.2.x — Accès Solana et fondation programmes
|
|
|
|
### Objectifs
|
|
|
|
Fournir les transports et identités nécessaires pour interagir avec Solana, établir la façade wire KSP et exposer les premiers contrats publics extensibles de décodage/exécution.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Introduire `ksp-onchain-transport-lib`.
|
|
- [ ] Introduire `ksp-wallet-lib`.
|
|
- [ ] Introduire `ksp-app-wallet-desk`.
|
|
- [ ] Développer la première surface utile de `ksp-interface-lib`.
|
|
- [ ] Introduire `ksp-program-api` comme contrat public extensible des decoders/executors.
|
|
- [ ] Introduire `ksp-program-lib` comme implémentation officielle intégrée des programmes supportés.
|
|
- [ ] Garantir que les contrats `ksp-program-api` puissent être implémentés et testés depuis des crates séparées sans dépendre de `ksp-program-lib`.
|
|
- [ ] Introduire `ksp-offchain-transport-lib` seulement si un besoin concret apparaît pendant cette phase.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.3.x — Données, stockage et acquisition raw
|
|
|
|
### Objectifs
|
|
|
|
Mettre en place les contrats de matérialisation et de stockage, l'acquisition raw live/quasi-live et des jobs historiques/ponctuels séparés des workers continus.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Introduire `ksp-materializer-api` comme contrat public/extensible de matérialisation.
|
|
- [ ] Introduire `ksp-materializer-lib` comme implémentation officielle des materializers KSP.
|
|
- [ ] Introduire `ksp-store-api` comme frontière backend-agnostic et propriétaire des contrats canoniques de notification de données persistées.
|
|
- [ ] Introduire `ksp-store-lib` avec PostgreSQL comme implémentation de référence.
|
|
- [ ] Introduire `ksp-app-store-desk`.
|
|
- [ ] Introduire W1 pour l'acquisition raw live/quasi-live uniquement.
|
|
- [ ] Permettre à W1 de modifier à chaud ce qu'il écoute/rapatrie/stocke.
|
|
- [ ] Introduire `ksp-worker-api` pour les contrats communs des workers sans y inclure les jobs.
|
|
- [ ] Introduire les premières capacités de contrôle/manager de W1, avec `ksp-worker-control-lib` comme candidat d'implémentation lorsque nécessaire.
|
|
- [ ] Introduire `ksp-job-api` pour les contrats communs des jobs, séparément des workers.
|
|
- [ ] Introduire `ksp-job-backfill` comme job historique à la demande, avec checkpoint/reprise et gouvernance propres.
|
|
- [ ] Utiliser les mêmes contrats de notification de données pour une même donnée, qu'elle provienne de W1, d'un backfill ou d'une autre source.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.4.x — Baseline Solana, SPL et metadata
|
|
|
|
### Objectifs
|
|
|
|
Commencer la couverture fonctionnelle des programmes nécessaires à l'objectif trading court terme et aux couches suivantes, en validant décodage, exécution technique, matérialisation et scénarios spécialisés.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Ajouter les premiers decoders/executors Solana Core utiles.
|
|
- [ ] Ajouter les premières surfaces SPL utiles : Token, Token-2022, ATA et autres besoins identifiés.
|
|
- [ ] Ajouter les metadata d'assets/tokens nécessaires.
|
|
- [ ] Introduire `ksp-offchain-transport-lib` au plus tard au premier besoin réel externe.
|
|
- [ ] Ajouter les materializers correspondants.
|
|
- [ ] Ajouter les jobs ponctuels nécessaires, par exemple metadata/off-chain, uniquement lorsqu'un besoin concret le justifie.
|
|
- [ ] Ajouter les tools/scénarios de validation spécialisés dans des crates séparées par domaine cohérent.
|
|
- [ ] Maintenir les demos/scénarios Memo, Token, ATA et Token-2022 séparés.
|
|
- [ ] Permettre une famille metadata commune pour Metaplex Token Metadata + Token-2022 Metadata.
|
|
- [ ] Maintenir Solana Program Metadata dans une famille distincte.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.5.x — Anchor et protocoles trading
|
|
|
|
### Objectifs
|
|
|
|
Étendre progressivement KSP vers Anchor et les protocoles/infrastructures nécessaires à l'analyse et au trading Solana, une surface cohérente et bornée par release.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Introduire la fondation Anchor.
|
|
- [ ] Étendre progressivement Meteora par surfaces distinctes.
|
|
- [ ] Étendre progressivement Raydium par surfaces distinctes.
|
|
- [ ] Ajouter progressivement Pump, Orca, Jupiter, OKX et autres intégrations utiles.
|
|
- [ ] Ajouter pour chaque surface les interfaces, decoders/executors, materializers, jobs éventuels, scénarios et validations nécessaires.
|
|
- [ ] Maintenir l'ordre précis des releases adaptable aux dépendances découvertes et aux priorités du trading court terme.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.6.x — Processing autonome et orchestration
|
|
|
|
### Objectifs
|
|
|
|
Introduire le processing continu des données acquises, la gouvernance de plusieurs workers et une application globale de supervision sans déplacer leur logique dans l'interface.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Introduire W2 pour les traitements live de décodage/matérialisation selon les contrats alors stabilisés.
|
|
- [ ] Réutiliser `ksp-worker-api` pour les contrats communs des workers.
|
|
- [ ] Introduire/étendre `ksp-worker-control-lib` lorsque plusieurs workers justifient un contrôle commun.
|
|
- [ ] Garder les contrats et contrôles des jobs séparés de ceux des workers.
|
|
- [ ] Introduire un orchestrateur commun lorsque plusieurs managers/workers le justifient.
|
|
- [ ] Introduire une application globale de supervision et contrôle.
|
|
- [ ] Exposer les états, health, backlog, erreurs, reprises et commandes nécessaires sans dupliquer la logique des workers/jobs.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.7.x — Trading Intelligence
|
|
|
|
### Objectifs
|
|
|
|
Construire la couche d'analyse statistique et d'intelligence nécessaire aux futures automatisations de trading, avant de stabiliser l'application de trading proprement dite.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Définir statistiques et métriques utiles.
|
|
- [ ] Définir les features et datasets historiques.
|
|
- [ ] Définir les contrats de signal et risque.
|
|
- [ ] Introduire replay analytique et backtests.
|
|
- [ ] Détecter patterns et anomalies.
|
|
- [ ] Intégrer XGBoost lorsque les contrats d'entrée/sortie sont suffisamment stables.
|
|
- [ ] Préparer l'intégration d'autres modèles et les futures couches de décision/automatisation.
|
|
|
|
### Status
|
|
|
|
Planifié.
|
|
|
|
## 0.8.x et suivantes — Extension continue et applications trading
|
|
|
|
### Objectifs
|
|
|
|
Poursuivre la couverture Solana, exploiter Trading Intelligence dans des couches de trading opérationnelles puis faire évoluer les autres produits au-dessus des mêmes contrats KSP.
|
|
|
|
### Étapes
|
|
|
|
- [ ] Étendre continuellement les Program IDs, interfaces, decoders/executors et materializers utiles.
|
|
- [ ] Construire progressivement les couches de trading opérationnelles et l'application de trading monoposte.
|
|
- [ ] Étendre l'automatisation de trading.
|
|
- [ ] Construire progressivement l'explorer Solana.
|
|
- [ ] Construire progressivement l'explorer/analyse DEX.
|
|
- [ ] Étendre Trading Intelligence et les modèles disponibles.
|
|
|
|
### Status
|
|
|
|
Planifié.
|