khadhroony-solana-project/ROADMAP.md

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

• 0.0.1 — Initialiser le dépôt avec le .gitignore de base.
• 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é.