6.7 KiB
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.1comme première release fonctionnelle et produire son prompt quasi-final. - Clôturer la fondation avec documentation, validations et prompt final ; release stable
0.0.3validé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— Stabiliserksp-core-lib:Error/Result, Program IDs fondamentaux et primitives réellement N1.0.1.2— Introduireksp-logging-libcomme façade KSP detracing,tracing-appenderettracing-subscriber.0.1.3— Stabiliserksp-config-lib: documents, profils, résolution, validation, environnement KSP/KSPB, management/persistence et adapter Logging.0.1.4— Introduireksp-app-config-deskpour valider réellement Config et la frontière Tauri.
0.1.1, 0.1.2 et 0.1.3 sont désormais stables. 0.1.4 constitue l'étape active suivante avec ksp-app-config-desk, première validation desktop/Tauri de Config et modèle des futures applications Tauri KSP.
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
- Introduire
ksp-onchain-transport-libavec des modèles de transport homogènes indépendants du store. - Introduire
ksp-wallet-libetksp-app-wallet-desk. - Développer la première surface utile de
ksp-interface-lib. - Introduire
ksp-program-apipuisksp-program-lib. - Définir
ksp-execution-policy-apicomme contrat de policy commun à plusieurs contextes. - Introduire
ksp-execution-liblorsque le premier cycle d'exécution réel justifie l'orchestration programme/policy/wallet/transport. - Introduire
ksp-offchain-transport-libseulement 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-libavec 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-apietksp-worker-raw-retriever. - Introduire
ksp-worker-control-liblorsque le manager W1 crée le premier besoin concret. - Introduire
ksp-job-apietksp-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
ProgramExecutionPreparerCore/SPL nécessaires. - Ajouter Token, Token-2022, ATA et metadata utiles.
- Introduire
ksp-offchain-transport-libau plus tard au premier besoin externe. - Ajouter materializers et jobs ponctuels nécessaires.
- Ajouter les crates
ksp-scenario-<domain>-libspécialisées. - Ajouter les demos
ksp-app-scenario-<domain>-<environment>-desk-democorrespondantes. - 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-processorpour D1 Raw -> D2 Core canonique. - Introduire
ksp-worker-generic-materializerpour D2 Core -> D3 journal de matérialisation générique. - Introduire
ksp-worker-domain-projectorpour 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.