khadhroony-solana-project/ROADMAP.md

Roadmap KSP

Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. Une série X.Y.x regroupe une famille fonctionnelle ; chaque release concrète reste une unité de développement/session distincte.

Légende

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

Discipline de livraison

• Une prerelease vise environ 15 à 20 minutes de travail effectif.
• Une release concrète doit être dimensionnée pour pouvoir être ouverte et clôturée dans une seule session de chat.
• Si pre.001 révèle qu'une release est trop grosse, elle est scindée avant implémentation fonctionnelle lourde.
• À partir des couches Program/Decode, KSP progresse verticalement groupe par groupe plutôt que par grandes vagues horizontales de decoders/materializers/executors séparés.

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

• 0.1.1 — ksp-core-lib : Error/Result, Program IDs fondamentaux et primitives N1.
• 0.1.2 — ksp-logging-lib : façade KSP de tracing.
• 0.1.3 — ksp-config-lib : documents, profils, environnement, persistence et adapters.
• 0.1.4 — ksp-app-config-desk : première application Tauri de référence.

0.2.x — Accès Solana, Wallet et contrats d'extension initiaux

Cadrage

• [/] 0.2.0 — Auditer bot3, fixer l'ordre de 0.2.x, actualiser l'architecture et préparer 0.2.1.
• 0.2.0-pre.001 — Méthode d'audit, cartographie initiale et matrice provisoire.
• 0.2.0-pre.002 — Fixer l'ordre fonctionnel, la discipline de sizing, le pipeline RAW/CORE/DECODE/SPECIALIZED et préparer le prompt 0.2.1.
• [/] 0.2.0-pre.003 — Audit de cohérence final : corriger les règles résiduelles supersédées, compléter les fiches 0.2.1+, préserver les TODO bot3 utiles et finaliser le prompt 0.2.1.

Releases fonctionnelles décidées/pressenties

• 0.2.1 — Introduire ksp-onchain-transport-lib avec HTTP Solana/JSON-RPC, settings publics, document Config standard + adapter, pools, rôles, priorités, limites, retry/backoff et couverture complète de la documentation HTTP ciblée.
• 0.2.2 — Introduire ksp-wallet-lib, le format .kspwallet, la gestion sûre des secrets et une architecture d'import/export extensible ; exclure WalletPolicy.
• 0.2.3 — Introduire ksp-app-wallet-desk utilisant Config composite + Wallet + transport HTTP, notamment pour afficher l'identité et le solde d'un wallet.
• 0.2.4 — Étendre ksp-onchain-transport-lib au WebSocket Solana standard complet ; permettre plusieurs sessions sur une même URL sans imposer encore un pool automatique complexe.
• 0.2.5 — Ajouter Helius LaserStream WebSocket comme extension du moteur WebSocket standard, sans duplication de client.
• 0.2.6 — Ajouter une première fondation Yellowstone gRPC standard/provider-neutral ; dimensionner la surface exacte à pre.001 selon la documentation normative actuelle.
• 0.2.7 — Introduire ksp-offchain-transport-lib avec un premier lecteur de prix, au minimum SOL/USD et SOL/EUR.
• 0.2.8 — Introduire une petite application desk de visualisation des prix.
• 0.2.9 — Introduire la première surface de ksp-interface-lib, comprenant une API wire publique utilisable par les implémentations officielles et externes.
• 0.2.10 — Introduire ksp-program-api comme premier contrat Program extensible, sans imposer encore ksp-program-lib complet.

Règles Transport pour toute la série

• Couvrir toutes les méthodes/opérations documentées pour la surface normative ciblée par chaque release.
• Conserver les méthodes deprecated/obsolete encore fonctionnelles et émettre un warn KSP lors de leur utilisation.
• Implémenter les méthodes unstable/experimental ciblées et émettre un warn KSP lors de leur utilisation.
• Centraliser la metadata de statut des méthodes plutôt que disperser des warnings ad hoc.
• Garder ksp-onchain-transport-lib indépendant de ksp-config-lib, du Store et des modèles Program/métier.

Architecture de données — progression canonique

La chaîne durable cible est :

RAW -> CORE -> DECODE -> SPECIALIZED

