0.5.1-pre.007

docs/rules/RULES_SPECIFIC_KHADHROONY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_SPECIFIC_KHADHROONY.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Règles spécifiques à `khadhroony-bot3`
 
@@ -237,21 +237,26 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
 
 ## Règles de configuration
 
-- La configuration commune Khadhroony Solana passe par `ks-config`, mais chaque binaire possède son fichier de composition et peut ajouter sa configuration dédiée sans rendre `ks-config` dépendant de ce binaire.
-- Le nom par défaut d'une composition binaire suit `<binary>.default.config.json`. Le desktop utilise `config/kb-app-demo-desktop.default.config.json` ; le CLI des scénarios utilise `config/ks-pipeline-demo-scenarios.default.config.json`.
-- Une composition référence les documents spécialisés et sélectionne explicitement les profils qu'elle consomme. Elle ne doit pas recopier les blocs transport, listeners ou logging.
-- Les documents partagés actuels sont `config/logging.config.json`, `config/transport.config.json` et `config/listeners.config.json`. Ils conservent chacun des profils nommés et peuvent être consommés indépendamment d'une composition.
-- Les schémas JSON actifs sont conservés exclusivement sous `config/schemas/`. `composition.config.schema.json`, `logging.config.schema.json`, `transport.config.schema.json` et `listeners.config.schema.json` décrivent les documents source ; `resolved.app.config.schema.json` décrit uniquement le contrat runtime transitoire reconstruit par `ks-config`.
+- La configuration commune Khadhroony Solana passe par `ks-config`, mais chaque binaire peut posséder un fichier de composition et une configuration dédiée sans rendre `ks-config` dépendant de ce binaire.
+- Le nom par défaut d'une composition binaire suit `<binary>.default.config.json`. Le desktop utilise `config/kb-app-demo-desktop.default.config.json`. Un consommateur qui accepte intégralement les defaults partagés ne doit pas créer une composition uniquement pour les répéter.
+- Les documents partagés actifs sont `config/logging.config.json`, `config/transport.config.json`, `config/listeners.config.json`, `config/store.config.json`, `config/wallet.config.json` et `config/execution.config.json`.
+- Chaque document partagé définit un `default_profile`. Une composition peut sélectionner un autre profil ; une référence explicite doit être validée par `ks-config` et doit désigner un profil existant.
+- Une composition ne recopie pas arbitrairement les paramètres d’un document spécialisé. Les overrides de champ restent définis et validés par le contrat propriétaire (par exemple les overrides d’un endpoint WebSocket) ; les valeurs globales explicitement prévues pour l’environnement peuvent être remplacées via `KS_*`/`KB_*`.
+- Les valeurs qui ne varient pas par profil restent au niveau racine de leur document spécialisé. `logs_directory` appartient au logging et `wallets_directory` au wallet ; ils ne doivent pas être dupliqués dans les profils.
+- Les valeurs globales pouvant varier par installation doivent fournir un défaut versionné sûr et peuvent être remplacées par une variable d'environnement namespacée.
+- Les endpoints WebSocket doivent sélectionner une classe de defaults nommée ; leurs timeouts, capacités et politique `auto_reconnect` peuvent être remplacés explicitement au niveau de l'endpoint.
+- Les autorisations `*_send_enabled` appartiennent à la politique d'exécution, pas au contrat d'identité/stockage wallet.
+- Les schémas JSON actifs sont conservés exclusivement sous `config/schemas/`. Les documents source spécialisés possèdent chacun leur schéma ; `resolved.app.config.schema.json` décrit uniquement le contrat runtime transitoire reconstruit par `ks-config`.
 - Les exemples conformes restent sous `config/` avec un nom distinct des fichiers runtime. Les fixtures d'un contrat runtime résolu appartiennent à `test-fixtures/` et ne doivent pas être chargées en production.
-- Les fichiers historiques `config/app.config.json`, `config/example.app.config.json`, `config/schemas/app.config.schema.json`, `config/example.config.json` et `config/schema.config.json` sont interdits dans l'état courant.
-- Le chemin de composition desktop peut être remplacé par `KB_APP_DEMO_DESKTOP_CONFIG_PATH`. `KS_DEVNET_CONFIG_PATH` sélectionne une composition pour les scénarios Devnet opt-in. `KS_LOGGING_CONFIG_PATH` reste un override explicite du document logging ; sans override, la composition fournit son chemin.
+- Les fichiers historiques `config/app.config.json`, `config/example.app.config.json`, `config/schemas/app.config.schema.json`, `config/example.config.json`, `config/schema.config.json` et `config/ks-pipeline-demo-scenarios.default.config.json` sont interdits dans l'état courant.
+- Le chemin de composition desktop peut être remplacé par `KB_APP_DEMO_DESKTOP_CONFIG_PATH`. `KS_DEVNET_CONFIG_PATH` est uniquement un override facultatif vers une composition explicite pour les scénarios Devnet ; sans cet override, les scénarios utilisent les defaults partagés. `KS_LOGGING_CONFIG_PATH` reste un override explicite du document logging.
 - Les fichiers JSON de configuration ne doivent pas contenir de commentaires.
 - Les secrets ne doivent pas être écrits en clair dans le dépôt.
 - Les valeurs sensibles doivent utiliser des variables d'environnement ou un stockage chiffré dédié.
 - Les variables possédées par les composants généralistes `ks-*` utilisent obligatoirement `KS_SECRET_*`, `KS_PUBLIC_*` ou `KS_*` ; les variables réellement spécifiques à `kb-app-demo-desktop` ou à de futures crates `kb-*` utilisent `KB_SECRET_*`, `KB_PUBLIC_*` ou `KB_*`.
-- Le namespace est déterminé par le propriétaire fonctionnel du contrat et non par son consommateur : une variable de scénario `ks-pipeline-demo-scenarios` reste `KS_*` même si le desktop la lit.
+- Le namespace est déterminé par le propriétaire fonctionnel du contrat et non par son consommateur.
 - Les sous-préfixes `SECRET` sont toujours non exposables ; les sous-préfixes `PUBLIC` ne sont exposables que par une surface explicitement autorisée ; les autres variables du domaine sont internes.
-- Les structures de configuration exposées à Tauri doivent dériver `TS`.
+- Les bindings TS-RS sont prioritairement une frontière d'application Tauri. Une crate `ks-*` ne conserve une dérivation/export TypeScript que si le type constitue un contrat externe générique explicitement justifié ; sinon l'application définit un DTO/wrapper dédié.
 
 ## Ordre de développement cible