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

v0.0.3-pre.002

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 07:23:56 +02:00
parent 5a86808376
commit bb69cbd557
11 changed files with 843 additions and 603 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/architecture/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/000-README.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Architecture KSP
@@ -19,6 +19,7 @@ Ils ne remplacent ni `ROADMAP.md`, ni les plans de version, ni les deltas.
1. [`001-PROJECT_OBJECTIVES.md`](001-PROJECT_OBJECTIVES.md) — finalité, objectifs produits et non-objectifs architecturaux ;
2. [`002-LAYERS_AND_DEPENDENCIES.md`](002-LAYERS_AND_DEPENDENCIES.md) — couches conceptuelles, sens des dépendances et responsabilités des exécutables ;
3. [`003-COMPONENT_CONTRACTS.md`](003-COMPONENT_CONTRACTS.md) — frontières initiales des composants structurants, contrats à définir tôt et responsabilités déjà acquises.
3. [`003-COMPONENT_CONTRACTS.md`](003-COMPONENT_CONTRACTS.md) — frontières initiales des composants structurants et contrats déjà acquis ;
4. [`004-COMPONENT_INVENTORY.md`](004-COMPONENT_INVENTORY.md) — premier inventaire des domaines, APIs, bibliothèques, workers, jobs, scénarios et applications candidates.
Les futurs documents prioritaires peuvent continuer avec `004-`, `005-`, etc. lorsqu'un ordre de lecture explicite apporte une valeur réelle.
L'inventaire `004` est volontairement révisable pendant `0.0.3-pre.003` lorsque le graphe de dépendances révélera des frontières à corriger.

205
docs/architecture/003-COMPONENT_CONTRACTS.md
View File

