Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.10-pre.008

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-08 06:43:02 +02:00
parent ab87fd23cd
commit 510adcb49b
21 changed files with 790 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/010-APPS_SERVICES_SCENARIOS_AND_CONTROL.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Applications, services, scenarios et control plane
@@ -49,7 +49,7 @@ Elle ne doit pas réimplémenter :
## Applications de validation par couche
KSP peut ajouter une petite application spécialisée à la fin d'une couche RAW ou CORE lorsque cela permet de valider et exploiter réellement la couche avant de passer à la suivante. Ces applications lisent les contrats KSP et ne recopient pas les processors dans Tauri.
KSP peut ajouter une petite application spécialisée à la fin d'une couche RAW ou STRUCTURAL lorsque cela permet de valider et exploiter réellement la couche avant de passer à la suivante. Ces applications lisent les contrats KSP et ne recopient pas les processors dans Tauri.
À partir des vertical slices Program, les applications restent attachées aux besoins réels : demos de scenarios pour l'exécution et Market Desk pour les projections de marché.
@@ -198,12 +198,12 @@ Exemples conceptuels :
ksp-worker-raw-transaction-ingest-lib # premier runtime worker réutilisable retenu
future autonomous raw-ingest binary # seulement si un besoin de service séparé le justifie
future STRUCTURAL worker
future group-specific DECODE/SPECIALIZED workers when justified
future group-specific DECODED/DOMAIN workers when justified
```
Le premier worker RAW est volontairement prévu comme bibliothèque réutilisable afin qu'une Desk ou un futur host puisse le construire sans dupliquer sa logique. Un binaire autonome n'est pas créé par convention seule ; s'il apparaît, il reste un host mince au-dessus de la même bibliothèque et de `ksp-worker-api`.
RAW reçoit son worker d’ingestion à la fin de sa couche ; CORE reçoit ensuite son STRUCTURAL worker lorsque sa persistence/backlog sont disponibles. Les workers DECODE/SPECIALIZED ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
RAW reçoit son worker d’ingestion à la fin de sa couche ; STRUCTURAL reçoit ensuite son STRUCTURAL worker lorsque sa persistence/backlog sont disponibles. Les workers DECODED/DOMAIN ne sont plus tous anticipés comme une chaîne globale fixe : leur granularité doit émerger des premiers vertical slices Program.
Le binaire, lorsqu'il existe, doit rester mince.
@@ -247,16 +247,16 @@ transport / acquisition
D1 RAW
|
v
D2 CORE
D2 STRUCTURAL
|
v
D3 DECODE
D3 DECODED
|
v
D4 SPECIALIZED
D4 DOMAIN
```
Ce schéma décrit les **frontières de données**, pas quatre workers globaux imposés. RAW et CORE peuvent disposer de workers horizontaux propres à leur couche. À partir de DECODE, la granularité des workers/processors émerge des groupes fonctionnels verticaux réellement introduits ; plusieurs groupes peuvent donc posséder des lifecycle hosts distincts sans qu'un `W3` ou `W4` universel existe.
Ce schéma décrit les **frontières de données**, pas quatre workers globaux imposés. RAW et STRUCTURAL peuvent disposer de workers horizontaux propres à leur couche. À partir de DECODED, la granularité des workers/processors émerge des groupes fonctionnels verticaux réellement introduits ; plusieurs groupes peuvent donc posséder des lifecycle hosts distincts sans qu'un `W3` ou `W4` universel existe.
Les notifications accélèrent le réveil mais ne créent pas une connexion fonctionnelle worker-to-worker.
@@ -286,7 +286,7 @@ Le data plane transporte/persiste les données Solana et les résultats de proce
ksp-onchain-transport-lib
|
v
RAW -> CORE -> DECODE -> SPECIALIZED
RAW -> STRUCTURAL -> DECODED -> DOMAIN
```
avec notifications de données persistées comme wake-up.
@@ -516,11 +516,11 @@ Une app spécialisée peut éditer une configuration puis demander son applicati
Après les groupes Meteora/Raydium/Pump/Orca, KSP prévoit une première application spécialisée candidate `ksp-app-market-desk`.
V1 peut afficher tokens, pools/markets, liquidité, trades/swaps, prix, volumes, OHLC et activité live/récente à partir des projections SPECIALIZED et des contrats KSP. Elle ne dépend pas directement des SDK/protocoles DEX pour reconstruire leurs modèles dans l'UI.
V1 peut afficher tokens, pools/markets, liquidité, trades/swaps, prix, volumes, OHLC et activité live/récente à partir des projections DOMAIN et des contrats KSP. Elle ne dépend pas directement des SDK/protocoles DEX pour reconstruire leurs modèles dans l'UI.
Après Jupiter/OKX, la même application est enrichie avec routes, legs, DEX impliqués, fees/slippage et comparaison quote/execution lorsqu'elle existe.
Les OHLC sont matérialisés dans SPECIALIZED et consommés par l'application; ils ne sont pas recalculés à partir de tout l'historique lors de chaque rendu.
Les OHLC sont matérialisés dans DOMAIN et consommés par l'application; ils ne sont pas recalculés à partir de tout l'historique lors de chaque rendu.
## Future orchestrator
@@ -575,7 +575,7 @@ control/application adapters
Data plane séparé :
```text
transport -> RAW -> CORE -> DECODE -> SPECIALIZED
transport -> RAW -> STRUCTURAL -> DECODED -> DOMAIN
```
Aucun payload de processing n'a besoin de transiter via l'UI/control plane.