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.

pre.020 rend kb_materializer_admin et kb_materializer_compliance_audit opérationnelles. pre.021 active ensuite kb_materializer_staking. Elles rejoignent donc la console et disposent de leurs routes propres sous :

logs/<profil>/kb_materializer_admin/
logs/<profil>/kb_materializer_compliance_audit/
logs/<profil>/kb_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.

README.md Unescape Escape