khadhroony-bot3/config

Configuration locale

Ce dossier contient les deux documents de configuration runtime, leurs exemples et leurs schémas JSON indépendants.

Fichiers chargés par défaut

• app.config.json : configuration générale Khadhroony Solana ;
• logging.config.json : configuration logging/tracing ;
• schemas/app.config.schema.json : schéma du document général ;
• schemas/logging.config.schema.json : schéma du document logging.

Les chemins par défaut peuvent être remplacés indépendamment par :

KS_CONFIG_PATH
KS_LOGGING_CONFIG_PATH

Exemples conformes

• example.app.config.json : exemple général minimal conforme ;
• example.logging.config.json : exemple logging minimal conforme.

Les exemples servent de référence de structure. Ils ne sont pas sélectionnés automatiquement au démarrage.

Sélection indépendante des profils

Chaque document possède son propre active_profile :

app.config.json
    active_profile = mainnet_research

logging.config.json
    active_profile = mainnet_research

Ces valeurs sont indépendantes. Changer le profil applicatif ne change pas implicitement le profil logging, et inversement. Les noms peuvent être identiques pour faciliter l’exploitation sans créer de couplage contractuel.

Le document général ne contient plus de propriété logging. Les routes, niveaux, formats et filtres sont exclusivement possédés par logging.config.json et ks-logging.

Variables d’environnement

app.config.json référence notamment :

KS_SECRET_HELIUS_API_KEY
KS_SECRET_POSTGRES_MAINNET_URL
KS_SECRET_POSTGRES_DEVNET_URL

KS_SECRET_POSTGRES_TEST_URL reste réservé aux tests d’intégration PostgreSQL. Le fichier réel .env reste local et ignoré par Git ; .env.example est le modèle versionné.

La classification KS_SECRET_* / KS_PUBLIC_* / KS_* et KB_SECRET_* / KB_PUBLIC_* / KB_* est normative. Le camouflage et la propagation de sensibilité dans les valeurs composées sont traités dans la prerelease suivante ; aucun secret ne doit être écrit en clair dans un fichier versionné.

Schémas

Les schémas runtime sont localisés exclusivement sous config/schemas/.

ks-config embarque schemas/app.config.schema.json. ks-logging embarque schemas/logging.config.schema.json. Les fichiers embarqués et leurs versions sur disque doivent rester identiques.

Migration depuis le format combiné

L’ancien example.config.json combinait configuration générale et logging dans chaque profil. La migration consiste à :

1. conserver dans app.config.json les sections app, database, data, solana, wallet, execution et demo ;
2. extraire chaque ancien bloc logging vers le profil homonyme de logging.config.json ;
3. sélectionner explicitement un active_profile dans chacun des deux documents ;
4. supprimer l’ancien fichier combiné une fois la migration validée.

Logging de développement

Le fichier logging.config.json conserve actuellement les routes globales ainsi que trois fichiers dédiés par crate opérationnelle utilisant tracing : debug.log, info.log et error.jsonl.

Les matérialisateurs consolidés disposent de leurs routes sous les targets ks-lib-materializer.*. Les tests de ks-logging découvrent dynamiquement les crates déclarant tracing.workspace = true et vérifient les routes canoniques du document logging par défaut.

Les logs ne doivent contenir ni secret, ni DSN non masqué, ni keypair, ni payload de configuration résolue complet.

Limites du profil public Devnet

api.devnet.solana.com est un endpoint public partagé. Les limites configurées par rôle ne sont pas des quotas indépendants fournis par le serveur : leur débit cumulé doit rester sous la limite globale de l’endpoint, et chaque méthode RPC doit également rester sous sa propre limite.

Le profil local_devnet de app.config.json utilise donc volontairement des valeurs conservatrices pour les rôles HTTP. Un warning retry_http_json_rpc_after_rate_limit reste possible sur un service partagé ; il indique que le cooldown et le retry borné ont été activés.