# 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--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--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. ## Program API — questions d'implémentation ### Payload décodé ouvert et persistable **Status :** À explorer lors de la première implémentation `ksp-program-api` ne doit utiliser ni enum central fermé de Program IDs ni `Any` comme seule représentation. À décider à partir des besoins réels : - value tree typé KSP ; - schema/version + payload binaire ; - structure sérialisable ouverte ; - autre contrat garantissant identification, persistence et extensibilité. ### Conflits de registry **Status :** À explorer Définir la politique lorsqu'un registry reçoit plusieurs implémentations capables de traiter le même Program ID/surface/version : - priorité explicite ; - refus du conflit ; - sélection par version/capability ; - autre mécanisme documenté. ### Convention interne `dec` / `exec_prep` **Status :** À explorer avec les premiers modules Le principe `domain/program/capability` est retenu. Les noms exacts des dossiers courts (`dec`, `exec_prep`) seront validés avec la première vraie arborescence.