v0.0.3-pre.001

docs/IDEAS.md

@@ -1,41 +1,127 @@
 <!-- file: docs/IDEAS.md -->
-<!-- version: 1 -->
+<!-- version: 5 -->
 
 # 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.
+## APIs et extensibilité
 
-Une idée peut évoluer vers un plan, une règle, une décision architecturale ou une entrée du `ROADMAP.md`. Lorsqu'elle est transférée, le document conserve une trace concise de son issue afin de ne pas perdre l'historique de la réflexion.
+### Nomenclature `*-api`
 
-## Statuts
+**Status :** Retenue
 
-Les statuts recommandés sont :
+Les crates de contrats publics extensibles utilisent `ksp-<domain>-api`, sans suffixe `-lib`.
 
-- `À explorer` ;
-- `En exploration` ;
-- `Retenue` ;
-- `Rejetée` ;
-- `Transférée au roadmap` ;
-- `Transférée vers une décision/règle`.
+Premiers couples retenus :
 
-## Architecture des interfaces Solana
+```text
+ksp-program-api        / ksp-program-lib
+ksp-materializer-api   / ksp-materializer-lib
+ksp-store-api          / ksp-store-lib
+```
 
-### Nom et périmètre de la crate commune d'interfaces/wire
+É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éterminer le nom définitif et le périmètre exact de la crate commune actuellement envisagée sous un nom tel que `ksp-interface-lib`. Elle doit permettre de centraliser les contrats wire/on-chain partagés sans absorber les responsabilités de transport, matérialisation ou stockage.
+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.
 
-### Regroupement decoder / construction / executor
+### Arborescence et réexports
 
 **Status :** À explorer
 
-Déterminer si le décodage et la construction d'instructions doivent rester dans une même crate ou être séparés, et distinguer cette question de l'exécution réseau proprement dite : signature, simulation, soumission et confirmation.
+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.
 
-## Applications et environnements
+## Données et notifications
 
-### Nomenclature complète des environnements de démonstration
+### Notifications normalisées de données
 
-**Status :** À explorer
+**Status :** Retenue
 
-Formaliser la nomenclature des applications et demos lorsque l'environnement est imposé (`mainnet`, `devnet`, `testnet`, `local-validator`, `synthetic`) ou sélectionnable. Une application dont le nom impose un environnement doit forcer les profils, endpoints, bases et autres ressources cohérents avec cet environnement.
+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-<domain>-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.