# 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 - [X] `0.0.1` — Initialiser le dépôt. - [X] `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--lib` spécialisées. - [ ] Ajouter les demos `ksp-app-scenario---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. - [ ] Garder jobs et workers sous des lifecycle APIs séparées. - [ ] Introduire un orchestrateur global lorsqu'il existe plusieurs managers/workers à coordonner. - [ ] Introduire l'application globale de supervision/contrôle. ## 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.