Un binaire ne possède pas une copie complète de toutes les configurations partagées. Il charge un fichier de composition <binary>.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 :

config/kb-app-demo-desktop.default.config.json

Le CLI des scénarios possède également une composition explicite :

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

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 :

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.