@@ -1,127 +1,144 @@
<!-- file: docs/architecture/003-COMPONENT_CONTRACTS.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Contrats initiaux des composants KSP
## Objet
Ce document enregistre les frontières déjà suffisamment claires pour guider la planification. Il ne définit pas encore les API Rust finales.
Le principe commun est de définir tôt les contrats nécessaires entre composants, puis d'enrichir les implémentations lorsque le besoin réel apparaît.
L'inventaire détaillé courant est maintenu dans [`004-COMPONENT_INVENTORY.md`](004-COMPONENT_INVENTORY.md).
## Convention API / implémentation
Lorsqu'un domaine doit exposer des contrats publics pouvant être implémentés indépendamment, KSP sépare :
Lorsqu'un domaine doit exposer des contrats publics pouvant être implémentés indépendamment, KSP peut séparer :
```text
ksp-<domain>-api
ksp-<domain>-lib
```
La crate `ksp-<domain>-api` est techniquement une bibliothèque Rust mais ne porte volontairement pas le suffixe `-lib`. Elle expose principalement des traits, types, enums et contrats publics ; elle peut être consommée par plusieurs implémentations et n'est pas, à elle seule, une implémentation fonctionnelle destinée aux exécutables.
La crate `ksp-<domain>-api` est techniquement une bibliothèque Rust mais ne porte volontairement pas le suffixe `-lib`.
La crate `ksp-<domain>-lib` contient l'implémentation officielle KSP correspondante lorsqu'une telle implémentation existe.
Cette séparation n'est pas automatique. Elle est utilisée lorsqu'une vraie frontière d'extension/backend/lifecycle la justifie.
Cette séparation n'est pas automatique pour tous les domaines. Elle est utilisée lorsqu'une vraie frontière d'extension ou de backend justifie une API indépendante.
Couples retenus :
Premiers couples retenus :
```text
ksp-program-api / ksp-program-lib
ksp-materializer-api / ksp-materializer-lib
ksp-store-api / ksp-store-lib
```
- `ksp-program-api` + `ksp-program-lib` ;
- `ksp-materializer-api` + `ksp-materializer-lib` ;
- `ksp-store-api` + `ksp-store-lib`.
Un unique `ksp-api-lib` monolithique est rejeté.
## `ksp-program-api` / `ksp-program-lib`
`ksp-program-api` possède les contrats publics communs de décodage/exécution. Une crate séparée doit pouvoir implémenter et tester ces contrats sans dépendre de `ksp-program-lib`.
`ksp-program-lib` contient les implémentations officielles intégrées des Program IDs supportés.
Le decoder vise toute surface techniquement décodable dont la définition est connue. Le statut `deprecated` concerne l'exécution, pas le décodage. Lorsqu'une définition wire a été réellement écrasée/remplacée sous la même identité et que l'ancienne définition n'est plus distinguable de manière fiable, le decoder utilise la définition la plus récente applicable.
L'executor expose les opérations techniquement exécutables connues ; une opération obsolète mais encore identifiable/exécutable peut rester implémentée et être marquée `deprecated`. La politique de sécurité appartient à une couche supérieure.
## `ksp-materializer-api` / `ksp-materializer-lib`
`ksp-materializer-api` possède les contrats publics/extensibles de matérialisation. Une crate externe doit pouvoir implémenter un materializer contre cette API sans dépendre de `ksp-materializer-lib`.
`ksp-materializer-lib` contient les materializers officiels intégrés KSP.
## `ksp-store-api` / `ksp-store-lib`
`ksp-store-api` possède les contrats backend-agnostic de persistance et d'accès aux données KSP.
`ksp-store-lib` contient PostgreSQL comme implémentation officielle de référence : configuration/connexion, migrations, repositories, queries et mécanismes backend nécessaires.
Les applications, workers, jobs et materializers consomment les contrats KSP et ne contournent pas le store pour accéder directement au backend.
## Notifications de données
Une notification de donnée décrit la donnée disponible, pas son producteur.
Le même type de donnée doit utiliser le même contrat de notification qu'elle provienne :
- de W1 ;
- d'un job de backfill ;
- d'un import ;
- d'une autre source future.
`ksp-store-api` est le propriétaire candidat des références/événements canoniques indiquant qu'une donnée persistée est disponible, par exemple conceptuellement `RawDataRef` / `RawDataAvailable`.
Le contrat de notification reste distinct du mécanisme de transport concret : channel in-process, PostgreSQL LISTEN/NOTIFY, IPC, broker ou autre mécanisme futur.
## Workers
Les workers sont des services continus/live. Leurs contrats communs appartiennent à :
APIs lifecycle retenues :
```text
ksp-worker-api
```
Cette API ne contient aucun contrat de job.
Une future implémentation commune de gouvernance/contrôle des workers peut vivre dans :
```text
ksp-worker-control-lib
```
W1 reste un worker d'acquisition raw live/quasi-live : configuration, transport, persistance raw, reconfiguration à chaud et notification de disponibilité. Il ne décode pas, ne matérialise pas et ne réalise aucun replay/backfill historique.
## Jobs
Les jobs sont des travaux déclenchés à la demande, suivables et terminables. Leurs contrats communs appartiennent à :
```text
ksp-job-api
```
Cette API ne contient aucun contrat de worker.
Aucune API commune worker+job n'est prévue.
Les implémentations concrètes utilisent le préfixe `ksp-job-`.
## Execution policy
Premier candidat retenu :
`ksp-program-lib` ne possède pas la politique de sécurité/autorisation d'un produit.
La direction retenue pour étude est un contrat public séparé :
```text
ksp-job-backfill
ksp-execution-policy-api
```
D'autres jobs pourront être introduits pour metadata, quotes ou autres travaux ponctuels lorsqu'un besoin réel existe.
Il doit permettre à différents contextes de fournir leurs propres décisions de policy sans modifier `ksp-program-lib` : scenario Devnet, application générale, futur produit trading, etc.
Le contrôle/gouvernance commun des jobs reste séparé du contrôle des workers, même si certaines opérations semblent similaires.
Les applications UI sélectionnent/injectent une implémentation réutilisable appropriée ; elles ne doivent pas enfouir une politique complexe directement dans la couche d'interface.
## Execution orchestration
`ksp-execution-lib` devient un candidat fort de pipeline/orchestrateur spécialisé pour relier :
- la préparation/sémantique programme ;
- une implémentation de `ksp-execution-policy-api` ;
- `ksp-wallet-lib` ;
- `ksp-onchain-transport-lib`.
Le but est d'éviter que `ksp-program-lib` dépende directement du wallet/transport uniquement pour réaliser le cycle réseau/signature.
Le graphe exact reste à valider dans `pre.003`.
## Transport on-chain
Aucune `ksp-onchain-transport-api` séparée n'est prévue.
`ksp-onchain-transport-lib` regroupe les transports/providers on-chain et expose des modèles de sortie homogènes par catégorie de données.
Il ne dépend pas de `ksp-store-api`.
Les modèles de transport doivent cependant être conçus pour une conversion explicite et simple vers les modèles raw persistants du store, sans décodage protocolaire.
## Transport off-chain
Aucune `ksp-offchain-transport-api` commune n'est prévue.
La crate est volontairement hétérogène : metadata, prix, quotes, routage et autres ressources externes peuvent avoir des modules/APIs distincts à l'intérieur d'une seule crate afin d'éviter une prolifération de crates artificielles.
## Wallet
Aucune `ksp-wallet-api` n'est prévue.
`ksp-wallet-lib` possède le format wallet KSP et les capacités de lecture/protection/import/export/pubkey/secret/signature nécessaires à ses consommateurs.
## Store et notifications de données
`ksp-store-api` reste la frontière backend-agnostic. `ksp-store-lib` contient PostgreSQL comme implémentation de référence.
Les notifications de données persistées sont normalisées indépendamment de leur producteur. W1, un job de backfill ou un import utilisent le même contrat pour signaler le même type de donnée.
Le contrat de notification est distinct de son transport concret.
## Workers
`ksp-worker-api` est une lifecycle API pour services continus/live.
`ksp-worker-control-lib` est une implémentation réutilisable de gouvernance pouvant être consommée par les applications manager desktop, une future application globale ou un orchestrateur.
Workers actuellement retenus :
```text
ksp-worker-raw-retriever
ksp-worker-core-processor
ksp-worker-generic-materializer
ksp-worker-domain-projector
```
Le dernier nom reste provisoire.
## Jobs
`ksp-job-api` est une lifecycle API distincte pour travaux déclenchés et terminables.
`ksp-job-backfill` est retenu pour le backfill historique.
Aucune `ksp-job-control-lib` n'est prévue actuellement. D'autres jobs pourront apparaître pour metadata, quotes ou autres besoins ponctuels.
## Scénarios
Les scénarios restent dans des crates spécialisées `ksp-scenario-<domain>-lib`.
`ksp-scenario-api` n'est pas retenu actuellement : une norme de structure/comportement commune est préférée à un trait Rust obligatoire tant qu'un vrai contrat commun n'a pas émergé.
Les demos desktop de scénario suivent provisoirement la forme :
```text
ksp-app-scenario-<domain>-<environment>-desk-demo
```
et réutilisent la crate de scénario correspondante.
## Pipelines
KSP ne prévoit pas de `ksp-pipeline-lib` monolithique. Lorsqu'un pipeline réutilisable devient nécessaire, il est introduit séparément avec un périmètre concret et borné.
Aucun `ksp-pipeline-lib` monolithique.
## Demos et scénarios
Il n'existe pas de crate monolithique `ksp-scenarios-lib`.
Les scénarios sont organisés en crates spécialisées par domaine cohérent, par exemple :
```text
ksp-scenario-memo-lib
ksp-scenario-token-lib
ksp-scenario-ata-lib
ksp-scenario-token-2022-lib
ksp-scenario-metadata-lib
ksp-scenario-spm-lib
```
Les metadata d'assets/tokens peuvent regrouper Metaplex Token Metadata et Token-2022 Metadata. Solana Program Metadata reste séparé.
Des pipelines spécialisés peuvent être ajoutés à la demande. `ksp-execution-lib` est justement étudié comme un pipeline/orchestrateur spécialisé, pas comme une infrastructure universelle.

