0.5.1-pre.007

docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Politique de namespace Khadhroony Solana
 
@@ -57,33 +57,38 @@ Chaque domaine possède les trois mêmes classes :
 - `KS_PUBLIC_*` / `KB_PUBLIC_*` : valeur explicitement classée comme publiable ; le préfixe ne suffit pas à lui seul à autoriser une exposition, qui doit rester définie par un DTO ou une surface publique explicite ;
 - `KS_*` / `KB_*` hors sous-préfixes précédents : valeur interne ; elle n'est pas exposée en fonctionnement normal mais peut être incluse dans un diagnostic explicitement demandé si sa sémantique n'est pas sensible.
 
-Une variable appartenant à un contrat `ks-*` qui utilise `KB_*`, ou l'inverse pour un contrat réellement spécifique `kb-*`, est non conforme. `0.5.1-pre.004` ne laisse actuellement aucun contrat d'environnement propre au desktop : les variables qu'il consomme appartiennent toutes aux composants ou scénarios Solana et utilisent donc `KS_*`.
+Une variable appartenant à un contrat `ks-*` qui utilise `KB_*`, ou l'inverse pour un contrat réellement spécifique `kb-*`, est non conforme. `0.5.1-pre.004` n’avait encore identifié aucun contrat d’environnement propre au desktop. Depuis l’introduction des compositions par binaire, `KB_APP_DEMO_DESKTOP_CONFIG_PATH` est le premier contrat réellement possédé par `kb-app-demo-desktop`; les variables des composants et scénarios Solana qu’il consomme restent `KS_*`.
 
 La classification d'une valeur sensible doit survivre à la substitution. Une chaîne composée contenant une valeur issue de `KS_SECRET_*` ou `KB_SECRET_*` reste sensible dans son ensemble et ne doit pas redevenir une simple valeur publiable après résolution. Cette propagation et le camouflage effectif sont implémentés après le split config/logging, pas dans la prerelease de renommage.
 
 ## 5. Configuration source, runtime et publique
 
-La restructuration `0.5.1` utilise des compositions propres aux binaires et des documents spécialisés partagés :
+La restructuration `0.5.1` utilise des documents spécialisés Khadhroony Solana et, uniquement lorsque nécessaire, une composition propre au binaire :
 
-- `config/kb-app-demo-desktop.default.config.json` compose les besoins du desktop ;
-- `config/ks-pipeline-demo-scenarios.default.config.json` compose les besoins du CLI/scénarios ;
-- `config/logging.config.json` appartient à `ks-logging` ;
-- `config/transport.config.json` contient les profils HTTP/WebSocket partagés ;
-- `config/listeners.config.json` contient les profils de subscriptions Solana partagés ;
+- `config/kb-app-demo-desktop.default.config.json` compose les overrides du desktop ;
+- `config/logging.config.json` appartient à `ks-logging` et porte notamment `logs_directory` hors profils ;
+- `config/transport.config.json` contient les profils HTTP/WebSocket et les classes de defaults WebSocket ;
+- `config/listeners.config.json` contient les profils de subscriptions Solana ;
+- `config/store.config.json` contient les profils de stockage ;
+- `config/wallet.config.json` contient la racine wallet globale et les profils wallet ;
+- `config/execution.config.json` contient les politiques de simulation, soumission et limites ;
 - tous les schémas actifs résident sous `config/schemas/`.
 
-Le fichier de composition sélectionne explicitement les profils spécialisés. Un nouveau worker ou binaire doit pouvoir fournir son propre `<binary>.default.config.json` et une configuration dédiée sans modifier `ks-config` pour enregistrer son existence.
+Chaque document partagé possède un `default_profile`. Un consommateur qui accepte les defaults n'a pas besoin de composition dédiée. C'est notamment le cas de `ks-pipeline-demo-scenarios`; `KS_DEVNET_CONFIG_PATH` reste uniquement un override facultatif vers une composition explicite.
+
+Lorsqu'un binaire possède une composition, celle-ci peut remplacer indépendamment les profils spécialisés. `ks-config` doit prouver l'existence des fichiers et des profils référencés avant de produire le contrat runtime.
 
 `AppConfig/ProfileConfig` reste temporairement un contrat runtime résolu afin de préserver les consommateurs pendant la migration. Il n'est plus un document source chargé directement ; son schéma de compatibilité est `config/schemas/resolved.app.config.schema.json` et ses fixtures sont sous `test-fixtures/config/`.
 
-La conception doit distinguer :
+La conception distingue :
 
-1. la représentation source, composée de documents indépendants pouvant contenir des références `${KS_*}` ou `${KB_*}` selon le propriétaire du contrat ;
-2. la composition propre au binaire, qui choisit les documents et profils ;
-3. la représentation runtime résolue, qui peut porter des secrets ;
-4. la représentation publique/diagnostique, construite explicitement et incapable d'exposer une valeur secrète résolue.
+1. les documents source indépendants, pouvant contenir des références `${KS_*}` ou `${KB_*}` selon le propriétaire ;
+2. leurs valeurs globales et `default_profile` ;
+3. l'éventuelle composition propre au binaire, qui fournit des overrides ;
+4. la représentation runtime résolue, qui peut porter des secrets ;
+5. la représentation publique/diagnostique, construite explicitement et incapable d'exposer une valeur secrète résolue.
 
-Une configuration runtime complète ne doit jamais être sérialisée puis « nettoyée » après coup pour produire un payload public.
+Une configuration runtime complète ne doit jamais être sérialisée puis « nettoyée » après coup pour produire un payload public. Les bindings TypeScript des crates généralistes suivent la même frontière : ils ne sont conservés que lorsqu'un contrat générique indépendant d'une application Tauri le justifie.
 
 ## 6. Identités runtime et persistées