v0.2.0-pre.002
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/000-README.md -->
|
||||
<!-- version: 25 -->
|
||||
<!-- version: 26 -->
|
||||
|
||||
# Plans KSP
|
||||
|
||||
@@ -15,7 +15,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
|
||||
- [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
|
||||
- [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`.
|
||||
- [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan historique clôturé de la release stable `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` puis consolidé jusqu'à `0.1.4-rel.001`.
|
||||
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `0.2.0-pre.001` pour auditer `khadhroony-bot3` et découper le reste de `0.2.x` sans implémentation N2 prématurée.
|
||||
- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `pre.001` puis consolidé par `pre.002` avec l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program et le prompt préparatoire `0.2.1`.
|
||||
|
||||
Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
|
||||
|
||||
|
||||
@@ -1,8 +1,11 @@
|
||||
<!-- file: docs/plans/001-V0_0_3_PLAN.md -->
|
||||
<!-- version: 15 -->
|
||||
<!-- version: 16 -->
|
||||
|
||||
# Plan KSP 0.0.3
|
||||
|
||||
> **Note de supersession — `0.2.0-pre.002`**
|
||||
> Ce document conserve le cadrage historique établi pendant `0.0.3`. Les mentions ci-dessous de quatre pipelines fixes, de `ksp-worker-generic-materializer`, de `ksp-worker-domain-projector` ou d'un Core processing dépendant du décodage Program décrivent l'état de décision de cette ancienne release et **ne constituent plus l'architecture courante**. Depuis `0.2.0-pre.002`, les documents normatifs/actifs sont `docs/architecture/008-DATA_MATERIALIZATION_AND_STORE.md`, `docs/architecture/009-ACQUISITION_WORKERS_AND_JOBS.md`, `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`, `docs/plans/007-V0_2_0_SERIES_PLANNING.md` et les règles associées. Le modèle courant est `RAW -> CORE -> DECODE -> SPECIALIZED`, RAW/CORE ne dépendent pas d'un decoder Program, et les capacités de DECODE/SPECIALIZED sont introduites verticalement groupe par groupe.
|
||||
|
||||
## Mission
|
||||
|
||||
Transformer le brainstorming KSP en architecture, règles, inventaire et plan suffisamment précis pour ouvrir la première série fonctionnelle `0.1.x` sans développement fonctionnel prématuré.
|
||||
@@ -15,7 +18,7 @@ Transformer le brainstorming KSP en architecture, règles, inventaire et plan su
|
||||
|
||||
Les tranches `pre.004` (Wire/Program), `pre.005` (Execution/Policy), `pre.006` (Data/Materialization/Store), `pre.007` (Acquisition/Workers/Jobs), `pre.008` (Apps/Services/Scenarios/Control) et `pre.009` (Functional Release Sequence) sont maintenant livrées séparément afin de conserver des prereleases de planification bornées.
|
||||
|
||||
## Décisions structurantes actuelles
|
||||
## Décisions structurantes à la clôture de `0.0.3` — historique
|
||||
|
||||
- `0.1.x`, `0.2.x`, etc. sont des séries fonctionnelles, pas des unités de session.
|
||||
- Chaque release concrète d'une série est dimensionnée séparément.
|
||||
|
||||
@@ -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`.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user