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 stable : .kspwallet V1, VIEW/OWNER indépendants, Argon2id/XChaCha20-Poly1305, autorité Ed25519 OWNER, persistence no-clobber, signature, administration/rotations/révocation VIEW forte, import/export Solana CLI JSON + Base58, canaris adversariaux, interop externe et documentation durable publiés. La clôture pre.010-fix.001–fix.003 ajoute ed25519-dalek 3.0.0 direct, normalise le Rust workspace et installe l’audit structurel Python complémentaire à rustfmt/Clippy. Pubkey reste via ksp-core-lib, la keypair reste encapsulée dans Wallet et Config/Transport/ExecutionPolicy/Store/Tauri restent hors Wallet.
• 0.2.6 — ksp-app-wallet-desk + .kspwallet V2 stables : composition Config/Wallet/HTTP/Logging, lifecycle VIEW/OWNER, balance, administration/import/export, wire binaire V2, APIs multi-version, migration V1 -> V2 explicite et runtime Tauri packagé user-writable validés ; bundles Linux .deb/.rpm/.AppImage produits avant publication. Plan clôturé : docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md.
• 0.2.7 — WebSocket Solana standard stable : 9 familles subscribe/unsubscribe typées (18/18 opérations), sessions physiques multiples explicites, subscriptions logiques typées, lifecycle/reconnect/resubscribe/backpressure/shutdown bornés, Config V2, non-régression HTTP 52+14, compliance finale, smoke WebSocket Devnet et audit de dépendances validés ; publication rel.001 et prompt 0.2.8 prêts.
• 0.2.8 — Helius LaserStream WebSocket stable : façade provider dédiée sur l’actor WebSocket partagé, sept familles standard réutilisées (account/logs/program/root/signature/slot/slotsUpdates) + transactionSubscribe/transactionUnsubscribe, block/vote absents, heartbeat Ping 60 s Helius-only, Config V2/secrets redacted, lifecycle adversarial, compliance HTTP 52+14 / Standard WS 18/18 et graphes Cargo finaux validés ; prompt 0.2.9 prêt.
• 0.2.9 — Yellowstone gRPC standard/provider-neutral stable : moteur Tonic/Protobuf KSP partagé, sept unary standard retenues, Subscribe bidi et neuf variantes d’update, lifecycle/backpressure/reconnect/replay bornés sans promesse lossless, Config Transport V3 backward V1/V2 avec provider/protocol séparés, profils PublicNode Mainnet/Testnet authentifiés par x-token, smoke live Subscribe -> Slot 2/2 PASS et graphes Cargo finaux inspectés ; SubscribeDeshred reste hors scope.
• 0.2.10 — OrbitFlare Yellowstone gRPC stable : profil Config V3 Devnet, License Key injectée comme metadata secrète x-token, smoke live Subscribe -> Slot + Ping validé deux fois, sans modification du moteur N1/N2 ni heartbeat provider.
• 0.2.11 — Off-chain price transport stable : ksp-offchain-transport-lib expose SOL/USD via huit adapters REST reqwest sans SDK provider, décimal exact, sémantiques/provenance explicites, registry/availability/rate limits et refresh single/many/all génériques ; Config std.offchain_transport construit le service sans dépendance inverse, DexScreener reste lié à une paire explicite sans discovery, aucun consensus/fallback automatique n’est introduit, et le smoke live keyless final passe 7/7 après correction CoinMarketCap V2.
• 0.2.12 — SOL Prices Desk + projection prix Wallet stables : HID provider-neutral avec refresh row/selected/all et batch 1..=64, observations/timestamps exacts sans polling/consensus, puis refresh balance Wallet enrichi d’une moyenne SOL/USD consumer-owned et d’un équivalent USD exact best-effort ; smoke live de composition, workspace complet et bundles Tauri Linux validés.
• 0.2.13 — Interface / wire foundation stable : ksp-interface-lib expose Pubkey, ProgramAccountMeta et ProgramInstruction passifs, admission bornée à 255 account metas / 10 240 bytes, erreurs et Debug sans payload hostile, façade crate-root et consumer externe canaris ; graphe strict Interface -> Core, sans serde/codec générique, solana-instruction, réseau ni logging runtime.
• 0.2.14 — Program API foundation stable : ksp-program-api expose une surface instruction-only ouverte avec ProgramInstructionRecognition, ProgramInstructionDecodeOutcome<Decoded> et ProgramInstructionDecoder; implémentation externe avec Program Pubkey opaque validée, 10 exports crate-root / 3 modules de production verrouillés, graphe strict Core + Interface, sans registry/runtime/serde/codec/Store/Materializer/Execution. Le prompt 0.3.1 prépare Store RAW-only.

TODO/IDEAS — providers Yellowstone non planifiés

• TODO — Helius LaserStream gRPC : réauditer lorsque l'accès live gRPC est raisonnablement disponible ; conserver N1/N2 Yellowstone inchangés, vérifier auth/endpoints/Subscribe/Ping/replay/from_slot/erreurs provider et traiter les preprocessed transactions comme extension Helius séparée.
• TODO — eRPC : réauditer accès, auth/IP policy, capabilities et produits complémentaires avant toute décision d’implémentation.
• TODO — Triton : réauditer la frontière Yellowstone upstream / extensions Triton, notamment Deshred et futures extensions.
• TODO — Alchemy : réauditer auth, replay, limites et capabilities Yellowstone avant toute intégration.
• TODO — QuickNode : réauditer auth, compression, from_slot, filtres et limites de plan.
• TODO — Chainstack : réauditer networks, auth, add-on et capabilities Yellowstone.
• IDEAS — Tatum, Shyft, Solinfra, NodeFlare et autres providers : conserver comme candidats exploratoires sans numéro de release ni engagement d’implémentation.

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 progression durable cible est :

