Rappels d’idées

Ce document regroupe les améliorations utiles mais non bloquantes pour la clôture de la migration et pour la reprise du développement fonctionnel.

Application desktop

Ajouter une autocomplétion Token lorsque des tables de référence fiables existeront.
Ajouter une autocomplétion Pool lorsque des tables de référence fiables existeront.
Introduire une pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs.
Étudier une résolution configurable du chemin de base utilisé par kb-store.
Séparer à terme la configuration du logging dans un fichier JSON dédié avec son propre schéma et ses propres profils de logging.
Permettre de sélectionner et changer un profil de logging indépendamment du profil applicatif actif, afin que les fenêtres Devnet puissent écrire dans des routes ou fichiers distincts sans changer le profil général de l’application.

Dimensionner dynamiquement la concurrence Decode replay en fonction du pool PostgreSQL disponible.
Ajouter un retry borné et observable pour les erreurs transitoires de pool PostgreSQL.
Conserver dans les résumés des compteurs distincts pour les échecs fonctionnels, les erreurs de traitement ou de stockage, les entrées récupérées après retry et les échecs finaux.
Étudier une persistance dédiée des erreurs transitoires qui surviennent avant qu’une ligne de ledger puisse être écrite.

Refaire les scripts Python d’audit après stabilisation définitive de la structure, des targets et de la nomenclature.
Maintenir un inventaire des IDL actives avec leur source, leur version ou commit, leur Program ID et les surfaces qui les utilisent.

Évaluer une crate kb-offchain-transport générale après le pipeline metadata : fetch HTTP(S)/IPFS/Arweave, prix SOL/USD-EUR-CHF, APIs Jupiter et autres fournisseurs non Solana RPC.
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.

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.

Cette proposition doit être étudiée avant intégration au ROADMAP définitif.

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 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.

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.

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.

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.