Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
khadhroony-solana-project/deltas/0.2.0/pre.002.md
SinuS Von SifriduS 259bff6707 v0.2.0-pre.002
2026-08-17 13:33:37 +02:00

6.8 KiB
Raw Permalink Blame History

Delta 0.2.0-pre.002

Identité

release : 0.2.0
prerelease : pre.002
identifiant de commit attendu : v0.2.0-pre.002
workspace.package.version : 0.2.0-pre.2
base : 0.2.0-pre.001

Cette livraison est une nouvelle tranche planifiée et non un pre.001-fix.001 : pre.001 avait volontairement laissé le découpage 0.2.1+ ouvert. pre.002 ajoute de nouvelles décisions de planification/architecture issues de l'audit et du brainstorming suivants.

Mission

Consolider le plan de série 0.2.x, fixer la première séquence fonctionnelle, corriger l'ancienne ambiguïté D1/D2 liée au décodage Program, établir la progression RAW -> CORE -> DECODE -> SPECIALIZED, formaliser la discipline de sizing d'une release/session et préparer un prompt de démarrage complet pour 0.2.1.

Aucune capacité Solana runtime N2 n'est implémentée dans cette tranche.

Décisions principales

Dimensionnement

  • une prerelease vise environ 15–20 minutes de travail effectif ;
  • une release concrète doit être entièrement clôturable dans une seule session de chat ;
  • si pre.001 révèle un risque de dépassement, la release est scindée avant implémentation fonctionnelle lourde.

Début de 0.2.x

0.2.1  HTTP Solana foundation
0.2.2  ksp-wallet-lib / .kspwallet
0.2.3  ksp-app-wallet-desk
0.2.4  standard WebSocket
0.2.5  Helius LaserStream WebSocket
0.2.6  Yellowstone gRPC standard foundation
0.2.7  off-chain price transport
0.2.8  price desk
0.2.9  ksp-interface-lib foundation
0.2.10 ksp-program-api foundation

HTTP précède Wallet afin que Wallet Desk puisse être validé avec un solde réseau réel.

Transport

  • ksp-onchain-transport-lib possède ses settings publics et ne dépend pas de Config ;
  • ksp-config-lib peut fournir un document standard Transport et un adapter Config -> Transport ;
  • pools/rôles/priorités/limites HTTP sont retenus ;
  • toute méthode documentée de la surface normative ciblée doit être inventoriée/implémentée sauf impossibilité documentée ;
  • une méthode deprecated/obsolete encore fonctionnelle émet un warning KSP à l'utilisation ;
  • une méthode unstable/experimental émet également un warning KSP ;
  • WebSocket autorise plusieurs sessions sur une même URL mais n'impose pas encore un pool automatique ;
  • Helius WS réutilise le moteur standard ;
  • Yellowstone reste provider-neutral dans sa première version ;
  • providers avancés/shred streams sont reportés dans IDEAS.

Wallet

  • format natif KSP : .kspwallet ;
  • temporary wallet JSON historique abandonné ;
  • WalletPolicy sort de Wallet et relève de la future execution policy ;
  • import/export reste extensible, formats supplémentaires suivis dans IDEAS.

Interface / Program / Policy

  • ksp-interface-lib expose sa propre API publique wire ; pas de ksp-interface-api séparée actuellement ;
  • nomenclature confirmée : ksp-program-api / ksp-program-lib ;
  • ksp-execution-policy-api reste le contrat commun ; petites policies locales dans scenarios/orchestrateurs, libs communes uniquement si réutilisation réelle.

Données

La chaîne durable devient explicitement :

RAW -> CORE -> DECODE -> SPECIALIZED
  • RAW et CORE ne nécessitent aucun decoder Program ;
  • CORE est une normalisation générique Solana ;
  • Program decoding commence à CORE -> DECODE ;
  • à partir de DECODE, progression verticale groupe par groupe.

Groupes Program

Ordre prioritaire :

Solana Core Programs
-> SPL token/trading
-> token metadata
-> Anchor
-> Meteora
-> Raydium
-> Pump
-> Orca
-> Market Desk V1
-> Jupiter/OKX routing
-> Market Desk V2
-> trading-adjacent
-> general decoding

Les programmes satellites nécessaires restent dans leur groupe : Meteora vaults avec Meteora, Pump fee avec Pump, etc.

Market Desk

Une première ksp-app-market-desk est prévue après les DEX prioritaires pour afficher notamment tokens, pools, liquidity, trades, prix et OHLC. Elle est enrichie après routing avec routes/legs/fees/slippage/quote-execution.

Fichiers modifiés

Cargo.toml
ROADMAP.md
docs/000-README.md
docs/IDEAS.md
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/006-WIRE_AND_PROGRAM.md
docs/architecture/007-EXECUTION_AND_POLICY.md
docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md
docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
docs/plans/000-README.md
docs/plans/001-V0_0_3_PLAN.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/rules/PROMPT_STRUCTURE.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_KSP.md
prompts/000-README.md

Fichier ajouté

prompts/006-V0_2_1_START_PROMPT.md

Le prompt 0.2.1 impose notamment :

  • audit bot3 précis ;
  • consultation des sources officielles Solana actuelles ;
  • matrice exhaustive des méthodes HTTP ;
  • classification stable/deprecated/unstable ;
  • warnings runtime appropriés ;
  • ownership Config/Transport ;
  • pools/rôles/limites ;
  • tests/canaries ;
  • gate de sizing avant grosse implémentation ;
  • préparation du futur plan docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md.

Validations réalisées dans l'environnement d'échange

  • parsing TOML du Cargo.toml via Python tomllib ;
  • contrôle de la version Cargo 0.2.0-pre.2 ;
  • contrôle des en-têtes <!-- file: ... --> / <!-- version: ... --> des fichiers modifiés ;
  • contrôle des fences Markdown équilibrées ;
  • contrôle des liens Markdown locaux des fichiers modifiés ;
  • recherche de contradictions actives principales (ksp-program-api-lib, ancienne dépendance Program dans RAW -> CORE, anciennes chaînes de workers/pipelines figées) ;
  • annotation explicite du plan historique 0.0.3 pour distinguer ses anciennes décisions des règles désormais actives ;
  • contrôle de l'archive d'échange et calcul SHA-256.

Validations non exécutables dans cet environnement

Le conteneur d'échange ne fournit ni cargo ni rustc. Les commandes Rust doivent donc être exécutées après application sur le dépôt canonique :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace

Aucune de ces commandes n'est déclarée réussie dans ce delta.

Commit attendu

Après application et validations sur le dépôt canonique :

v0.2.0-pre.002

Conformément aux règles KSP, ce commit de prerelease ne reçoit pas de tag Git stable.

Suite

Le travail restant de 0.2.0 est volontairement court : audit de cohérence final, correction des écarts documentaires restants, finalisation du prompt 0.2.1, puis publication 0.2.0-rel.001 lorsque le cadrage est validé.

Reference in New Issue View Git Blame Copy Permalink