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 — ksp-store-api stable : modèles N1 RAW backend-agnostic RawTransaction et RawAccountState avec observations, provenance, payload/hash/timestamps bornés, 10 capabilities object-safe, queries cursorisées sans plafond métier arbitraire, outcomes idempotence/conflit et lifecycle logique rétention/tombstone/force-rehydrate ; aucun backend physique, Config, runtime Store, notification dédiée ni surface STRUCTURAL/DECODED/DOMAIN.
• 0.3.2 — ksp-store-lib + ksp-store-postgres-lib stables comme fondation runtime/backend PostgreSQL : feature postgres par défaut, Store lié à un unique RawNetworkId, Config std.store avec targets/bases devnet/mainnet/testnet, pool Deadpool borné, tokio-postgres, TLS Rustls Disabled/VerifyFull, moteur de migrations privé V000 + SHA-256/advisory lock, health/readiness portable et close borné. Gate complet + PostgreSQL réel major 17 verts ; aucune table/capability RawTransaction/RawAccountState métier n'est encore ajoutée.
• 0.3.3 — Vertical slice PostgreSQL RawTransaction complète sur ksp-store-lib + ksp-store-postgres-lib : six capabilities transaction/observation/rétention, V001 physique liée à un réseau, acquisition canonical+observation atomique, idempotence/conflit, get/list keyset cursorisé, archive/purge/tombstone/ForceRehydrate, hardening des erreurs et du schéma, concurrence et rollback validés sur PostgreSQL 17.
• 0.3.4 — Vertical slice PostgreSQL RawAccountState complète sur ksp-store-lib + ksp-store-postgres-lib : quatre capabilities account ajoutées aux six transaction pour une conformance RAW 10/10, V002 additive de 32 ressources au-dessus de V000/V001 immuables, state+observation atomiques, idempotence/conflit exacts, metadata Yellowstone observation-only, get/list keyset (slot,pubkey,state_hash) avec cursor KSPA anti-replay, hardening cross-family et live validé sur PostgreSQL 17 sans rétention destructive account.
• 0.3.5 — ksp-interface-lib étendu avec deux familles passives réellement partagées : SlotLifecycleEvent (Processed, FirstShredReceived, Completed, CreatedBank, Dead, OptimisticallyConfirmed, Rooted) et TransactionExecutionEvent (slot + TransactionSignature[64] + Succeeded/Failed). Interface reste Core-only, provider-neutral, sans serde/codec/runtime/event bus et sans duplication de RawTransaction/RawAccountState; les DTOs riches restent Transport-owned et les candidats non convergents restent différés.
• 0.3.6 — ksp-job-api + ksp-job-backfill-lib stables pour la première verticale historique RawTransaction : lifecycle/cancellation/latest-value runtime-neutral, scopes Latest/Before/After/signatures explicites, découverte/hydratation Transport observée, RAW v1 canonique, persistance Store atomique/idempotente, concurrence bornée, frontier contiguë, checkpoint/reprise caller-owned, snapshots sûrs et hardening externe sans dépendance backend/provider directe.
• 0.3.7 — Introduire ksp-app-backfill-desk, application Tauri spécialisée de contrôle et monitoring de ksp-job-backfill-lib, composée via Config : sélection de composition/profil, lancement/annulation, scopes/anchors, limites, progression latest-value, compteurs, frontier/checkpoint/reprise et outcome terminal. Elle ne devient ni navigateur Store généraliste, ni scheduler, ni propriétaire des retries/providers/backends.
• 0.3.8 — Introduire ksp-app-store-desk V1, application Tauri backend-agnostique de diagnostic, consultation et requêtage du Store via ksp-store-lib + Config : health/capabilities, RawTransaction, RawAccountState, observations, rétention/tombstones et pagination sûre. Cette application évoluera ensuite avec les couches STRUCTURAL, DECODED, processing/materialization et DOMAIN réellement ajoutées au Store, sans SQL ni backend physique dans l'UI.
• 0.3.9 — Introduire ksp-worker-api comme API générique de lifecycle/health/progression pour services continus, en reprenant le pattern latest-value stabilisé par Job tout en gardant les sémantiques Worker distinctes des jobs terminables et des wake-ups Store post-commit.
• 0.3.10 — Introduire ksp-worker-raw-transaction-ingest-lib pour l'acquisition continue de RawTransaction via les surfaces live de ksp-onchain-transport-lib, persistance atomique par ksp-store-lib, reprise/backpressure/idempotence et notifications ksp-worker-api, sans decode Program ni dépendance backend/provider directe.
• 0.3.11 — Introduire ksp-app-raw-transaction-ingest-desk, application Tauri spécialisée de contrôle et monitoring du worker live : lifecycle, health, rates, backpressure, reconnect/recovery et compteurs sûrs ; la consultation détaillée des données persistées reste la responsabilité de ksp-app-store-desk.