• RAW et CORE ne nécessitent aucun décodage Program.
• À la fin de chaque couche horizontale RAW/CORE, ajouter les jobs/workers/apps nécessaires pour la rendre réellement exploitable avant d'ouvrir la couche suivante.
• À partir de DECODE, avancer verticalement groupe par groupe : wire -> decode -> matérialisation -> projection spécialisée si utile -> préparation d'exécution -> policy -> execution -> scénarios Devnet.

0.3.x — RAW / acquisition persistée

• 0.3.1 — Introduire ksp-store-api + ksp-store-lib avec PostgreSQL de référence et modèles/persistence RAW uniquement.
• 0.3.2 — Étendre ksp-interface-lib avec les wires génériques nécessaires aux acquisitions et à la future normalisation CORE.
• 0.3.3 — Introduire ksp-job-api et un job de backfill historique concret.
• 0.3.4 — Introduire une application spécialisée de backfill/inspection RAW.
• Compléter ensuite la couche RAW avec le worker/service live, son contrôle et les outils d'exploitation réellement nécessaires avant de passer à CORE.

Série CORE suivante

• Définir la persistence CORE canonique Solana générique.
• Implémenter RAW -> CORE sans decoder Program : blocs, slots, signatures, transactions/messages, comptes, instructions/CPI brutes, logs/meta et relations structurelles.
• Ajouter replay/backfill RAW -> CORE.
• Ajouter worker/service CORE.
• Ajouter l'application de contrôle/inspection CORE utile.

Séries DECODE/SPECIALIZED/EXECUTION — progression verticale

Priorité 1 — Solana Core Programs

• Wire/decoding des programmes Core nécessaires transversalement.
• Matérialisation et projections utiles.
• Préparation d'exécution, policy et scénarios Devnet pour les opérations retenues.

Priorité 2 — SPL token/trading

• SPL Token.
• Associated Token Account.
• Token-2022 et extensions pertinentes.
• Pour chaque famille : decode -> materialize -> specialized -> prepare -> policy -> execute -> scenarios.

Priorité 3 — Metadata token

• Metaplex Token Metadata.
• Token-2022 Metadata.
• [R] Solana Program Metadata (SPM) — redéveloppement plus tard avec le décodage généraliste.

Priorité 4 — Anchor

• Introduire les contrats et mécanismes Anchor nécessaires aux protocoles trading suivants.

Priorité 5 — DEX à fort intérêt

• Meteora, y compris vaults/fees/positions/états auxiliaires nécessaires à son groupe.
• Raydium, y compris programmes satellites nécessaires.
• Pump, y compris fee program et composants launch/bonding/pool nécessaires.
• Orca, y compris programmes satellites nécessaires.
• Chaque groupe est terminé verticalement avant de devenir secondaire au profit du suivant.

Market Desk V1

• Après les premiers groupes Meteora/Raydium/Pump/Orca, introduire une petite ksp-app-market-desk spécialisée.
• Visualiser tokens, pools/markets, liquidité, swaps/trades, prix, volumes, OHLC/candles et activité live/récente lorsque disponible.
• Lire les projections SPECIALIZED KSP ; ne pas reconstruire la logique protocolaire dans l'UI.

Routing

• Jupiter.
• OKX et autres routeurs selon besoin réel.
• Enrichir Market Desk avec routes, legs, DEX impliqués, fees/slippage et comparaison quote/execution lorsque disponible.

Trading-adjacent puis décodage généraliste

• Ajouter ensuite les programmes indépendants utiles au trading : oracles, locks/vesting indépendants, lifecycle token, risk/signaux, etc.
• Ne jamais y repousser un satellite appartenant à un groupe DEX déjà ciblé.
• Étendre enfin le décodage au reste de Solana selon valeur fonctionnelle.

Trading Intelligence et produits ultérieurs

• Statistiques/features/datasets historiques.
• Signaux, risque, anomalies et patterns.
• Replay analytique/backtests.
• XGBoost puis autres modèles lorsque les données et contrats sont stables.
• Construire ensuite les produits de trading opérationnel au-dessus de ces couches.
• Faire évoluer Market Desk vers davantage d'analyse sans la confondre avec l'application globale ou l'orchestrateur.
• Étudier plus tard les autres applications Wallet : mobile, extensions navigateur et web.