ks-config fournit les contrats de configuration généralistes Khadhroony Solana, les chargeurs des documents spécialisés et la résolution des compositions facultatives utilisées par les binaires.

Responsabilités

charger l'environnement du workspace et résoudre les placeholders ${KS_*} / ${KB_*} ;
valider les documents transport, listeners, store, wallet, execution et composition contre leurs schémas sous config/schemas/ ;
fournir les types partagés d'endpoints, listeners, stockage, wallet, exécution et profils runtime ;
permettre à un profil wallet de sélectionner un alias persistant non sensible, sans devenir gestionnaire de password ou de matériau privé ;
résoudre les defaults de chaque document ou les overrides d'une composition ;
refuser une référence de fichier ou de profil inexistante ;
reconstruire temporairement AppConfig/ProfileConfig pour les consommateurs existants ;
rester indépendant de la liste des applications et workers futurs.

Defaults et composition

Chaque document partagé possède un default_profile. Un consommateur qui accepte les defaults n'a pas besoin de composition dédiée.

Le desktop possède config/kb-app-demo-desktop.default.config.json parce qu'il sélectionne des combinaisons propres à l'application. ks-pipeline-demo-scenarios utilise directement les defaults partagés ; KS_DEVNET_CONFIG_PATH permet encore un override explicite lorsque nécessaire.

Un futur worker pourra ajouter son propre <binary>.default.config.json uniquement s'il doit remplacer des fichiers/profils ou ajouter des paramètres propres au binaire.

Documents spécialisés actuels

config/transport.config.json / config/schemas/transport.config.schema.json ;
config/listeners.config.json / config/schemas/listeners.config.schema.json ;
config/store.config.json / config/schemas/store.config.schema.json ;
config/wallet.config.json / config/schemas/wallet.config.schema.json ;
config/execution.config.json / config/schemas/execution.config.schema.json ;
config/logging.config.json reste possédé par ks-logging ;
config/schemas/resolved.app.config.schema.json décrit uniquement le contrat runtime transitoire.

Les valeurs globales telles que logs_directory et wallets_directory ne sont pas des propriétés de profils.

API publique principale

read_composed_app_config_with_environment ;
read_default_shared_app_config_with_environment ;
parse_composition_json, composition_profile, active_composition_profile ;
read_transport_json_file_with_environment, transport_profile, default_transport_profile ;
read_listeners_json_file_with_environment, listeners_profile, default_listeners_profile ;
read_store_json_file_with_environment, store_profile, default_store_profile ;
read_wallet_json_file_with_environment, wallet_profile, default_wallet_profile ;
read_execution_json_file_with_environment, execution_profile, default_execution_profile ;
load_workspace_environment, resolve_environment_placeholders ;
classify_environment_variable, classify_environment_template, diagnostic_environment_value ;
validate_json_value_against_schema pour les fragments possédés par les binaires ;
AppConfig, ProfileConfig pendant la phase de compatibilité backend-only.

Frontières

ks-logging dépend de ks-config pour les helpers d'environnement, mais ks-config ne possède aucun type logging runtime.

ks-onchain-transport peut consommer directement TransportProfileConfig.

Depuis 0.5.1, ks-config ne dépend plus de TS-RS et ne produit plus de bindings TypeScript. Ses contrats source/runtime peuvent contenir des secrets résolus : ils ne dérivent donc ni serde::Serialize ni Debug. Les applications propriétaires construisent leurs DTO publics et diagnostics bornés champ par champ.

La section application d'une composition est volontairement opaque pour ks-config. Chaque binaire propriétaire définit son schéma et le valide avec validate_json_value_against_schema; le desktop utilise config/schemas/kb-app-demo-desktop.application.config.schema.json.