# Configuration locale Ce dossier contient les compositions propres aux binaires, les documents de configuration partagés, leurs exemples et les schémas JSON actifs. ## Principe de composition Un binaire ne possède pas une copie complète de toutes les configurations partagées. Il charge un fichier de composition `.default.config.json` qui référence les documents spécialisés et sélectionne explicitement un profil dans chacun. Le desktop utilise par défaut : ```text config/kb-app-demo-desktop.default.config.json ``` Le CLI des scénarios possède également une composition explicite : ```text config/ks-pipeline-demo-scenarios.default.config.json ``` La composition desktop peut être remplacée par `KB_APP_DEMO_DESKTOP_CONFIG_PATH`. Les tests/scénarios Devnet opt-in peuvent remplacer leur composition avec `KS_DEVNET_CONFIG_PATH`. ## Documents partagés actuels ```text config/ ├── kb-app-demo-desktop.default.config.json ├── ks-pipeline-demo-scenarios.default.config.json ├── logging.config.json ├── transport.config.json ├── listeners.config.json ├── example.kb-app-demo-desktop.default.config.json ├── example.logging.config.json ├── example.transport.config.json ├── example.listeners.config.json └── schemas/ ├── composition.config.schema.json ├── logging.config.schema.json ├── transport.config.schema.json ├── listeners.config.schema.json └── resolved.app.config.schema.json ``` `resolved.app.config.schema.json` décrit uniquement le contrat runtime `AppConfig/ProfileConfig` reconstruit par `ks-config`. Il ne correspond pas à un fichier runtime chargé directement. ## Sélection des profils Les documents partagés conservent un `active_profile` pour les consommateurs autonomes. Une composition binaire peut cependant sélectionner un autre profil explicitement : ```text composition profile mainnet_research logging_profile = mainnet_research transport_profile = mainnet_research listeners_profile = mainnet_research ``` Lorsqu'une composition est utilisée, sa sélection explicite prime pour le binaire. Le même `transport.config.json` ou `listeners.config.json` peut donc être réutilisé par plusieurs binaires avec des combinaisons différentes. ## Transport `transport.config.json` possède les endpoints HTTP et WebSocket, leurs providers, clusters, timeouts, capacités, rôles, limites et politique de reconnexion propre aux endpoints. `ks-onchain-transport` peut consommer directement un `TransportProfileConfig`. Un futur worker n'a donc pas besoin de dépendre d'un `ProfileConfig` applicatif complet pour construire ses pools réseau. ## Listeners `listeners.config.json` possède les ensembles de listeners Solana : - `logsSubscribe` par mention de programme ; - `programSubscribe` ; - `accountSubscribe` ; - commitment et rôles d'endpoint associés. La séparation prépare les futurs workers de capture, qui pourront associer un profil transport et un profil listeners sans recopier les définitions dans leur propre configuration. ## Logging `logging.config.json` reste possédé par `ks-logging`. Une composition sélectionne le profil logging souhaité. `KS_LOGGING_CONFIG_PATH` reste un override direct du chemin logging pour l'exploitation ; sans override, le chemin déclaré par la composition est utilisé. ## Configuration encore transitoire dans la composition Après `pre.006`, les sections suivantes restent temporairement dans les profils de composition : - `database` et `data` ; - `wallet` ; - `execution` ; - `demo`. Elles seront séparées dans la prerelease suivante. En particulier, `demo` est propre au desktop et ne doit pas rester durablement dans un contrat généraliste `ks-config`. ## Variables d'environnement Les composants `ks-*` utilisent `KS_SECRET_*`, `KS_PUBLIC_*` ou `KS_*`. Les besoins réellement spécifiques à une application `kb-*` utilisent `KB_SECRET_*`, `KB_PUBLIC_*` ou `KB_*`. Les secrets ne sont jamais écrits en clair dans le dépôt. La propagation de sensibilité et les DTO publics sûrs sont traités après la fin du découpage des fichiers de configuration. ## Exemples et schémas Les exemples sous `config/` sont des références conformes et ne sont pas chargés automatiquement. Tous les schémas actifs résident exclusivement sous `config/schemas/`. Les fichiers historiques `app.config.json`, `example.app.config.json`, `schemas/app.config.schema.json`, `example.config.json` et `schema.config.json` sont obsolètes et ne doivent pas coexister avec cette architecture. ## Logging de développement Le fichier `logging.config.json` conserve les routes globales ainsi que trois fichiers dédiés par crate opérationnelle utilisant `tracing` : `debug.log`, `info.log` et `error.jsonl`. Les logs ne doivent contenir ni secret, ni DSN non masqué, ni keypair, ni payload de configuration résolue complet.