v0.2.0-pre.002
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
|
||||
<!-- version: 26 -->
|
||||
<!-- version: 27 -->
|
||||
|
||||
# Séquence des releases fonctionnelles KSP
|
||||
|
||||
@@ -349,122 +349,207 @@ Par défaut :
|
||||
- prompt de la release suivante ;
|
||||
- vérification de cohérence des versions.
|
||||
|
||||
# Série `0.2.x` — ordre candidat uniquement
|
||||
# Série `0.2.x` — accès Solana, Wallet et contrats initiaux
|
||||
|
||||
`0.2.x` ouvre les capacités Solana N2.
|
||||
|
||||
L'ordre exact des numéros n'est **pas figé** en `0.0.3`.
|
||||
|
||||
Ordre candidat à réévaluer à l'approche de la série :
|
||||
`0.2.0` reste la release de cadrage. `0.2.0-pre.002` fixe maintenant le début de la séquence fonctionnelle suivante :
|
||||
|
||||
```text
|
||||
wallet foundation
|
||||
-> wallet specialized app
|
||||
|
||||
on-chain transport foundation
|
||||
-> specialized transport/demo validation
|
||||
|
||||
interface/wire foundation
|
||||
-> first concrete Program surface
|
||||
|
||||
program-api / program-lib
|
||||
-> first real decoder + ProgramExecutionPreparer + registry validation
|
||||
|
||||
execution-policy-api / execution-lib
|
||||
-> first real execution cycle
|
||||
|
||||
scenario/demo validating the complete path
|
||||
0.2.1 on-chain transport HTTP foundation
|
||||
0.2.2 wallet foundation (.kspwallet)
|
||||
0.2.3 Wallet Desk
|
||||
0.2.4 standard Solana 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 visualization desk
|
||||
0.2.9 interface/wire foundation
|
||||
0.2.10 program-api foundation
|
||||
```
|
||||
|
||||
Wallet, Transport et Interface sont en grande partie indépendants ; leur ordre précis peut donc être réordonné selon le premier cas fonctionnel choisi.
|
||||
Cette séquence est motivée par les dépendances fonctionnelles : un Wallet Desk utile doit pouvoir lire le solde du wallet, donc HTTP précède Wallet ; les transports live arrivent ensuite ; Interface/Program sont préparés avant les couches de données décodées.
|
||||
|
||||
`ksp-offchain-transport-lib` reste need-driven.
|
||||
## `0.2.1` — HTTP Solana foundation
|
||||
|
||||
# Série `0.3.x` — ordre candidat uniquement
|
||||
Mission : créer `ksp-onchain-transport-lib` avec une surface HTTP JSON-RPC complète et indépendante de Config/Store/Program.
|
||||
|
||||
Direction :
|
||||
Inclure :
|
||||
|
||||
- settings publics transport ;
|
||||
- endpoint/provider/cluster ;
|
||||
- pools logiques ;
|
||||
- rôles/capabilities/request kinds ;
|
||||
- priorités/limites/concurrence ;
|
||||
- timeout/retry/backoff ;
|
||||
- JSON-RPC ;
|
||||
- méthodes read et write/execution technique ;
|
||||
- statut centralisé `stable/deprecated/unstable` ;
|
||||
- warning runtime KSP pour deprecated/obsolete encore fonctionnel et unstable/experimental ;
|
||||
- document Config standard Transport + adapter dans `ksp-config-lib`, sans dépendance Transport -> Config.
|
||||
|
||||
La documentation officielle actuelle de la surface ciblée doit être inventoriée exhaustivement dans `pre.001`.
|
||||
|
||||
## `0.2.2` — Wallet foundation
|
||||
|
||||
Mission : créer `ksp-wallet-lib` et le format `.kspwallet`.
|
||||
|
||||
Inclure protection du secret, pubkey/identity, signature, import/export extensible, changement de mot de passe et publication sûre.
|
||||
|
||||
Exclure : temporary wallet JSON historique et `WalletPolicy`.
|
||||
|
||||
## `0.2.3` — Wallet Desk
|
||||
|
||||
Mission : valider Config composite + `.kspwallet` + transport HTTP dans une application Tauri mince.
|
||||
|
||||
Le solde d'un wallet constitue un premier cas de validation réseau obligatoire.
|
||||
|
||||
## `0.2.4` — WebSocket Solana standard
|
||||
|
||||
Mission : couvrir la surface WebSocket standard officielle ciblée.
|
||||
|
||||
Une URL peut avoir plusieurs sessions physiques ; une session peut avoir plusieurs subscriptions. Un pool automatique de sessions est reporté jusqu'à besoin concret.
|
||||
|
||||
## `0.2.5` — Helius LaserStream WebSocket
|
||||
|
||||
Mission : étendre le moteur WebSocket standard avec les opérations/filtres/capabilities Helius ciblés sans copier le client.
|
||||
|
||||
## `0.2.6` — Yellowstone gRPC standard
|
||||
|
||||
Mission : introduire un backend Yellowstone standard/provider-neutral.
|
||||
|
||||
Le `pre.001` est un gate de sizing : inventorier toute la surface normative cible et scinder la release avant implémentation si sa clôture dans une session paraît incertaine.
|
||||
|
||||
Les profiles/adapters Helius/Triton/ERPC/Chainstack/Shyft sont reportés après les priorités fondatrices.
|
||||
|
||||
## `0.2.7` / `0.2.8` — Off-chain price + app
|
||||
|
||||
`0.2.7` introduit `ksp-offchain-transport-lib` avec au minimum SOL/USD et SOL/EUR via une abstraction indépendante du premier provider.
|
||||
|
||||
`0.2.8` ajoute une petite application desk de visualisation/validation.
|
||||
|
||||
Metadata HTTP/IPFS/Arweave viendra au premier besoin Metadata réel.
|
||||
|
||||
## `0.2.9` — Interface foundation
|
||||
|
||||
`ksp-interface-lib` devient la façade wire officielle et expose une API publique wire utilisable par les implementations officielles et externes.
|
||||
|
||||
Aucune `ksp-interface-api` séparée n'est retenue pour l'instant.
|
||||
|
||||
## `0.2.10` — Program API foundation
|
||||
|
||||
Introduire `ksp-program-api`, sans suffixe `-lib`, comme contrat d'extension Program.
|
||||
|
||||
`ksp-program-lib` et les vertical slices réels arrivent plus tard.
|
||||
|
||||
# Architecture durable : RAW -> CORE -> DECODE -> SPECIALIZED
|
||||
|
||||
La chaîne de données est :
|
||||
|
||||
```text
|
||||
store-api + PostgreSQL store foundation
|
||||
|
|
||||
v
|
||||
D1 raw persistence
|
||||
|
|
||||
v
|
||||
specialized Store app
|
||||
|
|
||||
v
|
||||
worker-api / job-api
|
||||
|
|
||||
v
|
||||
raw-ingestion pipeline
|
||||
|
|
||||
+--> raw-retriever service
|
||||
|
|
||||
+--> backfill job
|
||||
D1 RAW
|
||||
-> D2 CORE
|
||||
-> D3 DECODE
|
||||
-> D4 SPECIALIZED
|
||||
```
|
||||
|
||||
Les contrats Materializer et les frontières D2/D3/D4 sont introduits lorsque les sorties Program/Core réelles nécessaires existent.
|
||||
RAW et CORE ne nécessitent aucun decoder Program.
|
||||
|
||||
Store/D1/acquisition peuvent donc être validés avant une matérialisation complète.
|
||||
`RAW -> CORE` est une normalisation générique Solana ; le premier decoder intervient à `CORE -> DECODE`.
|
||||
|
||||
# Séries suivantes
|
||||
# Série `0.3.x` — RAW / acquisition persistée
|
||||
|
||||
Les directions restent celles du roadmap :
|
||||
Début décidé :
|
||||
|
||||
```text
|
||||
0.4.x Core/SPL/metadata + scenarios/demos
|
||||
0.5.x Anchor + protocoles trading
|
||||
0.6.x processing autonome D1 -> D4
|
||||
0.7.x Trading Intelligence
|
||||
0.8.x+ trading opérationnel + explorers + expansion produits
|
||||
0.3.1 ksp-store-api + ksp-store-lib, RAW only
|
||||
0.3.2 ksp-interface-lib, wires génériques acquisition/CORE
|
||||
0.3.3 ksp-job-api + backfill
|
||||
0.3.4 application backfill/RAW
|
||||
```
|
||||
|
||||
Ces séries sont des objectifs fonctionnels, pas un calendrier contractuel.
|
||||
La suite de la série termine la couche RAW avec worker/service live et outils d'exploitation utiles avant l'ouverture de CORE.
|
||||
|
||||
`0.3.1` ne doit pas créer par anticipation les modèles/tables DECODE/SPECIALIZED.
|
||||
|
||||
# Série CORE suivante
|
||||
|
||||
Objectif : rendre CORE exploitable sans aucun decoder Program :
|
||||
|
||||
```text
|
||||
RAW persisted
|
||||
-> Solana generic normalization
|
||||
-> CORE persistence
|
||||
-> RAW->CORE replay/backfill
|
||||
-> CORE worker/service
|
||||
-> CORE inspection/control app
|
||||
```
|
||||
|
||||
# Séries DECODE/SPECIALIZED/EXECUTION suivantes
|
||||
|
||||
À partir du décodage, KSP progresse par vertical slices complets et non par grandes couches de crates isolées :
|
||||
|
||||
```text
|
||||
wire
|
||||
-> decode
|
||||
-> materialize
|
||||
-> specialized projection si utile
|
||||
-> execution preparation
|
||||
-> execution policy
|
||||
-> execute
|
||||
-> Devnet scenario
|
||||
```
|
||||
|
||||
Ordre prioritaire :
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
Un programme satellite nécessaire reste dans son groupe protocolaire : Pump fee avec Pump, Meteora vaults avec Meteora, etc.
|
||||
|
||||
SPM est reporté au décodage généraliste ultérieur.
|
||||
|
||||
# Market Desk
|
||||
|
||||
Après les DEX prioritaires, introduire une petite `ksp-app-market-desk` consommant les projections KSP pour afficher tokens, pools, liquidité, trades, prix, volumes et OHLC.
|
||||
|
||||
Après Jupiter/OKX, enrichir la même app avec routes, legs, DEX impliqués, fees/slippage et quote/execution lorsque disponible.
|
||||
|
||||
L'app ne réimplémente pas les SDK/protocoles DEX ; elle consomme les faits SPECIALIZED normalisés.
|
||||
|
||||
# Discipline de sizing
|
||||
|
||||
Chaque prerelease vise environ 15–20 minutes de travail effectif.
|
||||
|
||||
Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule session de chat. Si `pre.001` montre que ce n'est pas réaliste, scinder la release avant implémentation fonctionnelle lourde.
|
||||
|
||||
# Progression de la série `0.1.x`
|
||||
|
||||
La première release fonctionnelle est :
|
||||
Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
|
||||
|
||||
# Ouverture de `0.2.0`
|
||||
|
||||
`0.2.0` a été ouverte par :
|
||||
|
||||
```text
|
||||
0.1.1 — Core foundation
|
||||
```
|
||||
|
||||
Son prompt historique d'ouverture reste :
|
||||
|
||||
```text
|
||||
prompts/001-V0_1_1_START_PROMPT.md
|
||||
```
|
||||
|
||||
`0.1.1-rel.001` publie la surface Core stable après validation complète de `pre.005`. Le commit de release reçoit le tag `v0.1.1`. La release suivante s'ouvre avec :
|
||||
|
||||
```text
|
||||
0.1.2 — Logging foundation
|
||||
prompts/002-V0_1_2_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Ouverture de `0.2.0`
|
||||
|
||||
Après publication stable de `0.1.4`, la session suivante s’ouvre avec :
|
||||
|
||||
```text
|
||||
0.2.0-pre.001
|
||||
prompts/005-V0_2_0_START_PROMPT.md
|
||||
```
|
||||
|
||||
`0.2.0` est une **release intermédiaire de cadrage de la série `0.2.x`**. Sa mission n'est pas de choisir immédiatement un premier composant N2 à implémenter, mais de reprendre méthodiquement les capacités pertinentes de `khadhroony-bot3` et de définir le plan de migration/refondation de la série.
|
||||
`0.2.0-pre.001` a construit la première cartographie. `0.2.0-pre.002` fixe la trajectoire ci-dessus et prépare :
|
||||
|
||||
La série `0.2.0` doit notamment produire :
|
||||
|
||||
- un inventaire des fonctionnalités `khadhroony-bot3` pertinentes pour `0.2.x` ;
|
||||
- pour chaque capacité, une décision explicite `reprendre / adapter / refondre / abandonner / ajouter` ;
|
||||
- les écarts entre les contrats historiques et les règles KSP déjà stabilisées en `0.1.x` ;
|
||||
- une cartographie des dépendances entre Wallet, transport on-chain, Interface/wire, Program API/Program, policy/execution et les éventuels besoins off-chain ;
|
||||
- les nouvelles fonctionnalités nécessaires qui n'existaient pas dans bot3 ou dont le contrat doit être modifié ;
|
||||
- le découpage concret du reste de `0.2.x` en releases bornées `0.2.1`, `0.2.2`, etc., avec ordre, objectifs, dépendances, hors-périmètre et critères de clôture ;
|
||||
- le prompt de démarrage de la première release fonctionnelle résultant de ce découpage.
|
||||
|
||||
Le document directeur attendu pour cette session est `docs/plans/007-V0_2_0_SERIES_PLANNING.md`. Les numéros et périmètres des releases `0.2.1+` ne deviennent contractuels qu'après validation de ce plan.
|
||||
|
||||
`0.2.0-pre.001` a ouvert ce document avec la méthode d'audit, une première cartographie et une matrice provisoire. Les lots Wallet, Transport, Interface, Program et Execution restent volontairement non numérotés à ce stade ; les audits spécialisés suivants doivent encore challenger leur ordre et leur taille.
|
||||
```text
|
||||
prompts/006-V0_2_1_START_PROMPT.md
|
||||
```
|
||||
|
||||
Le prompt `0.2.1` reste un brouillon vivant jusqu'à la publication stable de `v0.2.0`.
|
||||
|
||||
Reference in New Issue
Block a user