0.5.1-pre.004

docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Politique de namespace Khadhroony Solana
 
@@ -7,7 +7,7 @@
 
 Cette décision est adoptée pendant la clôture de `0.5.0` et devient la cible normative des migrations de fondation `0.5.1` à `0.5.3`.
 
-À partir de `0.5.1-pre.002`, les dix crates Solana généralistes sont physiquement nommées `ks-*` et leurs identifiants Rust `ks_*`. `0.5.1-pre.003` migre également les identités techniques `kb-lib.*` vers `ks-lib-*`. Les namespaces historiques `KB_*` et `kb_sol_*` restent temporairement présents jusqu'aux prereleases dédiées ; leur présence pendant cette migration bornée ne remet pas en cause la cible ci-dessous.
+À partir de `0.5.1-pre.002`, les dix crates Solana généralistes sont physiquement nommées `ks-*` et leurs identifiants Rust `ks_*`. `0.5.1-pre.003` migre également les identités techniques `kb-lib.*` vers `ks-lib-*`. `0.5.1-pre.004` migre les variables possédées par Khadhroony Solana vers `KS_*` et réserve explicitement `KB_*` aux composants réellement possédés par Khadhroony Bot. Le namespace SQL `kb_sol_*` reste temporairement présent jusqu'à `0.5.3`.
 
 Le renommage des bibliothèques internes ne renomme pas le workspace, le dépôt ni le répertoire racine : ils restent `khadhroony-bot3` pendant toute la série pré-`1.0`. Un éventuel renommage du workspace racine est explicitement hors périmètre de `0.5.x` et ne doit intervenir qu'en `1.0` ou ultérieurement sur décision dédiée.
 
@@ -44,17 +44,22 @@ La migration doit couvrir les manifests, chemins de workspace, imports, exports,
 
 ## 4. Variables d'environnement
 
-Toutes les variables d'environnement appartenant aux contrats Khadhroony Solana/Bot doivent utiliser le namespace `KS_` après la migration `0.5.1`.
+Le namespace d'une variable est déterminé par **la responsabilité qui possède le contrat**, et non par l'exécutable qui la lit.
 
-Trois classes sont retenues :
+- les crates et contrats généralistes Khadhroony Solana utilisent `KS_*` ;
+- `kb-app-demo-desktop` et les futures crates réellement spécifiques au Bot utilisent `KB_*` pour leurs propres contrats ;
+- une variable d'un scénario Solana réutilisable reste donc `KS_*` même lorsqu'elle est consommée par `kb-app-demo-desktop` ;
+- les variables standard du système, de Cargo, de Rust ou d'un outil externe ne sont pas renommées artificiellement tant qu'elles ne deviennent pas un contrat de configuration du workspace.
 
-- `KS_SECRET_*` : secret absolu ; la valeur peut être utilisée côté backend mais ne doit jamais être loggée, sérialisée vers une surface publique, renvoyée par Tauri ni affichée en diagnostic, même en mode debug ;
-- `KS_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_*` 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.
+Chaque domaine possède les trois mêmes classes :
 
-Une variable appartenant au workspace qui ne commence pas par `KS_` est non conforme après migration. Les variables standard du système ou de dépendances externes ne sont pas reclassées artificiellement comme variables de configuration Khadhroony.
+- `KS_SECRET_*` / `KB_SECRET_*` : secret absolu ; la valeur peut être utilisée côté backend mais ne doit jamais être loggée, sérialisée vers une surface publique, renvoyée par Tauri ni affichée en diagnostic, même en mode debug ;
+- `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.
 
-La classification d'une valeur sensible doit survivre à la substitution. Une chaîne composée contenant une valeur issue de `KS_SECRET_*` reste sensible dans son ensemble et ne doit pas redevenir une simple valeur publiable après résolution.
+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_*`.
+
+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
 
@@ -67,7 +72,7 @@ D'autres documents spécialisés ne sont créés que si l'audit démontre une re
 
 La conception doit distinguer :
 
-1. la représentation source, qui peut contenir des références `${KS_*}` ;
+1. la représentation source, qui peut contenir des références `${KS_*}` ou `${KB_*}` selon le propriétaire du contrat ;
 2. la représentation runtime résolue, qui peut porter des secrets ;
 3. la représentation publique/diagnostique, construite explicitement et incapable d'exposer une valeur secrète résolue.
 
@@ -111,7 +116,7 @@ La migration `kb_sol_*` → `k_sol_*` doit être traitée avec les contrats temp
 
 ## 8. Ordre des migrations
 
-- `0.5.1` : crates `ks-*`, identifiants Rust `ks_*`, variables `KS_*`, identités runtime/persistées Khadhroony Solana et restructuration sûre de la configuration/logging ;
+- `0.5.1` : crates `ks-*`, identifiants Rust `ks_*`, variables `KS_*` pour Solana avec `KB_*` réservé aux contrats Bot, identités runtime/persistées Khadhroony Solana et restructuration sûre de la configuration/logging ;
 - `0.5.2` : restructuration de `ks-wallet` sur la nouvelle fondation de configuration ;
 - `0.5.3` : normalisation de `ks-store`, y compris migration du préfixe SQL vers `k_sol_*` et contrats temporels/provenance ;
 - `0.5.4` : centralisation finale des scénarios dans `ks-pipeline-demo-scenarios` et audit de complétude des exécuteurs/validations.