271
docs/architecture/004-COMPONENT_INVENTORY.md Normal file
View File

@@ -0,0 +1,271 @@
<!-- file: docs/architecture/004-COMPONENT_INVENTORY.md -->
<!-- version: 1 -->
# Inventaire initial des composants KSP
## Objet
Ce document constitue le premier inventaire architectural de `0.0.3-pre.002`.
Il répond principalement à la question : **quel composant possède quelle responsabilité ?**
Il ne fige pas encore le graphe exact des dépendances. `0.0.3-pre.003` doit explicitement pouvoir corriger cet inventaire lorsque l'étude des dépendances montre qu'une API, une bibliothèque ou une frontière doit être déplacée, séparée ou supprimée.
## Statuts
- **Retenu** — composant ou responsabilité considérée nécessaire dans la trajectoire actuelle ;
- **Candidat fort** — composant très probable mais dont la frontière exacte doit encore être validée ;
- **Futur retenu** — responsabilité acquise mais implémentation différée ;
- **À la demande** — ne doit être créé que lorsqu'un premier besoin concret le justifie ;
- **Non retenu actuellement** — idée volontairement non créée ; elle peut être réévaluée si l'usage réel change.
## Inventaire synthétique
| Domaine | Composant | Nature | Niveau provisoire | Statut | Première série envisagée | Responsabilité principale |
|-------------------------|---------------------------------------------|---------------|-------------------|-----------------------------------|----------------------------|-------------------------------------------------------------------------------------------|
| Core | `ksp-core-lib` | lib | N1 | Retenu | `0.1.x` | `Error` commun, Program IDs, primitives/contrats réellement transversaux |
| Configuration | `ksp-config-lib` | lib | N1 | Retenu | `0.1.x` | documents de configuration, profils, résolution, modifications autorisées |
| Logging | `ksp-logging-lib` | lib | N1 | Retenu | `0.1.x` | logging/tracing commun |
| Wire Solana | `ksp-interface-lib` | lib | N1 | Retenu | `0.2.x` | façade wire on-chain, réexports contrôlés et réimplémentations compatibles |
| Program API | `ksp-program-api` | API | N2 contrat | Retenu | `0.2.x` | contrats publics decoder/executor et types associés |
| Program impl. | `ksp-program-lib` | lib | N2 | Retenu | `0.2.x+` | decoders/executors officiels intégrés |
| Execution policy | `ksp-execution-policy-api` | API | N3 contrat | Candidat fort | `0.2.x–0.4.x` | contrat public permettant à chaque contexte d'autoriser/refuser/contraindre une exécution |
| Execution orchestration | `ksp-execution-lib` | lib | N3 | Candidat fort | `0.2.x–0.4.x` | orchestration spécialisée entre opération préparée, policy, wallet et transport |
| Transport on-chain | `ksp-onchain-transport-lib` | lib | N2 | Retenu | `0.2.x` | RPC/WS/providers et modèles de transport homogènes, sans dépendance store |
| Transport off-chain | `ksp-offchain-transport-lib` | lib | N2 | Retenu, implémentation différable | premier besoin réel | accès metadata, prix, quotes, routage et autres ressources hors blockchain |
| Wallet | `ksp-wallet-lib` | lib | N2 | Retenu | `0.2.x` | format wallet KSP, lecture/protection/import/export, pubkey, secret/signature |
| Materializer API | `ksp-materializer-api` | API | N3 contrat | Retenu | `0.3.x` | contrats publics/extensibles de matérialisation |
| Materializer impl. | `ksp-materializer-lib` | lib | N3 | Retenu | `0.3.x+` | materializers officiels KSP |
| Store API | `ksp-store-api` | API | N3 contrat | Retenu | `0.3.x` | contrats backend-agnostic, modèles persistants et notifications de données persistées |
| Store impl. | `ksp-store-lib` | lib | N3 | Retenu | `0.3.x` | PostgreSQL de référence, migrations, repositories, queries |
| Worker lifecycle | `ksp-worker-api` | API | N3 contrat | Retenu | `0.3.x` | lifecycle commun des services continus |
| Worker control | `ksp-worker-control-lib` | lib | N3 | Candidat fort | `0.3.x+` | gouvernance réutilisable des workers pour managers/apps/orchestrateur |
| Live raw acquisition | `ksp-worker-raw-retriever` | worker | N4 | Retenu | `0.3.x` | acquisition live/quasi-live -> raw persisté -> notification data |
| Raw -> Core | `ksp-worker-core-processor` | worker | N4 | Futur retenu | `0.6.x` | transformer le raw persisté en Core canonique |
| Core -> generic mat. | `ksp-worker-generic-materializer` | worker | N4 | Futur retenu | `0.6.x` | produire la matérialisation/journal générique depuis le Core |
| Domain projection | `ksp-worker-domain-projector` | worker | N4 | Futur retenu, nom provisoire | `0.6.x` | matérialiser/classer/stocker les projections spécialisées par domaine |
| Job lifecycle | `ksp-job-api` | API | N3 contrat | Retenu | `0.3.x` | lifecycle/progression commun des travaux déclenchés et terminables |
| Historical backfill | `ksp-job-backfill` | job | N4 | Retenu | `0.3.x` | acquisition historique avec pagination, progression, checkpoint/reprise |
| Other jobs | `ksp-job-<role>` | job | N4 | À la demande | `0.4.x+` | metadata, quotes et autres travaux ponctuels/historiques |
| Scenarios | `ksp-scenario-<domain>-lib` | lib | N3 | Retenu | `0.4.x+` | scénarios de validation spécialisés par domaine |
| Scenario common API | `ksp-scenario-api` | API | — | Non retenu actuellement | — | préférer une norme de scénario souple plutôt qu'un trait commun contraignant |
| Scenario demo apps | `ksp-app-scenario-<domain>-<env>-desk-demo` | app | N4 | Retenu | `0.4.x+` | interface desktop appelant la crate scénario correspondante |
| Specialized pipelines | `ksp-pipeline-<role>-lib` ou autre forme | variable | N3/N4 | À la demande | selon besoin | pipeline concret et borné ; aucune crate pipeline globale |
| Trading Intelligence | noms à définir | API/libs/jobs | N3+ | Futur retenu | `0.7.x` | statistiques, features, signaux, anomalies, backtests, ML |
| Trading operation/app | noms à définir | libs/apps | N3/N4 | Futur retenu | après Trading Intelligence | politique/automatisation de trading et application monoposte |
| Solana explorer | noms à définir | libs/apps | N3/N4 | Futur retenu | futur | exploration générale Solana |
| DEX explorer | noms à définir | libs/apps | N3/N4 | Futur retenu | futur | exploration/analyse DEX |
## APIs séparées retenues
Les couples suivants ont une justification d'extensibilité suffisante :
```text
ksp-program-api -> ksp-program-lib
ksp-materializer-api -> ksp-materializer-lib
ksp-store-api -> ksp-store-lib
```
Les APIs lifecycle sont également séparées :
```text
ksp-worker-api -> workers continus
ksp-job-api -> jobs terminables
```
Aucune API commune worker+job n'est prévue.
## Execution policy et orchestration
### Direction retenue pour étude en `pre.003`
La direction privilégiée est une orchestration supérieure plutôt qu'une dépendance directe de `ksp-program-lib` vers le wallet et le transport :
```text
policy implementation
^
|
ksp-execution-policy-api
^
|
ksp-execution-lib
/ | \
/ | \
program side wallet onchain transport
```
`ksp-program-lib` doit rester propriétaire de la sémantique technique des programmes et de la préparation des opérations, sans posséder la politique de sécurité d'un produit ni le cycle réseau complet.
`ksp-execution-policy-api` permettrait plusieurs politiques incompatibles mais conformes au même contrat, par exemple :
- politique permissive et bornée d'un scénario Devnet ;
- politique plus stricte d'une future application générale ;
- politique spécialisée d'un futur produit de trading.
Une application UI ne doit pas enfouir cette logique dans ses commandes ou composants. Elle sélectionne/injecte une implémentation réutilisable située dans la crate de scénario ou de domaine appropriée.
Aucune `ksp-execution-policy-lib` générique n'est retenue actuellement. Des implémentations réutilisables pourront être créées plus tard si plusieurs consommateurs partagent réellement la même politique.
Le graphe exact `ksp-execution-lib -> ksp-program-api` ou `ksp-program-lib`, ainsi que la forme des plans/opérations préparées, est explicitement reporté à `pre.003/pre.004`.
## Transport on-chain
Aucune crate `ksp-onchain-transport-api` n'est prévue.
`ksp-onchain-transport-lib` peut contenir plusieurs familles hétérogènes :
- HTTP RPC ;
- WebSocket RPC ;
- Helius avancé ;
- Yellowstone ;
- autres providers/transports futurs.
Les adapters providers doivent toutefois faire sortir de la crate des **modèles de transport homogènes par catégorie de donnée**, afin que les consommateurs n'aient pas à comprendre chaque réponse propriétaire.
Ces modèles :
- restent indépendants de `ksp-store-api` ;
- conservent les informations raw/provenance nécessaires ;
- ne réalisent aucun décodage métier/protocolaire ;
- doivent être facilement et explicitement convertibles par `ksp-worker-raw-retriever` vers les modèles raw persistants de `ksp-store-api`.
Le détail de cette frontière de conversion est reporté à `pre.003/pre.005`.
## Transport off-chain
Aucune crate `ksp-offchain-transport-api` ni trait global `OffchainTransport` n'est prévu.
`ksp-offchain-transport-lib` regroupe volontairement des accès hétérogènes afin d'éviter une explosion de petites crates. Metadata externes, quotes, prix hors blockchain ou routage peuvent conserver des APIs/modules spécialisés à l'intérieur de cette crate sans prétendre partager une abstraction métier commune.
## Wallet
Aucune crate `ksp-wallet-api` n'est prévue.
`ksp-wallet-lib` est propriétaire du format wallet KSP, des opérations de protection/import/export et de l'accès contrôlé aux capacités pubkey/secret/signature nécessaires aux couches supérieures.
Les applications futures utilisant ce wallet restent des consommateurs de `ksp-wallet-lib`, pas des implémentations alternatives du contrat wallet.
## Workers
### `ksp-worker-api`
`ksp-worker-api` est une **lifecycle API de services continus**.
Elle pourra porter des contrats communs comme identité, état, health, start/stop/shutdown et événements de lifecycle. Une capacité optionnelle comme la reconfiguration à chaud ne doit devenir universelle que si plusieurs workers la partagent réellement.
Elle ne contient aucun concept de progression/checkpoint terminal propre aux jobs.
### `ksp-worker-control-lib`
`ksp-worker-control-lib` est une implémentation réutilisable de gouvernance au-dessus de `ksp-worker-api`.
Elle doit pouvoir être consommée par :
- une application desktop manager spécialisée ;
- une future application globale ;
- un futur orchestrateur ;
- des tools/tests lorsque pertinent.
Les applications restent des interfaces et ne réimplémentent pas elles-mêmes registre, dispatch start/stop, agrégation d'état ou reconfiguration générique.
### Workers de processing
Le modèle initial d'un unique W2 est remplacé par une chaîne de responsabilités plus étroites :
```text
raw persisted
|
v
ksp-worker-core-processor
|
v
canonical Core
|
v
ksp-worker-generic-materializer
|
v
generic materialization/journal
|
v
ksp-worker-domain-projector
|
v
domain projections
```
Le nom `ksp-worker-domain-projector` est explicitement provisoire jusqu'à ce que les contrats de matérialisation spécialisée soient définis.
## Jobs
`ksp-job-api` est une **lifecycle API de travaux déclenchés et terminables**.
Elle peut porter identité, état, progression, cancel, résultat et, lorsque pertinent, pause/resume/checkpoint.
Aucune `ksp-job-control-lib` n'est prévue actuellement. Le fait que plusieurs jobs implémentent `ksp-job-api` suffit tant qu'aucune duplication concrète de gouvernance ne justifie une bibliothèque commune.
## Notifications de données
Les notifications de données restent indépendantes du lifecycle des workers et des jobs.
Le même type de donnée persistée doit produire le même contrat de notification quelle que soit son origine :
```text
worker live -----\
job backfill -----+--> même notification de donnée
import -----------/
```
`ksp-store-api` reste le propriétaire candidat de ces références/notifications lorsqu'elles signifient qu'une donnée persistée est disponible.
Le transport de notification reste distinct du contrat de donnée.
## Scénarios et demos
Aucune crate monolithique de scénarios n'est prévue.
Les scénarios vivent dans des crates spécialisées :
```text
ksp-scenario-memo-lib
ksp-scenario-token-lib
ksp-scenario-ata-lib
ksp-scenario-token-2022-lib
ksp-scenario-metadata-lib
ksp-scenario-spm-lib
...
```
`ksp-scenario-api` n'est pas retenu actuellement. Une **norme de structure/comportement** commune est préférée à un trait Rust susceptible de limiter des scénarios dont les besoins sont différents. Cette décision pourra être revue si les premières implémentations montrent un vrai contrat commun utile.
Les applications de démonstration correspondantes suivent la forme :
```text
ksp-app-scenario-<domain>-<environment>-desk-demo
```
Exemples :
```text
ksp-app-scenario-memo-devnet-desk-demo
ksp-app-scenario-token-2022-devnet-desk-demo
ksp-app-scenario-metadata-devnet-desk-demo
```
Chaque application appelle la crate `ksp-scenario-<domain>-lib` correspondante et ne duplique pas son scénario.
## Pipelines
`ksp-pipeline-lib` reste rejeté.
Des pipelines spécialisés peuvent être créés à la demande lorsqu'un flux concret possède assez de logique réutilisable pour justifier sa propre frontière. Leur forme n'est pas nécessairement une bibliothèque : certains pourront être workers, jobs ou composants spécialisés.
## Questions explicitement reportées à `pre.003`
- dépendance exacte de `ksp-execution-lib` vers `ksp-program-api` et/ou `ksp-program-lib` ;
- forme du contrat entre program preparation, execution policy, wallet et transport ;
- emplacement exact des modèles communs nécessaires à l'exécution ;
- types publics de transport on-chain et conversion vers les DTO raw de `ksp-store-api` ;
- dépendances autorisées de `ksp-materializer-api` et `ksp-store-api` ;
- risque de cycles entre program, materializer, store, execution et control ;
- position exacte des notifications de données dans le graphe.