v0.1.0-pre.074-fix001

docs/IDEA_REMINDERS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/IDEA_REMINDERS.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Rappels d’idées
 
@@ -32,3 +32,63 @@ Ce document regroupe les améliorations utiles mais non bloquantes pour la clôt
 - Décider séparément si cette crate accepte uniquement des lectures ou aussi des opérations off-chain authentifiées/mutables, avec contrats de sécurité distincts.
 - Borner tailles, types MIME, redirections, délais et schémas HTTP(S)/IPFS/Arweave.
 - Ne pas coupler le fetch off-chain au décodage déterministe ni au replay canonique on-chain.
+
+## Registre Program IDs, IDL et surfaces implémentées
+
+- Analyser `olddocs/archivekbobobot/docs/SOLSCAN_ACCOUNT_SOURCE_MATRIX.md` et les documents équivalents de bot2.
+- Construire un registre croisé contenant au minimum Program ID, protocole, source vérifiée, présence d’IDL, provenance de l’IDL et chemin local.
+- Comparer ce registre avec les constantes de `kb-program-ids`.
+- Comparer chaque entrée avec les décodeurs, exécuteurs et matérialisateurs réellement présents dans `kb-lib`.
+- Distinguer les IDL provenant de Solscan, Solana Explorer, dépôts Git officiels ou autres sources vérifiées.
+- Ne pas déclarer l’inventaire complet avant le rescan des archives bot2 et bobobot.
+
+## Architecture future des workers et applications
+
+Cette proposition doit être étudiée avant intégration au ROADMAP définitif.
+
+### Worker W1 — acquisition temps réel
+
+- Binaire long-running utilisant `kb-onchain-transport`.
+- Écoute configurable de Program IDs, logs, comptes ou autres filtres.
+- Support progressif WebSocket, gRPC et recours HTTP/RPC lorsque nécessaire.
+- Écriture des signatures et transactions raw dans `kb-store`.
+- Modification à chaud des abonnements.
+- Notification fiable de l’arrivée de nouvelles données raw.
+- Arrêt uniquement sur demande explicite ou erreur fatale contrôlée.
+
+### Worker W2 — décodage et matérialisation temps réel
+
+- Binaire recevant ou détectant les notifications de nouveaux raw.
+- Exécution des décodeurs et matérialisateurs activés.
+- Configuration à chaud des surfaces actives.
+- Notification après décodage et matérialisation.
+- Traitement uniquement des données reçues pendant son activité ; aucun rattrapage implicite des périodes d’arrêt.
+
+### Application de rattrapage historique
+
+- Application ou binaire séparé, éventuellement Tauri.
+- Réutilisation des capacités Core extraction, decode replay et matérialisation.
+- Traitement des raw non pris en charge en temps réel par W2.
+- Coordination explicite pour éviter la concurrence ou la double prise en charge avec W2.
+- Backfill ciblé pour combler des périodes manquantes.
+- Décodage et matérialisation configurables comme dans W2.
+
+### Pilotage W1/W2
+
+- Application de contrôle permettant de modifier à chaud les filtres d’acquisition, décodeurs et matérialisateurs.
+- Diagnostics, état des workers, files d’attente, erreurs et métriques.
+- Contrats d’administration séparés des contrats de données.
+
+### Applications consommatrices
+
+- Application de trading consommant les événements temps réel de W2 et l’historique de `kb-store`.
+- Filtrage d’événements tels que nouveaux tokens, nouvelles paires, prix, migrations launchpad vers AMM, burns et changements de liquidité.
+- Construction d’historiques et OHLC depuis les matérialisations stockées.
+- Application non trading utilisant la même combinaison temps réel et historique pour visualiser les autres matérialisations.
+
+### Principe de déploiement progressif
+
+- W1 doit pouvoir continuer à acquérir les raw pendant le développement de nouveaux décodeurs.
+- W2 et les applications peuvent être redémarrés pour charger de nouvelles surfaces.
+- Le rattrapage historique doit traiter les périodes non couvertes sans perturber le flux temps réel.
+- Les frontières de notification, ownership de traitement, idempotence et reprise doivent être définies avant implémentation.