v0.2.0-pre.002

docs/IDEAS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDEAS.md -->
-<!-- version: 15 -->
+<!-- version: 16 -->
 
 # Idées à explorer
 
@@ -70,6 +70,14 @@ Définir avec les premières APIs réelles les conventions de nommage des traits
 
 Définir avec les premières crates fonctionnelles les conventions d'arborescence, façades `lib.rs`, modules API et réexports publics.
 
+### API Interface séparée
+
+**Status :** Rejetée pour l'instant
+
+`ksp-interface-lib` expose sa propre API publique wire afin que des crates Program externes puissent expérimenter contre les mêmes contrats que les implementations officielles.
+
+Ne créer `ksp-interface-api` que si un futur problème réel de graphe de dépendances, de poids d'implémentation ou de publication démontre qu'un contrat séparé est nécessaire. La symétrie avec `ksp-program-api` n'est pas une justification suffisante.
+
 ## Transport
 
 ### Modèles homogènes on-chain
@@ -94,17 +102,44 @@ Réévaluer seulement si les premières implémentations montrent une duplicatio
 
 `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.
 
+### Pool automatique de sessions WebSocket
+
+**Status :** À explorer après `0.2.4`
+
+Le contrat WebSocket doit autoriser plusieurs sessions physiques sur une même URL, chaque session portant plusieurs subscriptions.
+
+Ne pas implémenter automatiquement un scheduler/pool de sessions tant qu'un besoin réel de distribution de charge, quotas provider, isolation de flux ou reconnexion indépendante ne le justifie pas.
+
+### Providers Yellowstone avancés
+
+**Status :** À explorer après la fondation standard
+
+Candidats à intégrer ultérieurement par adapters/capabilities sans dupliquer le client Yellowstone générique :
+
+- Helius LaserStream gRPC ;
+- Triton One / Dragon's Mouth ;
+- ERPC ;
+- Chainstack ;
+- Shyft ;
+- autres providers compatibles réellement utiles.
+
+Le choix dépendra des capacités, quotas, replay, authentification, prix et besoins opérationnels au moment de leur introduction.
+
+### Streaming pré-exécution / shreds
+
+**Status :** À explorer plus tard
+
+Conserver comme pistes séparées les offres pré-exécution/shred/deshred (Helius Shred Delivery, Triton/Yellowstone deshred, Shyft RabbitStream ou équivalents). Leur sémantique n'est pas identique à un flux exécuté Yellowstone standard et elles ne doivent pas être ajoutées comme simples aliases provider sans audit.
+
 ## Workers et jobs
 
 ### Workers de processing
 
-**Status :** Retenue
+**Status :** Retenue, granularité révisée
 
-Après `ksp-worker-raw-retriever`, les responsabilités de processing actuellement prévues sont séparées :
+RAW et CORE peuvent disposer de workers dédiés à la fin de leur couche respective.
 
-- `ksp-worker-core-processor` ;
-- `ksp-worker-generic-materializer` ;
-- `ksp-worker-domain-projector` (nom provisoire).
+À partir de DECODE, ne pas figer à l'avance une chaîne globale `generic-materializer -> domain-projector` pour tout Solana : la granularité des workers/processors doit émerger des vertical slices Program réels et réutiliser les mêmes transformations que les jobs de replay correspondants.
 
 ### Worker control
 
@@ -145,6 +180,24 @@ Le modèle de sécurité, la frontière Rust/WebAssembly/native et le stockage d
 
 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.
 
+### Formats Wallet import/export supplémentaires
+
+**Status :** À explorer avec `0.2.2` et après
+
+Le format natif KSP est `.kspwallet`. L'architecture d'import/export doit rester extensible, mais seules les conversions réellement nécessaires sont implémentées immédiatement.
+
+Formats/cibles à inventorier et prioriser selon usage réel :
+
+- Solana CLI keypair JSON ;
+- keypair Base58 complet lorsque pertinent ;
+- Phantom ;
+- Solflare ;
+- autres wallets logiciels Solana ;
+- hardware wallets / standards de dérivation si un besoin apparaît ;
+- migrations depuis formats historiques KSP/bot uniquement si utiles aux utilisateurs réels.
+
+Chaque format doit être étudié côté sécurité, round-trip, secret/public, dépendances et compatibilité avant engagement.
+
 ## Pipelines
 
 ### Pas de pipeline monolithique
@@ -276,6 +329,24 @@ Checkpoint/restart est nécessaire pour backfill/replay. Déterminer si pause/re
 
 Backlog count, oldest pending age, processing rate et failure rate doivent être observables. Décider plus tard si health/status + logging suffisent ou si une API/metrics exporter dédiée devient nécessaire.
 
+### Market Desk évolutive
+
+**Status :** Transférée au roadmap
+
+Introduire une première `ksp-app-market-desk` après les groupes DEX prioritaires Meteora/Raydium/Pump/Orca, puis l'enrichir après Jupiter/OKX.
+
+Pistes futures au-delà de la V1/V2 :
+
+- profondeur/market microstructure si les sources le permettent ;
+- indicateurs dérivés ;
+- alertes/anomalies ;
+- overlays de risk ;
+- outputs XGBoost/ML ;
+- comparaison de providers/latence ;
+- vues replay historiques.
+
+Ces extensions restent séparées de l'application de trading opérationnel tant que leur responsabilité est l'observation/analyse.
+
 ## Applications et orchestration futures
 
 ### Application globale de contrôle/exploitation
@@ -318,8 +389,8 @@ Si cette capacité devient utile, l’intégration doit être conçue dans la pi
 
 ### Numérotation fine après `0.1.x`
 
-**Status :** À décider à l'approche de chaque série
+**Status :** Transférée au roadmap pour le début de `0.2.x`
 
-`0.1.1` et `0.1.2` sont fixées ; `0.1.3` / `0.1.4` constituent la séquence par défaut sous réserve d'une éventuelle scission de Config.
+`0.2.0-pre.002` fixe désormais le début concret `0.2.1 -> 0.2.10` sous réserve du gate de dimensionnement de chaque `pre.001`.
 
-Pour `0.2.x+`, ne pas attribuer prématurément un numéro précis à chaque composant. L'ordre candidat est documenté dans `docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md` et sera converti en releases concrètes lorsque les dépendances et premiers cas d'usage de la série seront connus.
+Les séries après RAW/CORE ne sont volontairement pas numérotées programme par programme à ce stade : la règle est de redécouper chaque vertical slice selon sa taille réelle et de ne jamais ouvrir une release qui ne peut pas être clôturée dans sa session.