63 lines
2.5 KiB
Markdown
63 lines
2.5 KiB
Markdown
<!-- 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.
|
||
|