163 lines
5.8 KiB
Markdown
163 lines
5.8 KiB
Markdown
<!-- file: docs/IDEAS.md -->
|
|
<!-- version: 7 -->
|
|
|
|
# Idées à explorer
|
|
|
|
Ce document conserve les idées, pistes, questions et alternatives qui méritent d'être étudiées sans constituer encore un engagement de développement ou une décision architecturale.
|
|
|
|
## Statuts
|
|
|
|
- `À explorer`
|
|
- `En exploration`
|
|
- `Retenue`
|
|
- `Rejetée`
|
|
- `Transférée au roadmap`
|
|
- `Transférée vers une décision/règle`
|
|
|
|
## APIs et extensibilité
|
|
|
|
### Nomenclature `*-api`
|
|
|
|
**Status :** Retenue
|
|
|
|
Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
|
|
|
|
Premiers couples retenus : program, materializer et store. Les APIs worker/job sont des lifecycle APIs distinctes.
|
|
|
|
### Execution policy API
|
|
|
|
**Status :** Transférée vers une décision/règle
|
|
|
|
`ksp-execution-policy-api` est retenu comme contrat commun d'autorisation/safety/policy d'une exécution.
|
|
|
|
Le contrat doit permettre des implémentations différentes selon le contexte, par exemple scenario Devnet, application générale ou futur produit trading.
|
|
|
|
L'UI sélectionne/injecte une implémentation réutilisable ; elle ne doit pas devenir propriétaire d'une politique complexe.
|
|
|
|
### Execution orchestration
|
|
|
|
**Status :** Transférée vers une décision/règle
|
|
|
|
`ksp-execution-lib` est retenu comme orchestration spécialisée entre programme, policy, wallet et transport. Il dépend de `ksp-program-api`, pas de l'implémentation `ksp-program-lib`.
|
|
|
|
Les types exacts d'opération préparée et de policy restent à définir en `0.0.3-pre.004`.
|
|
|
|
### Scenarios : norme avant API
|
|
|
|
**Status :** Retenue
|
|
|
|
Ne pas créer `ksp-scenario-api` pour l'instant.
|
|
|
|
Définir d'abord une norme souple de structure, métadonnées, exécution et résultat des crates `ksp-scenario-<domain>-lib`, sans imposer un trait Rust qui limiterait des scénarios hétérogènes.
|
|
|
|
Réévaluer seulement si les premières implémentations révèlent un vrai contrat commun.
|
|
|
|
### Type d'erreur KSP unique
|
|
|
|
**Status :** En exploration
|
|
|
|
La direction retenue est un seul type public `ksp_core_lib::Error` consommable par le workspace sans obliger `ksp-core-lib` à connaître chaque domaine supérieur.
|
|
|
|
### Nommage des items publics
|
|
|
|
**Status :** À explorer
|
|
|
|
Définir avec les premières APIs réelles les conventions de nommage des traits, structs, enums, aliases, constantes et autres items exportés publiquement.
|
|
|
|
### Arborescence et réexports
|
|
|
|
**Status :** À explorer
|
|
|
|
Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades `lib.rs`, modules API et réexports publics.
|
|
|
|
## Transport
|
|
|
|
### Modèles homogènes on-chain
|
|
|
|
**Status :** Retenue
|
|
|
|
`ksp-onchain-transport-lib` ne dépend pas de `ksp-store-api`, mais ses différents providers doivent exposer des modèles homogènes par catégorie de données afin que `ksp-worker-raw-retriever` puisse les convertir simplement vers les modèles raw persistants du store.
|
|
|
|
Aucune `ksp-onchain-transport-api` séparée n'est prévue.
|
|
|
|
### Modèles communs inter-domaines
|
|
|
|
**Status :** À explorer avec l'implémentation
|
|
|
|
Aucun `ksp-data-api` global n'est prévu actuellement. Les modèles appartiennent à leur responsabilité (transport, program, materializer, store) et les composants de composition réalisent les conversions explicites.
|
|
|
|
Réévaluer seulement si les premières implémentations montrent une duplication réellement nuisible impossible à résoudre sans contrat commun supplémentaire.
|
|
|
|
### Off-chain volontairement hétérogène
|
|
|
|
**Status :** Retenue
|
|
|
|
`ksp-offchain-transport-lib` regroupe metadata, prix, quotes, routage et autres accès externes afin d'éviter une explosion de crates. Il n'est pas nécessaire de leur inventer une API métier commune.
|
|
|
|
## Workers et jobs
|
|
|
|
### Workers de processing
|
|
|
|
**Status :** Retenue
|
|
|
|
Après `ksp-worker-raw-retriever`, les responsabilités de processing actuellement prévues sont séparées :
|
|
|
|
- `ksp-worker-core-processor` ;
|
|
- `ksp-worker-generic-materializer` ;
|
|
- `ksp-worker-domain-projector` (nom provisoire).
|
|
|
|
### Worker control
|
|
|
|
**Status :** Retenue comme direction
|
|
|
|
`ksp-worker-control-lib` doit être une implémentation réutilisable de gouvernance consommable par des applications desktop manager, une future application globale et l'orchestrateur.
|
|
|
|
### Job control
|
|
|
|
**Status :** Rejetée pour l'instant
|
|
|
|
Ne pas créer `ksp-job-control-lib` sans duplication concrète entre plusieurs jobs. `ksp-job-api` suffit comme lifecycle API commune tant que chaque job peut être gouverné directement via son implémentation.
|
|
|
|
## Wallet : applications futures
|
|
|
|
### Wallet Android
|
|
|
|
**Status :** À explorer — futur lointain
|
|
|
|
Une application Android native utilisant `ksp-wallet-lib` est envisagée. Nom exact à définir plus tard, candidat : `ksp-app-wallet-android`.
|
|
|
|
### Extensions navigateur
|
|
|
|
**Status :** À explorer — futur lointain
|
|
|
|
Prévoir potentiellement des extensions Firefox et Chrome consommant les capacités KSP appropriées. Noms candidats non normatifs :
|
|
|
|
```text
|
|
ksp-app-wallet-firefox-extension
|
|
ksp-app-wallet-chrome-extension
|
|
```
|
|
|
|
Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage des secrets devront être étudiés avant toute décision.
|
|
|
|
### Wallet web
|
|
|
|
**Status :** À explorer — futur lointain
|
|
|
|
Un wallet web/online utilisant les contrats KSP est envisagé. La gestion des secrets et le modèle de confiance devront être traités comme une question architecturale majeure avant développement.
|
|
|
|
## Pipelines
|
|
|
|
### Pas de pipeline monolithique
|
|
|
|
**Status :** Retenue
|
|
|
|
Ne pas créer de `ksp-pipeline-lib`. Les pipelines sont introduits séparément à la demande avec un périmètre concret.
|
|
|
|
## Trading
|
|
|
|
### Trading Intelligence avant application de trading
|
|
|
|
**Status :** Retenue
|
|
|
|
Construire d'abord statistiques, features, signaux, risque, backtests, détection de patterns/anomalies et intégrations ML telles que XGBoost. La couche/application de trading opérationnelle est construite ensuite.
|