0.1.0

config/README.md

@@ -0,0 +1,62 @@
+<!-- file: config/README.md -->
+<!-- version: 13 -->
+
+# 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 :
+
+```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`.
+
+`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 :
+
+```text
+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.
+