RAW -> STRUCTURAL -> DECODED -> DOMAIN

• RAW et STRUCTURAL ne nécessitent aucun décodage Program.
• La progression n'est pas une chaîne obligatoire pour chaque famille : une donnée event-only peut s'arrêter en N1, et un état de compte pourra aller directement vers un futur decoder si aucune décomposition STRUCTURAL utile n'existe.
• À la fin des couches horizontales RAW/STRUCTURAL réellement persistées, ajouter les jobs/workers/apps nécessaires avant d'ouvrir la couche suivante.
• À partir de DECODED, avancer verticalement groupe par groupe ; DOMAIN désigne les projections métier et la matérialisation est le processus qui les produit.

0.3.x — RAW / acquisition persistée

• [/] 0.3.1 — Introduire ksp-store-api uniquement avec le modèle objet commun et les contrats N1 RAW/observations : RawTransaction + observations en premier, inventaire/admission cross-source des futurs account/status models, séparation explicite des events realtime non persistés, lifecycle logique de rétention/tombstone, outcomes, queries/pagination et contrats backend, sans persistence concrète ni configuration backend.
• 0.3.2 — Introduire ensemble ksp-store-lib et ksp-store-postgres-lib : façade/runtime Store commune, feature postgres activée par défaut, implémentation PostgreSQL de référence via tokio-postgres, Config std.store/secrets et migrations privées au backend. Un backend connu demandé par Config mais absent des features compilées est rejeté explicitement.
• 0.3.3 — Étendre ksp-interface-lib avec les modèles passifs/wires réellement partagés par acquisition/workers, notamment les events realtime non persistés retenus par l'audit 0.3.1, sans dupliquer les modèles persistants de ksp-store-api.
• 0.3.4 — Introduire ksp-job-api et un job de backfill historique concret consommant uniquement ksp-store-lib côté Store.
• 0.3.5 — 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 à la couche de normalisation générique suivante.

TODO/IDEAS — taxonomie N1, processing et rétention

• TODO — maintenir une matrice d'admission HTTP/WS/gRPC/provider pour chaque modèle N1 : plusieurs sources ne convergent vers un même struct que si elles satisfont la même sémantique sans perte.
• TODO — RawAccountState + observation : auditer les shapes HTTP/WS/Yellowstone, conserver les bytes canoniques et documenter les limites de backfill historique avant de figer la capability de persistence.
• TODO — TransactionStatusObservation : auditer signatureSubscribe, getSignatureStatuses, Yellowstone TransactionStatus et extensions provider ; distinguer persistence éventuelle et déclenchement d'event.
• TODO — logs realtime : conserver logMessages dans RawTransaction jusqu'à la décomposition STRUCTURAL ; traiter logsSubscribe comme event-only candidat et décider son contrat passif dans ksp-interface-lib, sans table Store par défaut. Le format canonique d'un wake-up « donnée persistée disponible » reste distinct et appartient à ksp-store-api conformément à KSP-NOTIFY-*, tandis que sa publication appartient au worker/runtime.
• TODO — slot/root/slotsUpdates et vote : ne créer un modèle passif commun que si un consumer realtime réel et une sémantique cross-ledger/provider justifient le contrat ; aucune persistence Store par défaut.
• IDEA — RawBlock : ne rouvrir que si une information block-level non reconstructible devient nécessaire ; getBlock doit d'abord être traité comme source de RawTransaction, pas comme invitation à recopier le ledger en blocs.
• REJET ACTUEL — Yellowstone Entry : trop bas niveau et aucune destination replay/decomposition/event métier justifiant un modèle KSP n'est identifiée.
• TODO — processing ledger : reprendre l'idée kbot2/kbot3 stage + processor identity/version + input identity/hash + terminal status, sans faire d'un processed: bool la preuve durable unique ; prévoir force replay/version upgrades.
• TODO — lifecycle RAW : prévoir Full -> Compacted -> Archived -> Purged, policy d'éligibilité hors Store, compression/archive backend futures et tombstone minimal empêchant un backfill normal après purge ; une réhydratation doit être explicitement forcée.
• TODO — frontière ksp-interface-lib / ksp-store-api : documenter chaque type partagé afin que les events passifs non persistés vivent dans Interface et que les modèles persistants/replayables vivent dans Store API, sans doublons quasi équivalents.
• IDEA — réauditer la structure de processing/decode/materialization historique kbot2/kbot3 lors de l'ouverture de N2/N3 ; conserver l'isolation instruction/CPI et les statuts terminal/versionnés, sans reprendre automatiquement le schéma SQL historique.

Série STRUCTURAL suivante

• Définir la persistence STRUCTURAL canonique Solana générique pour les familles réellement décomposables.
• Implémenter en priorité RawTransaction -> STRUCTURAL sans decoder Program : transaction/message, comptes/références, instructions top-level, CPI/inner instructions, logs/meta/balances/return data et relations structurelles.
• Vérifier avant extension si d'autres familles N1 possèdent une vraie décomposition STRUCTURAL utile ; ne pas créer de niveau vide par convention.
• Ajouter replay/backfill RAW -> STRUCTURAL avec processing versionné.
• Ajouter worker/service STRUCTURAL et l'application de contrôle/inspection utile.

Séries DECODED/DOMAIN/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 -> domain projection -> 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 DOMAIN 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.