# Idées à explorer ## APIs et extensibilité ### Nomenclature `*-api` **Status :** Retenue Les crates de contrats publics extensibles utilisent `ksp--api`, sans suffixe `-lib`. Premiers couples retenus : ```text ksp-program-api / ksp-program-lib ksp-materializer-api / ksp-materializer-lib ksp-store-api / ksp-store-lib ``` Éviter un unique `ksp-api-lib` monolithique. ### APIs workers et jobs **Status :** Retenue Les workers et jobs ont des modèles de lifecycle différents et ne doivent pas partager une API universelle commune. Prévoir séparément : ```text ksp-worker-api ksp-job-api ``` `ksp-worker-control-lib` reste un candidat d'implémentation de contrôle des workers uniquement. Le besoin éventuel d'une implémentation commune de contrôle des jobs sera évalué séparément. ### 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 des modules/fichiers, façades `lib.rs`, modules API et réexports publics. ## Données et notifications ### Notifications normalisées de données **Status :** Retenue Une notification de donnée doit avoir la même représentation canonique pour le même type de donnée quelle que soit son origine. `ksp-store-api` est le propriétaire candidat de ces contrats lorsque la notification signifie qu'une donnée persistée est disponible. Le transport concret de notification reste indépendant du contrat. ### Backend PostgreSQL **Status :** Retenue `ksp-store-lib` contient PostgreSQL comme implémentation de référence de `ksp-store-api`. ## Workers et jobs ### W1 **Status :** Retenue W1 reste strictement un worker raw live/quasi-live avec reconfiguration à chaud, persistance raw et notification. Aucun replay/backfill. ### Backfill historique **Status :** Retenue Le backfill historique est un job distinct, candidat `ksp-job-backfill`. ### Autres jobs **Status :** Retenue Des jobs séparés pourront apparaître pour metadata, quotes ou autres traitements ponctuels lorsqu'un besoin réel existe. ### Orchestrateur **Status :** Retenue Commencer par des managers séparés. Introduire un orchestrateur global lorsque plusieurs workers/managers le justifient. Les jobs restent gouvernés par leurs contrats propres. ## 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 borné. ## Scénarios ### Crates spécialisées **Status :** Retenue Ne pas créer de `ksp-scenarios-lib` monolithique. Utiliser des crates spécialisées `ksp-scenario--lib`. Memo, Token classique, ATA et Token-2022 restent séparés. Metaplex Token Metadata et Token-2022 Metadata peuvent partager une famille metadata ; Solana Program Metadata reste séparé. ## 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.