# 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é.