# 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_onchain_transport`, 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. ## Variables d’environnement de l’exemple `example.config.json` conserve la topologie des profils et référence les valeurs locales avec des placeholders : ```text HELIUS_API_KEY KB_POSTGRES_MAINNET_URL KB_POSTGRES_DEVNET_URL ``` `KB_POSTGRES_TEST_URL` n’est pas utilisé par un profil runtime : il reste réservé aux tests d’intégration PostgreSQL. Le profil `local_devnet` utilise `KB_POSTGRES_DEVNET_URL`; les profils `mainnet_research` et `mainnet` utilisent `KB_POSTGRES_MAINNET_URL`. Les trois bases doivent être distinctes. Le fichier réel `.env` reste local et ignoré par Git. `.env.example` est le seul modèle dotenv versionné. ## Phase `0.3.x` `0.3.x` utilise les endpoints HTTP des profils de recherche existants pour : ```text 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 : ```text logs//kb-lib/materializer/admin/ logs//kb-lib/materializer/compliance/ logs//kb-lib/materializer/lifecycle/ logs//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.