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 — Introduire ksp-app-wallet-desk utilisant Config composite + Wallet + transport HTTP. pre.001 fixe le sizing et le gabarit ; pre.002 matérialise la crate Tauri et son shell splash/main avec Config + Logging bootstrap, ports 1432/1433, Bootstrap, Font Awesome, DataTables/Select, SimpleBar, resize-observer-polyfill, TS-RS et bridge frontend Logging. pre.003 matérialise cfg.std.wallet/schema.std.wallet, le composite cfg.composite.ksp-app-wallet-desk, ResolvedWalletConfig, wallets_directory global + wallets_subdirectory par profil et la préparation automatique des répertoires côté application avec logs debug/error. pre.003-fix.001 corrige les premiers canaris Config et active la trace des interactions frontend sans valeur de contrôle. pre.003-fix.002 corrige le scanner .env.example sur les fragments d’identifiants Rust, généralise std.logging avec les profils console-only, file_info, superdev et supertrace, et sélectionne temporairement supertrace dans le composite Wallet Desk. pre.003-fix.003 corrige les canaris de ce changement : closures explicites compatibles avec clippy::implicit_return et distinction entre fragment KSP incorporé dans un identifiant et nom d’environnement concret suffixé. pre.003-fix.004 corrige les cinq closures restantes du canari de composition Wallet Desk afin que cargo clippy --workspace --all-targets respecte intégralement clippy::implicit_return, sans modifier Config ni Logging. pre.004 branche ensuite l’inventory réel .kspwallet sur le répertoire effectif Config : enumeration non récursive, extension exacte, fichiers réguliers uniquement, rejet des symlinks, inspection locked via ksp-wallet-lib, diagnostics sûrs par ligne, DataTable réel, refresh et sélection root-scoped revalidée côté Rust sans Pubkey/alias/notes. pre.004-fix.001 limite les deux réexports crate-root internes utilisés uniquement par les unit tests à #[cfg(test)], afin de fermer les warnings unused_imports observés par cargo check, Clippy, tests et tauri dev sans modifier le comportement d’inventory. pre.005 ajoute la création native create_wallet_file_v1, le formulaire OWNER + VIEW optionnel et le premier WalletSession durable côté Rust : OWNER reste ouvert après création, sélection existante reste Locked, tandis que lock/deselect/refresh/changement de wallet détruisent le handle et purgent les projections protégées. pre.005-fix.001 corrige le premier gate opérateur de cette tranche : WalletOwner est indirecté par Box dans WalletSession::Owner pour fermer clippy::large_enum_variant, et le canari desktop_security retrouve explicitement le début de WalletCreateRequestDto avant de vérifier que les passwords restent request-only. pre.006 ajoute ensuite les unlock explicites VIEW/OWNER : saisie manuelle request-only, découverte des candidats KSP_SECRET_WALLET_PASS_* exclusivement via Config, ordre filename normalisé puis numérique puis nommé, tentative configurée uniquement sur action utilisateur, état transitoire PrivilegedOperation pendant Argon2 et projection frontend limitée au nombre de candidats sans nom/suffixe/valeur. pre.006-fix.001 corrige uniquement les deux canaris statiques de sécurité : ils inspectent désormais les champs réels de WalletAuthorizedDto au lieu de considérer le mot password présent dans sa documentation de configured_secret_candidate_count comme une fuite de champ. pre.007 ferme ensuite le MVP obligatoire : l'adapter Transport accepte un profil déjà sélectionné par composite avec provenance Composite, Wallet Desk construit HttpTransportPool au bootstrap, expose des diagnostics profile/cluster/provider sans URL, extrait la Pubkey uniquement d'une session VIEW/OWNER Rust, puis appelle le wrapper typé getBalance en confirmed et projette lamports exacts, SOL décimal, slot et api_version. Le frontend ne fournit ni Pubkey ni endpoint au refresh et toute balance est purgée lors du lock/deselect/changement de wallet. pre.007-fix.001 corrige le canari d'intégration config_composition qui appelait le constructeur interne test-only ConfigEnvironment::from_maps; le test consomme désormais uniquement l'API publique ConfigEnvironment::load, comme le runtime Wallet Desk, sans modification du pool Transport ni du frontend. pre.007-fix.002 corrige le diagnostic de ce même canari : l'assertion sur ConfigEnvironment::load() ne tente plus de formatter Result<ConfigEnvironment, _> avec Debug, trait volontairement absent de ConfigEnvironment; le contrat runtime reste inchangé. Les tranches suivantes ajoutent administration/import/export, avec une dernière tranche prévue pour README/USAGE/docs/validation, prompt 0.2.7 et build Tauri final. 0.2.6-pre.008 ajoute ensuite l'import Solana CLI JSON/Base58 via un picker natif exclusivement Rust : tauri-plugin-dialog reste backend-only, aucun chemin source ni contenu secret ne traverse IPC, les octets sont lus avec une borne stricte puis conservés dans Zeroizing<Vec<u8>>, l'inspection ne projette que basename/format/Pubkey, et import_wallet_transfer_v1 publie no-clobber sous la racine Config avec de nouveaux credentials OWNER/VIEW avant d'ouvrir la session OWNER. pre.008-fix.001 ferme uniquement les deux warnings Clippy observés au gate opérateur en remplaçant mem::replace(..., Some(...)) par Option::replace et le déréférencement explicite &mut *bytes par l’auto-deref &mut bytes; le staging zéroïsable, l’import et les frontières IPC restent inchangés.
• 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/validation des prix offchain, puis intégrer cette capacité dans ksp-app-wallet-desk sans dupliquer la logique de récupération/normalisation possédée par le composant spécialisé.
• 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.