khadhroony-solana-project/ROADMAP.md

Roadmap KSP

Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues pour y parvenir. Une série X.Y.x regroupe une famille fonctionnelle de travaux ; elle peut contenir plusieurs releases concrètes et plusieurs sessions.

Les décisions architecturales négatives ou de prudence n'apparaissent pas comme des tâches à cocher. Elles sont conservées dans les règles et documents d'architecture.

Légende

• [ ] — prévu / non commencé ;
• [/] — en cours ;
• [X] — réalisé et validé ;
• [C] — annulé ;
• [R] — reporté.

0.0.x — Fondation

• 0.0.1 — Initialiser le dépôt.
• 0.0.2 — Installer le squelette minimal et les règles initiales.
• [/] 0.0.3 — Définir domaines, composants, dépendances, contrats, workers/jobs/scénarios/apps et plan global.
• [/] Construire progressivement le prompt de démarrage 0.1.x.
• Clôturer la fondation avec documentation, validations et prompt final.

0.1.x — Fondations N1

Objectifs

Regrouper les releases consacrées aux fondations N1. La série n'est pas destinée à tenir dans une seule session : chaque release concrète (0.1.1, 0.1.2, etc.) sera dimensionnée séparément.

Étapes

• Stabiliser ksp-core-lib, dont Error et Program IDs.
• Introduire ksp-logging-lib.
• Introduire ksp-config-lib.
• Introduire ksp-app-config-desk.
• Définir au besoin les premiers contrats publics requis par les couches suivantes sans anticiper leur implémentation complète.

0.2.x — Accès Solana et fondation programmes

• Introduire ksp-onchain-transport-lib avec des modèles de transport homogènes indépendants du store.
• Introduire ksp-wallet-lib et ksp-app-wallet-desk.
• Développer la première surface utile de ksp-interface-lib.
• Introduire ksp-program-api puis ksp-program-lib.
• Définir ksp-execution-policy-api comme contrat de policy commun à plusieurs contextes.
• Introduire ksp-execution-lib lorsque le premier cycle d'exécution réel justifie l'orchestration programme/policy/wallet/transport.
• Introduire ksp-offchain-transport-lib seulement au premier besoin réel.

0.3.x — Données, stockage et acquisition raw

• Introduire ksp-materializer-api / ksp-materializer-lib.
• Introduire ksp-store-api / ksp-store-lib avec PostgreSQL de référence.
• Établir les niveaux durables D1 Raw, D2 Core, D3 journal de matérialisation générique et D4 projections de domaine.
• Garantir des replays indépendants D1 -> D2, D2 -> D3 et D3 -> D4.
• Introduire ksp-app-store-desk.
• Introduire ksp-worker-api et ksp-worker-raw-retriever.
• Introduire ksp-worker-control-lib lorsque le manager W1 crée le premier besoin concret.
• Introduire ksp-job-api et ksp-job-backfill.
• Introduire les pipelines spécialisés raw ingestion, Core processing, generic materialization et domain projection lorsque leurs premières frontières fonctionnelles sont développées.
• Introduire les jobs de replay indépendants D1 -> D2, D2 -> D3 et D3 -> D4.
• Normaliser les notifications de données persistées indépendamment de leur producteur et conserver le Store comme source de vérité du backlog.
• Mettre en place claim/lease, outcomes durables et reprise après crash pour les traitements concurrents.

0.4.x — Baseline Solana, SPL et metadata

• Ajouter progressivement les decoders/executors Core/SPL nécessaires.
• Ajouter Token, Token-2022, ATA et metadata utiles.
• Introduire ksp-offchain-transport-lib au plus tard au premier besoin externe.
• Ajouter materializers et jobs ponctuels nécessaires.
• Ajouter les crates ksp-scenario-<domain>-lib spécialisées.
• Ajouter les demos ksp-app-scenario-<domain>-<environment>-desk-demo correspondantes.
• Garder Memo, Token, ATA, Token-2022 séparés ; regrouper uniquement Metaplex Token Metadata + Token-2022 Metadata dans la famille metadata ; garder SPM séparé.

0.5.x — Anchor et protocoles trading

• Introduire Anchor.
• Étendre Meteora par surfaces bornées.
• Étendre Raydium par surfaces bornées.
• Ajouter progressivement Pump, Orca, Jupiter, OKX et autres intégrations utiles.
• Ajouter interfaces, program implementations, materializers, jobs/scénarios/demos nécessaires pour chaque surface.

0.6.x — Processing autonome et orchestration

• Introduire ksp-worker-core-processor pour D1 Raw -> D2 Core canonique.
• Introduire ksp-worker-generic-materializer pour D2 Core -> D3 journal de matérialisation générique.
• Introduire ksp-worker-domain-projector pour D3 -> D4 projections spécialisées ; nom révisable.
• Exploiter les mêmes pipelines spécialisés pour les workers live et les jobs de replay afin d'éviter la duplication des frontières de processing.
• Étendre ksp-worker-control-lib à la gouvernance de plusieurs workers autonomes.
• Fournir pour chaque worker un mode service autonome, avec logique réutilisable séparée du binaire d'enveloppe.
• Construire d'abord les applications spécialisées nécessaires au développement, test et exploitation de chaque capacité.
• Garder jobs et workers sous des lifecycle APIs séparées.

0.7.x — Trading Intelligence

• Statistiques et métriques.
• Features et datasets historiques.
• Signaux et risque.
• Replay analytique/backtests.
• Patterns/anomalies.
• XGBoost puis autres modèles lorsque les contrats sont stables.

0.8.x et suivantes — Trading opérationnel et expansion produits

• Construire les couches puis l'application de trading monoposte au-dessus de Trading Intelligence.
• Étendre l'automatisation de trading.
• Étendre continuellement Program IDs, decoders/executors/materializers.
• Construire progressivement l'explorer Solana.
• Construire progressivement l'explorer/analyse DEX.
• Étudier plus tard d'autres applications utilisant ksp-wallet-lib, notamment mobile, extensions navigateur et web.