v0.4.7-pre.016

docs/IDEA_REMINDERS.md

@@ -1,94 +1,45 @@
 <!-- file: docs/IDEA_REMINDERS.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # 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.
+Ce document conserve les idées utiles qui ne constituent pas encore des engagements de version. Les orientations déjà intégrées au ROADMAP ne sont pas répétées comme propositions ouvertes.
 
 ## 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.
+- autocomplétion Token et Pool lorsque des tables de référence fiables existeront ;
+- pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs ;
+- résolution configurable du chemin de base de `kb-store` ;
+- sélection indépendante du profil de logging ;
+- protection systématique contre les doubles déclenchements des actions réseau ;
+- affichage explicite des preuves de matérialisation après confirmation.
 
 ## Pipeline et PostgreSQL
 
-- 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.
+- dimensionnement dynamique de la concurrence Decode replay selon le pool ;
+- retry borné et observable des erreurs transitoires ;
+- compteurs séparés pour erreurs fonctionnelles, traitement, stockage, reprises et échecs finaux ;
+- persistance éventuelle des erreurs survenant avant l’écriture du ledger.
+
+## Metadata et validation réseau
+
+- compléter ultérieurement les validations Devnet spécialisées Metaplex Token Metadata : Print, Burn, collections avancées, pNFT delegate/lock/unlock/revoke/transfer et rule sets ;
+- maintenir une distinction stricte entre validation synthétique, simulation RPC et soumission confirmée ;
+- prévoir les scénarios Devnet desktop dès la planification de chaque nouvelle surface, pas après l’implémentation ;
+- étudier `kb-offchain-transport` sans coupler le fetch distant au replay canonique.
 
 ## Documentation et outils
 
-- 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.
+- refaire les scripts Python d’audit après stabilisation définitive de la nomenclature ;
+- maintenir un inventaire des IDL avec source, version/commit, Program ID et surfaces utilisatrices ;
+- rescanner les archives bot2 et bobobot avant de déclarer le registre Program IDs complet.
 
-## Transport off-chain des metadata
+## Workers et applications
 
-- É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.
+L’orientation W1/W2, rattrapage historique, application de contrôle et applications consommatrices est désormais intégrée au ROADMAP. Les points encore ouverts sont :
 
-## 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.
+- mécanisme de notification fiable entre acquisition, stockage et décodage ;
+- ownership et idempotence entre W2 et le rattrapage historique ;
+- configuration à chaud et reprise après erreur ;
+- métriques, files d’attente et contrats d’administration ;
+- frontière entre événements temps réel et historiques OHLC.