khadhroony-bot3/config

Configuration locale

Ce dossier contient les exemples et le schéma de configuration JSON.

Règles

• Le fichier versionné doit rester sans secret.
• Les placeholders de clés restent directement dans les URLs.
• Le champ active_profile sélectionne un seul profil actif.
• Un profil actif doit être présent et unique.
• Les profils non actifs peuvent rester dans le fichier pour les tests devnet, mainnet lecture seule, backfill ou future production.
• Le contrat courant couvre HTTP JSON-RPC Solana et WebSocket JSON-RPC générique.
• Helius transactionSubscribe et Yellowstone gRPC seront ajoutés plus tard dans kb_rpc, avec évolution explicite du schéma quand les transports seront réellement utilisés.
• Les IDLs restent des artefacts de développement et ne font pas partie de la configuration runtime.

Fichiers

• example.config.json : exemple complet avec profils local_devnet, mainnet_research et mainnet.
• schema.config.json : JSON Schema de validation du fichier de configuration.

Phase 0.3.x

0.3.x utilise les endpoints HTTP des profils de recherche existants pour :

getSignaturesForAddress
getTransaction
getSignatureStatuses

Aucun profil Helius payant ou Yellowstone n’est activé à ce stade.

Les sources futures devront déclarer séparément :

• provider ;
• protocole ;
• rôle ;
• limites de streams et filtres ;
• authentification ;
• région éventuelle.

Évolution du schéma

schema.config.json est le contrat de validation runtime. Il évolue seulement lorsqu’un champ est réellement utilisé par l’exécution.

Logging de développement

L’exemple configure, pour chacun des trois profils, quatre fichiers globaux puis trois fichiers dédiés par crate opérationnelle utilisant tracing : debug.log, info.log et error.jsonl.

Les matérialisateurs natifs consolidés rejoignent la console et disposent de leurs routes propres sous :

logs/<profil>/kb-lib/materializer/admin/
logs/<profil>/kb-lib/materializer/compliance/
logs/<profil>/kb-lib/materializer/lifecycle/
logs/<profil>/kb-lib/materializer/staking/

Le test de configuration découvre dynamiquement toutes les crates déclarant tracing.workspace = true et vérifie leurs trois routes dans chaque profil. Les logs ne doivent contenir ni secret, ni DSN non masqué, ni payload Config ou bytecode complet.