TODO/IDEAS — applications spécialisées et control plane

• TODO — faire évoluer ksp-app-store-desk avec chaque nouvelle couche réellement persistée : RAW d'abord, puis STRUCTURAL, DECODED, journal de processing/materialization et projections DOMAIN selon les contrats effectivement disponibles. Les vues avancées restent backend-agnostiques et passent uniquement par ksp-store-lib.
• TODO — différer une future ksp-app-control-desk jusqu'à ce que KSP dispose au minimum d'un niveau N3/D3 de processing/materialization exploitable et de plusieurs decoders réels. Cette application sera une surface end-user simplifiée : démarrer/arrêter les flux autorisés, lancer une recherche courante, voir l'état global et les erreurs importantes. Elle ne recopiera pas le diagnostic détaillé, les réglages avancés, les tables complètes ni toutes les fonctions des ksp-app-*-desk spécialisées, qui resteront les outils d'administration, développement et investigation approfondie.

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

• TODO — maintenir la matrice d’admission HTTP/WS/gRPC/provider lors de toute nouvelle famille N1 : plusieurs sources ne convergent vers un même struct que si elles satisfont la même sémantique sans perte.
• RawAccountState + observation — contrat commun stabilisé en 0.3.1 avec bytes complets + slot, provenance séparée et enrichissements source-specific optionnels ; la persistence PostgreSQL physique est complétée en 0.3.4 avec les quatre capabilities account et la conformance RAW 10/10.
• TODO — statut/commitment transactionnel restant : 0.3.5 couvre uniquement le fait passif d’exécution slot + signature + outcome; réauditer séparément signatureSubscribe et getSignatureStatuses lorsqu’un consumer de commitment/snapshot réel apparaît, sans fusionner snapshot, transition et execution update dans un modèle Option-soup.
• IDEA — logs realtime enrichis : logsSubscribe alimente déjà la projection minimale TransactionExecutionEvent, mais un éventuel TransactionLogEvent portant les lignes de log reste différé dans docs/IDEAS.md jusqu’à démonstration d’un consumer et de bornes explicites. logMessages reste dans RawTransaction jusqu’à STRUCTURAL ; le wake-up post-commit reste distinct et Store API-owned conformément à KSP-NOTIFY-*.
• slot/root/slotsUpdates — 0.3.5 stabilise SlotLifecycleEvent pour l’intersection réellement partagée, sans persistence Store par défaut et sans promettre l’ordre/complétude du flux.
• TODO — vote realtime : reste hors Interface tant qu’aucun consumer transversal et aucune sémantique provider-neutral suffisamment précise ne justifient un contrat partagé.
• 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 lorsque les processors seront ouverts.
• lifecycle RAW logique — RawRetentionState, tombstone minimal, normal-skip et force-rehydrate sont stabilisés en 0.3.1 pour RawTransaction.
• rétention physique RawTransaction PostgreSQL — 0.3.3 matérialise Full -> Archived -> Purged, tombstone et ForceRehydrate atomiques ; Compacted reste explicitement unsupported tant qu’aucune représentation compactée réelle n’existe.
• TODO — policy de rétention/compaction : définir les critères d’éligibilité fondés sur les preuves de processing et la maintenance worker/job ; Store applique une transition demandée mais ne décide pas seul qu’un RAW peut être archivé/purgé, et la compaction physique ne sera ajoutée qu’avec un besoin réel.
• frontière ksp-interface-lib / ksp-store-api — ownership documenté et canaris de non-duplication stabilisés en 0.3.1; les events passifs non persistés restent Interface, les modèles persistants/replayables restent Store API.
• 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 le worker/service STRUCTURAL utile sans le coupler à un worker RAW concret.
• Faire évoluer ksp-app-store-desk avec des vues/requêtes STRUCTURAL lorsque cette couche est réellement persistée ; ne pas créer une seconde application de browsing des mêmes données.

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.