# 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 :** En exploration — candidat fort Étudier `ksp-execution-policy-api` 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 :** En exploration — candidat fort Étudier `ksp-execution-lib` comme orchestration spécialisée entre programme, policy, wallet et transport, plutôt qu'une dépendance directe de `ksp-program-lib` vers wallet/transport. Le graphe exact est reporté à `0.0.3-pre.003`. ### 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. ### 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.