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.
• Cette règle fixe une durée maximale par release, pas une obligation de changer de session après chaque release : si une release est clôturée plus vite que prévu, la même session peut ouvrir puis clôturer la release suivante si son propre sizing reste positif et si toutes les frontières version/delta/validation sont conservées.
• 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 — Audit bot3, ordre fonctionnel de 0.2.x, architecture durable, discipline de sizing et pipeline RAW/CORE/DECODE/SPECIALIZED stabilisés.
• 0.2.1 — HTTP foundation stable : matrice 52+14, runtime/routing/résilience/exécution HTTP, 4 canaris typés, std.transport, adapter Config -> Transport, canaries de clôture, smoke Devnet opt-in et documentation durable validés ; les 48 wrappers typés restants sont reportés à 0.2.2–0.2.4.

Releases fonctionnelles décidées/pressenties

• 0.2.1 — HTTP transport foundation réduite par le gate pre.001 : crate/settings/JSON-RPC/registry 52 current + 14 deprecated historiques, pool/rôles/limites/retry, Config adapter, documentation et 4 méthodes typées canari (getBalance, getGenesisHash, getHealth, getVersion) publiés stables.
• 0.2.2 — HTTP Accounts + Tokens + Cluster : 22 wrappers typés (5 Accounts + 5 Tokens + 12 Cluster), canaries de complétude 52+14, smoke Devnet Transport pur et smoke historique Config -> Transport validés, documentation durable et prompt 0.2.3 publiés stables.
• 0.2.3 — HTTP Transactions stable : 11/11 wrappers typés publiés, classification 8 Read / 2 WriteSubmission / 1 Simulation, no-resend ambigu prouvé pour les write submissions, KSP-TRANSPORT-007 réaudité conforme sur les 37 wrappers HTTP courants, graphes Cargo et deux smokes Devnet validés ; 0.2.4 reprend les 15 Blocks/Economics restants.
• 0.2.4 — HTTP Blocks + Economics stable : 15/15 wrappers V0_2_4 publiés, surface typed complète à 52/52 méthodes courantes, 14/14 historiques conservées, réaudit SIMD/inventaire final et KSP-TRANSPORT-007 global validés ; deux smokes Devnet passés avant publication.
• [/] 0.2.5 — Wallet foundation : pre.001 fixe le threat model et le format V1 autonome ; pre.002 crée ksp-wallet-lib avec capabilities VIEW/OWNER et frontières ; pre.003 fige l’enveloppe JSON stricte, transcript OWNER/AAD et la spécification externe initiale ; pre.004 ajoute les primitives in-memory Argon2id v19 + XChaCha20-Poly1305 + CSPRNG OS, le wrapping de content keys et un vecteur crypto interopérable. Le choix du profil Argon2 de création reste bloqué sur le benchmark opérateur explicite livré par pre.004. Pubkey reste consommée uniquement via ksp-core-lib; Config/Transport/ExecutionPolicy/Store/Tauri restent hors Wallet. Persistence, state signature, signature Solana, rotations et import/export restent réparties jusqu’à pre.010 ; WalletPolicy reste exclu.
• 0.2.6 — Introduire ksp-app-wallet-desk utilisant Config composite + Wallet + transport HTTP, notamment pour afficher l'identité et le solde d'un wallet.
• 0.2.7 — É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.8 — Ajouter Helius LaserStream WebSocket comme extension du moteur WebSocket standard, sans duplication de client.
• 0.2.9 — Ajouter une première fondation Yellowstone gRPC standard/provider-neutral ; dimensionner la surface exacte à pre.001 selon la documentation normative actuelle.
• 0.2.10 — Introduire ksp-offchain-transport-lib avec un premier lecteur de prix, au minimum SOL/USD et SOL/EUR.
• 0.2.11 — Introduire une petite application desk de visualisation des prix.
• 0.2.12 — Introduire la première surface de ksp-interface-lib, comprenant une API wire publique utilisable par les implémentations officielles et externes.
• 0.2.13 — 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.