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.
• Sélectionner 0.1.1 comme première release fonctionnelle et produire son prompt quasi-final.
• Clôturer la fondation avec documentation, validations et prompt final ; release stable 0.0.3 validée.

0.1.x — Fondations N1

Objectifs

Regrouper les releases consacrées aux fondations N1. Chaque release concrète est une unité de développement/session distincte et commence par son propre pre.001 de brainstorming/audit/planification.

Releases concrètes

• 0.1.1 — Stabiliser ksp-core-lib : Error/Result, Program IDs fondamentaux et primitives réellement N1.
• 0.1.2 — Introduire ksp-logging-lib comme façade KSP de tracing, tracing-appender et tracing-subscriber.
• 0.1.3 — Stabiliser ksp-config-lib : documents, profils, résolution, validation, environnement KSP/KSPB, management/persistence et adapter Logging.
• 0.1.4 — Introduire ksp-app-config-desk pour valider réellement Config et la frontière Tauri.

0.1.1, 0.1.2, 0.1.3 et 0.1.4 sont désormais stables. 0.1.4 publie ksp-app-config-desk comme première validation desktop/Tauri de Config et modèle de référence des futures applications Tauri KSP. La prochaine session est 0.2.0, release intermédiaire d’audit de khadhroony-bot3 et de planification du reste de 0.2.x.

Les contrats publics supplémentaires ne sont introduits que lorsqu'une release concrète en démontre le besoin.

0.2.x — Accès Solana et fondation programmes

Release de cadrage 0.2.0

• 0.2.0 — Auditer les fonctionnalités pertinentes de khadhroony-bot3, décider ce qui doit être repris, refondu, abandonné ou ajouté dans KSP, puis découper et ordonner les releases fonctionnelles restantes de 0.2.x.

0.2.0 est une release intermédiaire de transition et de planification de série. Elle ne doit pas démarrer par l'implémentation arbitraire d'un composant N2 : elle établit d'abord la cartographie fonctionnelle, les écarts avec KSP, les dépendances, les contrats à préserver ou redéfinir et le découpage concret de 0.2.1, 0.2.2, etc.

Capacités à répartir dans les releases fonctionnelles suivantes

• 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 et ProgramExecutionPreparer 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, execution preparers et 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.