0.5.0-pre.002

docs/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/README.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # Documentation active de Khadhroony Bot3
 
@@ -103,6 +103,7 @@ Les preuves détaillées de `0.4.8-pre.*` restent accessibles sous `../olddocs/a
 ## 10. Plans de version actifs
 
 - [`Plan 0.5.0 — cadrage de la fondation 0.5.x`](plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md) : plan temporaire actif créé pendant `0.5.0-pre.001`, à maintenir jusqu’à la clôture de `0.5.0`.
+- [`Audit 0.5.0-pre.002 — configuration, logging, wallet et namespaces`](plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md) : décisions de sécurité, split logging, namespace `KS_*`, migration wallet et audit du possible préfixe de crates `ks-*`.
 
 Le plan `0.4.8` reste archivé sous `../olddocs/archivekbot3/docs/plans/`.
 

docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan `0.5.0` — cadrage de la fondation `0.5.x`
 
@@ -11,7 +11,9 @@ Ce document est le livrable principal de `0.5.0-pre.001`.
 
 Le plan reste temporaire pendant le développement de `0.5.0`. Il doit être maintenu à chaque prerelease, puis archivé sous `olddocs/archivekbot3/` lors de la dernière prerelease, après transfert des décisions durables vers le ROADMAP, les règles, les guides et les documents de crates appropriés.
 
-**État de `pre.001` : plan proposé, à valider avant toute restructuration importante.**
+**État de `pre.001` : plan validé.**
+
+**État de `pre.002` : audit config/logging/wallet effectué ; les décisions détaillées sont consignées dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md). Aucune restructuration fonctionnelle n'est encore appliquée.**
 
 ## 2. Base `0.4.8` à préserver
 
@@ -75,7 +77,9 @@ Le split futur ne doit pas être traité comme un simple déplacement de fichier
 
 `kb-config` et `kb-logging` possèdent actuellement des structures presque identiques `LoggingConfig`, `LogTargetConfig` et `LogTargetFilterConfig`. Le desktop les convertit manuellement dans `app_state.rs`.
 
-Cette duplication confirme l'existence d'une frontière à auditer en `0.5.1`, mais `pre.001` ne décide pas encore si le contrat source, le contrat runtime ou un adaptateur intermédiaire doit devenir canonique. La décision doit respecter la direction des dépendances du workspace et éviter de coupler `kb-config` au runtime de logging par commodité.
+`pre.002` confirme que le logging doit devenir un document et un schéma distincts de la configuration généraliste. Les profils logging doivent pouvoir évoluer indépendamment des profils réseau/applicatifs et la conversion manuelle du desktop doit disparaître lors de `0.5.1`.
+
+La propriété exacte du DTO source logging doit encore respecter la direction des dépendances : `kb-config` ne doit pas dépendre du runtime `kb-logging` par commodité. `0.5.1` devra choisir un propriétaire unique du contrat source et éviter une nouvelle crate si elle ne représente pas une responsabilité autonome.
 
 ### 5.3 `kb-wallet`
 
@@ -211,26 +215,35 @@ Ces écarts doivent être corrigés dans une prerelease documentaire de `0.5.0`
 
 ## 8. Préparation de `0.5.1` — `kb-config`
 
-### Questions à fermer avant code
+### Décisions fermées par `pre.002`
 
-1. Quel contrat sépare configuration source, configuration runtime résolue et vue publique redacted ?
-2. Le logging doit-il être un fichier distinct, un sous-document distinct ou seulement un schéma distinct ?
-3. Qui est propriétaire du shape source logging et qui est propriétaire du shape runtime ?
-4. Comment migrer l'actuel fichier unique sans casser les profils existants ?
-5. Quelles valeurs sont des secrets explicites et quelles valeurs peuvent en contenir indirectement, par exemple une URL ?
-6. Comment interdire une sérialisation accidentelle d'un secret résolu ?
-7. Quels types ont réellement besoin d'être exportés via TS-RS ?
+- toutes les variables d'environnement propres au projet devront utiliser le namespace `KS_*` ;
+- `KS_SECRET_*` est strictement non exposable, y compris en debug/diagnostic ;
+- `KS_PUBLIC_*` est seulement candidate à une exposition explicitement autorisée par un DTO public ;
+- autre `KS_*` reste interne et n'est visible que par un diagnostic explicite et borné ;
+- toute valeur composée contenant un secret hérite de la classification `Secret` ;
+- la configuration source, la configuration runtime résolue et les DTO publics/diagnostics doivent être des frontières distinctes ;
+- le logging doit être extrait dans un document et un schéma JSON indépendants ;
+- le profil logging doit pouvoir évoluer indépendamment du profil généraliste ;
+- la conversion manuelle `kb-config` -> `kb-logging` actuellement située dans le desktop doit disparaître ;
+- le renommage éventuel des crates `kb-*` -> `ks-*` doit être décidé transversalement avant de figer les nouveaux noms de types, chemins de bindings et exemples.
+
+L'audit a recensé 84 noms d'environnement actifs ou de fixture dans le code/configuration de référence : 67 `KB_*` et 17 sans namespace cible. La migration exacte est détaillée dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md).
 
 ### Critères d'acceptation préparés
 
-- compatibilité ou migration explicite du format `0.4.8` ;
-- schémas JSON distincts et synchronisés si la frontière est retenue ;
+- migration explicite du format `0.4.8` vers les documents séparés ;
+- schémas JSON général et logging distincts et synchronisés avec leurs modèles ;
+- table exhaustive ancien nom d'environnement -> nouveau nom `KS_*` ;
+- refus des variables Khadhroony hors namespace `KS_*` après migration ;
 - tests des profils, defaults, validations croisées et erreurs ;
-- tests `.env`, `.env.local`, placeholders et fallbacks ;
-- canaris secrets absents de tous les payloads publics, logs et erreurs ;
+- tests `.env`, fichier dotenv sélectionné, placeholders et fallbacks ;
+- canaris `KS_SECRET_*` absents de tous les payloads publics, logs, diagnostics et erreurs ;
 - suppression du payload frontend de configuration résolue complète ;
+- aucun élargissement automatique de la surface publique uniquement parce que la build est debug ;
 - adaptation explicite de `kb-logging`, transport, pipeline, scénarios et desktop ;
 - aucune dépendance de `kb-store` vers `kb-config` ;
+- tests d'API externe de la façade `kb-config` avant changement structurel ;
 - documentation et exemples alignés.
 
 ## 9. Préparation de `0.5.2` — `kb-wallet`
@@ -345,16 +358,20 @@ Critère de sortie : plan complet et **validation explicite du plan avant toute
 
 ### `0.5.0-pre.002` — audit config/logging/wallet et contrats de sécurité
 
-Livrables prévus :
+Livrables réalisés :
 
-- inventaire exhaustif des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ;
-- audit de tous les chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ;
+- inventaire des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ;
+- audit des chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ;
+- confirmation du split logging en document + schéma indépendants ;
+- définition de la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` et de la propagation de sensibilité ;
+- inventaire de 84 contrats d'environnement actifs ou de fixture à migrer ;
 - audit des tests TS-RS et tests d'API externe manquants ;
 - caractérisation du format de configuration `0.4.8` et du format wallet `0.4.8` ;
 - dossier de migration `0.5.1` et `0.5.2` avec compatibilité, rollback et critères de non-divulgation ;
-- correction des documents de configuration rendus faux par l'audit, sans appliquer encore le nouveau format.
+- ouverture de l'audit transversal sur un éventuel namespace de crates `ks-*`, sans renommage prématuré ;
+- correction des documents de configuration rendus faux ou dangereux par l'audit, sans appliquer encore le nouveau format.
 
-Critère de sortie : aucune ambiguïté sur les frontières source/runtime/public de la configuration ni sur le contrat de migration wallet.
+Critère de sortie : frontières source/runtime/public fermées, namespace d'environnement cible défini, split logging confirmé et contrat de migration wallet borné. Le possible renommage de crates reste une décision transversale à fermer avant l'implémentation structurelle.
 
 ### `0.5.0-pre.003` — audit store/scénarios/desktop et contrats de préparation
 
@@ -467,6 +484,8 @@ Ne jamais lancer directement les scripts npm de développement ou build. Les com
 - les six surfaces ont un audit suffisamment précis pour leurs versions propriétaires ;
 - les contrats publics et formats persistés à migrer sont inventoriés ;
 - le chemin de fuite de configuration résolue est explicitement attribué à `0.5.1` avec critères de non-divulgation ;
+- le namespace d'environnement `KS_*` et les classes `Secret/Public/Internal` sont documentés avec propagation de sensibilité ;
+- le split logging en document et schéma indépendants est retenu comme cible de `0.5.1` ;
 - le format wallet `0.4.8` et ses exigences de migration sont documentés ;
 - le vocabulaire temporel/provenance/idempotence du store est défini avant tout schéma trading ;
 - la méthode d'audit decoder/executor/scenario/validation de `0.5.4` est fermée ;

docs/plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md

@@ -0,0 +1,380 @@
+<!-- file: docs/plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md -->
+<!-- version: 1 -->
+
+# Audit `0.5.0-pre.002` — configuration, logging, wallet et namespaces
+
+## 1. Objet
+
+Ce document complète le plan temporaire [`V0_5_0_FOUNDATION_0_5_X_PLAN.md`](V0_5_0_FOUNDATION_0_5_X_PLAN.md) avec l'audit approfondi prévu pour `0.5.0-pre.002`.
+
+Cette prerelease reste **non structurelle** : elle ferme les contrats à préparer pour `0.5.1` et `0.5.2`, mais ne scinde pas encore les fichiers de configuration, ne change pas les noms de variables d'environnement utilisés par le runtime, ne modifie pas le format wallet persistant et ne renomme aucune crate.
+
+## 2. Décisions de cadrage fermées
+
+### 2.1 Namespace des variables d'environnement
+
+Toutes les variables d'environnement appartenant à Khadhroony/Solana devront obligatoirement commencer par `KS_`.
+
+La convention cible comporte trois niveaux :
+
+- `KS_SECRET_*` : secret absolu, utilisable uniquement côté backend et jamais exposé, sérialisé, loggé ou inclus en clair dans une erreur, y compris en mode debug ou diagnostic ;
+- `KS_PUBLIC_*` : valeur explicitement candidate à l'exposition publique, mais seulement lorsqu'un DTO public l'autorise ;
+- autre `KS_*` : valeur interne, non exposée en fonctionnement normal et consultable uniquement par un diagnostic explicite et borné.
+
+Aucune variable hors namespace `KS_*` ne doit être lue comme contrat propre au projet après migration. Le runtime ne doit jamais énumérer l'environnement du processus pour décider automatiquement ce qui est exposable.
+
+Le préfixe ne remplace pas la politique de type : une valeur `KS_PUBLIC_*` n'est pas envoyée au frontend si aucun DTO public ne l'autorise, et une valeur issue d'un champ sémantiquement secret reste secrète même si son nom est mal classé.
+
+### 2.2 Propagation de la sensibilité
+
+La résolution d'un placeholder ne doit plus perdre son origine de sécurité.
+
+Si une chaîne composée contient au moins une valeur `KS_SECRET_*`, la chaîne résolue complète devient secrète. Exemple :
+
+```text
+https://mainnet.helius-rpc.com/?api-key=${KS_SECRET_HELIUS_API_KEY}
+```
+
+Le résultat complet doit être traité comme secret. La même règle s'applique aux DSN PostgreSQL et à toute autre composition.
+
+Ordre de dominance prévu pour une valeur composée :
+
+```text
+Secret > Internal/DebugOnly > Public
+```
+
+Une représentation publique doit être construite explicitement à partir du runtime ; elle ne doit jamais provenir d'une sérialisation complète suivie d'une suppression opportuniste de champs.
+
+### 2.3 Split de la configuration logging
+
+Le split du logging n'est plus une question ouverte : `0.5.1` devra extraire le logging du document général dans **un document et un schéma JSON distincts**.
+
+La cible minimale est donc :
+
+- un document de configuration général ;
+- un document de configuration logging ;
+- un schéma JSON général ;
+- un schéma JSON logging.
+
+Les profils généralistes et les profils logging doivent pouvoir évoluer indépendamment. Un profil réseau ne doit plus contenir une copie complète de toutes les routes logging.
+
+D'autres documents spécialisés ne seront ajoutés que si l'audit de `0.5.1` démontre une responsabilité, une validation ou un cycle de vie suffisamment indépendant ; le split ne doit pas devenir une fragmentation systématique.
+
+## 3. État réel de la configuration `0.4.8`
+
+### 3.1 Taille et duplication
+
+`config/example.config.json` représente environ 154 Ko.
+
+Les trois profils actifs (`local_devnet`, `mainnet_research`, `mainnet`) embarquent chacun un bloc logging d'environ 23 à 24 Ko. Ensemble, ces blocs représentent environ **70 Ko** de configuration, soit une part disproportionnée du document général.
+
+Les trois blocs ont la même structure et diffèrent principalement par :
+
+- les noms de routes associés au profil ;
+- les chemins sous `logs/<profil>/...` ;
+- quelques valeurs de niveau ou de sélection liées au profil.
+
+La séparation du logging est donc justifiée à la fois par la lisibilité, la maintenance et la réduction du couplage entre profil réseau et politique de tracing.
+
+### 3.2 Contrat public actuel
+
+`kb-config::ProfileConfig` contient directement :
+
+```text
+app
+logging
+database
+data
+solana
+wallet
+execution
+demo
+```
+
+`AppConfig`, `ProfileConfig` et toutes les sous-structures sont actuellement `Clone + Debug + Serialize + Deserialize + TS`.
+
+Les fonctions publiques `serialize_config_json` et `serialize_config_json_pretty` peuvent sérialiser la configuration runtime complète. Après résolution d'environnement, cette configuration peut contenir des secrets en clair.
+
+`DemoConfigPayload` clone aujourd'hui `AppConfig` et `ProfileConfig` complets et le frontend les affiche intégralement dans des JSON viewers avec copie activée. Cette surface doit disparaître dans `0.5.1` au profit d'un DTO public explicitement borné.
+
+### 3.3 Consommateurs actuels
+
+L'audit des onze crates confirme les principaux couplages suivants :
+
+- `AppConfig` est consommé directement par le desktop et `kb-pipeline-demo-scenarios` ;
+- `ProfileConfig` traverse le desktop, `kb-onchain-transport`, `kb-pipeline-demo-scenarios` et certaines fixtures/tests de `kb-pipeline` ;
+- les types logging de `kb-config` ne sont convertis vers `kb-logging` que par le desktop aujourd'hui ; cette conversion constitue donc un adaptateur applicatif accidentel à supprimer ;
+- `kb-wallet` est consommé principalement par `kb-pipeline-demo-scenarios` et quelques adaptations desktop ; les scénarios utilisent directement `TemporaryWallet`, `TemporaryWalletStore`, `WalletAlias`, `WalletSummary`, `as_signer()` et `as_sync_signer()`.
+
+Cette concentration permet de préparer des migrations bornées, mais `ProfileConfig` reste suffisamment diffus pour interdire un changement de shape sans phase de compatibilité/test.
+
+### 3.4 Résolution d'environnement actuelle
+
+`resolve_environment_placeholders` :
+
+- accepte n'importe quel nom dans `${NAME}` ;
+- lit directement `std::env::var(name)` ;
+- retourne une `String` ordinaire ;
+- ne conserve ni origine, ni visibilité, ni indicateur de secret ;
+- peut donc transformer une URL ou un DSN contenant un secret en simple chaîne indistinguable d'une valeur publique.
+
+Le futur resolver devra refuser les variables de projet hors namespace `KS_*` et conserver suffisamment de métadonnées pour empêcher la perte de sensibilité.
+
+## 4. Inventaire des contrats d'environnement
+
+L'audit du code, de `config/example.config.json`, de `.env.example` et des fichiers de fixture `.env` Token-2022 trouve **84 noms de variables/entrées de type environnement actuellement utilisés comme contrats actifs ou de fixture** :
+
+- 67 commencent par `KB_` ;
+- 17 ne commencent ni par `KB_` ni par `KS_` ;
+- aucune n'utilise encore le namespace cible `KS_`.
+
+Les variables non conformes comprennent notamment :
+
+- `HELIUS_API_KEY` ;
+- les familles `TOKEN_2022_*` ;
+- des entrées de fixture ElGamal/validity proof.
+
+Les guides opérateur contiennent en plus des variables shell historiques qui devront être réconciliées avec la même règle lors de la migration documentaire.
+
+### 4.1 Secrets certains
+
+Les contrats suivants doivent devenir explicitement secrets :
+
+- `HELIUS_API_KEY` -> cible de famille `KS_SECRET_HELIUS_*` ;
+- `KB_POSTGRES_MAINNET_URL` -> cible `KS_SECRET_POSTGRES_MAINNET_URL` ;
+- `KB_POSTGRES_DEVNET_URL` -> cible `KS_SECRET_POSTGRES_DEVNET_URL` ;
+- `KB_POSTGRES_TEST_URL` -> cible `KS_SECRET_POSTGRES_TEST_URL`.
+
+Une URL ou un DSN complet contenant l'un de ces secrets hérite de la classification `Secret` après résolution.
+
+### 4.2 Variables internes
+
+Les sélecteurs de profil, chemins, opt-ins de tests, confirmations opérateur, paramètres de campagnes et valeurs de fixture ne doivent pas être promus artificiellement en `KS_PUBLIC_*`. Par défaut, ils deviennent des `KS_*` internes.
+
+`KS_PUBLIC_*` doit rester réservé aux valeurs dont une exposition publique est réellement requise et testée.
+
+### 4.3 Migration
+
+`0.5.1` devra fournir une table de migration exhaustive ancien nom -> nouveau nom avant changement du runtime et de `.env.example`.
+
+La migration ne doit pas laisser le code lire durablement les anciens alias `KB_*`, `TOKEN_2022_*` ou `HELIUS_API_KEY`, car cela contredirait la règle du namespace unique. Si une compatibilité transitoire est nécessaire pendant une prerelease de migration, elle doit être explicitement bornée, détecter les conflits et être supprimée avant clôture de la version propriétaire.
+
+## 5. Frontières source / runtime / public
+
+Le futur contrat de `0.5.1` doit distinguer trois représentations conceptuelles.
+
+### 5.1 Source
+
+La représentation source conserve les documents utilisateur, les placeholders et les valeurs non résolues nécessaires à la validation/migration.
+
+Elle ne doit pas être confondue avec un objet sûr à afficher.
+
+### 5.2 Runtime
+
+La représentation runtime contient les valeurs effectivement utilisables par les consommateurs backend.
+
+Elle peut contenir des secrets résolus et ne doit donc pas dériver automatiquement une surface de sérialisation/TS-RS générale. Les champs sensibles connus doivent être encapsulés ou accompagnés d'une classification qui empêche `Debug`, sérialisation ou erreur accidentelle.
+
+### 5.3 Public/diagnostic
+
+Les DTO publics sont construits explicitement à partir du runtime :
+
+- vue publique normale : uniquement les champs autorisés et valeurs `KS_PUBLIC_*` nécessaires ;
+- diagnostic explicite : peut ajouter des valeurs `KS_*` internes sélectionnées ;
+- secrets : jamais de valeur, uniquement un état non secret tel que `configured: true` lorsque cela apporte une valeur opérateur.
+
+Le simple fait qu'une build Rust utilise `debug_assertions` ne doit pas élargir automatiquement la surface Tauri.
+
+## 6. Propriété du contrat logging
+
+### 6.1 Duplication actuelle
+
+`kb-config` et `kb-logging` exposent chacun :
+
+- `LoggingConfig` ;
+- `LogTargetConfig` ;
+- `LogTargetFilterConfig`.
+
+Leurs champs sont pratiquement identiques. `kb-app-demo-desktop/src/app_state.rs` effectue une conversion champ par champ avant `kb_logging::init_logging`.
+
+`kb-logging::LogFileRoute` n'a aucun consommateur actif hors de `kb-logging` et constitue un contrat legacy à réévaluer pendant la migration.
+
+### 6.2 Direction de dépendance à préserver
+
+`kb-config` ne doit pas dépendre du runtime logging simplement pour réutiliser ses types.
+
+La solution de `0.5.1` devra choisir un propriétaire unique du contrat source logging et supprimer la conversion manuelle du desktop. Deux solutions restent architecturalement acceptables avant implémentation :
+
+1. `kb-config` possède le DTO source logging séparé et `kb-logging` le consomme directement ou via un adaptateur propriétaire du runtime ;
+2. une frontière de configuration logging est déplacée dans une surface dédiée sans faire dépendre la configuration générale de l'initialisation `tracing`.
+
+Le choix final doit minimiser la duplication sans réintroduire une crate artificielle si elle n'apporte pas de responsabilité autonome.
+
+## 7. Audit `kb-wallet`
+
+### 7.1 Points déjà solides
+
+Le wallet actuel protège correctement plusieurs frontières :
+
+- `TemporaryWallet` ne dérive ni `Serialize` ni `Clone` ;
+- son implémentation `Debug` n'affiche que l'alias, la clé publique et le chemin ;
+- les octets du keypair restent privés ;
+- les buffers temporaires de lecture/écriture sont zeroized ;
+- les fichiers existants ne sont pas écrasés ;
+- les liens symboliques et permissions trop ouvertes sont refusés ;
+- `as_signer()` et `as_sync_signer()` fournissent la capacité de signature sans exposer les octets.
+
+### 7.2 Contrat persistant à migrer
+
+Le format `0.4.8` est un contrat réel :
+
+```text
+<alias>.json
+```
+
+contient le tableau JSON standard du keypair Solana, sans enveloppe de version et sans chiffrement applicatif.
+
+`0.5.2` devra donc traiter ce format comme **legacy importable**, et non le modifier in-place sans stratégie.
+
+### 7.3 Exigences de migration `0.5.2`
+
+Avant implémentation, le design devra préciser :
+
+- format versionné du nouveau conteneur ;
+- détection sûre du format legacy ;
+- import sans perte de clé publique ;
+- écriture atomique du nouveau format avant suppression éventuelle de l'ancien ;
+- rollback après échec ;
+- corruption et mauvais secret de déverrouillage ;
+- séparation identité / secret / état verrouillé / capacité de signer ;
+- absence de secret dans config, logs, erreurs, Tauri et backup metadata ;
+- politique d'import/export et sauvegarde/restauration si ces capacités sont retenues.
+
+Aucun mot de passe ou matériau de déchiffrement ne devra être stocké dans la configuration générale. Une automatisation non interactive éventuelle devra utiliser une source secrète dédiée, classée `KS_SECRET_*`.
+
+## 8. Tests d'API externe manquants
+
+Le workspace possède des tests d'API externe pour `kb-lib`, `kb-pipeline` et une partie de `kb-pipeline-demo-scenarios`, mais aucun dossier `tests/` équivalent pour `kb-config`, `kb-logging` ou `kb-wallet`.
+
+Avant les refactors propriétaires, il faudra ajouter des tests de caractérisation externes couvrant au minimum :
+
+### `kb-config`
+
+- chargement du format `0.4.8` de référence ;
+- profil actif et invariants publics ;
+- contrat de schéma embarqué ;
+- migration vers les documents séparés ;
+- refus des variables de projet hors `KS_*` ;
+- canaris `KS_SECRET_*` absents de toute vue publique, erreur et diagnostic.
+
+Ces tests ne doivent pas figer la sérialisation dangereuse actuelle d'une configuration résolue complète.
+
+### `kb-logging`
+
+- initialisation depuis le futur contrat source canonique ;
+- conservation des routes/niveaux/filtres/formats ;
+- migration sans dépendance au desktop.
+
+### `kb-wallet`
+
+- lecture d'une fixture legacy `0.4.8` ;
+- identité de clé publique après migration ;
+- corruption, permissions et atomicité ;
+- absence de secret dans `Debug` et surfaces publiques ;
+- tests de lock/unlock seulement après choix du format chiffré.
+
+## 9. Audit du possible renommage `kb-*` -> `ks-*`
+
+La demande de namespace `KS_` pour l'environnement ouvre légitimement la question du nom des crates généralistes. Cette question ne doit cependant pas être traitée par remplacement global.
+
+### 9.1 Crates candidates
+
+Les responsabilités actuelles rendent les crates suivantes plausiblement généralistes Solana et donc candidates à un préfixe `ks-*` si le renommage est retenu :
+
+- `kb-core` ;
+- `kb-config` ;
+- `kb-lib` ;
+- `kb-logging` ;
+- `kb-program-ids` ;
+- `kb-pipeline` ;
+- `kb-onchain-transport` ;
+- `kb-store` ;
+- `kb-wallet`.
+
+`kb-pipeline-demo-scenarios` doit être classée séparément : sa logique est réutilisable et non spécifique au frontend, mais son rôle de validation/scénarios peut justifier un nom différent de la simple substitution de préfixe.
+
+`kb-app-demo-desktop` reste clairement une application Khadhroony Bot et n'est pas candidate au même renommage automatique.
+
+### 9.2 Namespaces à ne pas confondre
+
+Un éventuel renommage de packages Cargo touche plusieurs espaces de noms distincts :
+
+1. nom de répertoire ;
+2. nom `[package]` Cargo ;
+3. identifiant Rust (`kb_config` -> éventuellement `ks_config`) ;
+4. chemins TS-RS/bindings ;
+5. targets `tracing` ;
+6. noms de binaires/CLI ;
+7. identités persistées de décodeurs, matérialiseurs et exécuteurs ;
+8. préfixes SQL et noms de tables.
+
+Ces couches ne doivent pas être renommées en bloc.
+
+En particulier :
+
+- les tables `kb_sol_*` sont des contrats SQL publiés et ne doivent pas changer de nom du seul fait d'un renommage Cargo ;
+- les identités telles que `kb-lib.decoder.*`, `kb-lib.materializer.*` et `kb-lib.executor.*` peuvent être persistées dans le ledger, les événements ou les clés d'idempotence ; leur changement exige un audit de migration propre ;
+- les targets `tracing` peuvent être renommés séparément, mais cela impose une migration du document logging et de ses filtres.
+
+### 9.3 Décision à prendre avant implémentation structurelle
+
+Avant de lancer `0.5.1`, la clôture de `0.5.0` devra statuer sur l'une des stratégies suivantes :
+
+- conserver `kb-*` comme namespace historique pour toutes les crates ;
+- renommer uniquement les packages/libs réellement généralistes en `ks-*`, en laissant les applications `kb-*` ;
+- planifier un chantier de renommage dédié dans le ROADMAP si l'impact est trop transversal pour être absorbé proprement par `0.5.1`.
+
+Aucun renommage n'est livré par `pre.002`.
+
+## 10. Dossier de migration préparé pour `0.5.1`
+
+`0.5.1` devra au minimum :
+
+1. introduire le namespace `KS_*` et la classification Secret/Public/Internal ;
+2. fournir la table exhaustive de renommage des variables actuelles ;
+3. remplacer le resolver non typé par une résolution conservant la sensibilité ;
+4. séparer la configuration générale et la configuration logging en deux documents et deux schémas ;
+5. supprimer `logging` de chaque `ProfileConfig` généraliste ;
+6. rendre la sélection du profil logging indépendante du profil général ;
+7. supprimer la duplication de types logging ou la conversion manuelle desktop ;
+8. séparer source, runtime et DTO publics/diagnostics ;
+9. retirer `AppConfig`/`ProfileConfig` complets des payloads Tauri ;
+10. ajouter les tests de migration `0.4.8` -> nouveau format et les canaris de non-divulgation.
+
+Le détail des noms de fichiers et types Rust sera fixé dans la première prerelease d'implémentation de `0.5.1`, après décision sur le namespace de crates.
+
+## 11. Dossier de migration préparé pour `0.5.2`
+
+`0.5.2` devra :
+
+1. caractériser le format legacy `0.4.8` par fixture externe ;
+2. définir un conteneur wallet versionné avant chiffrement ;
+3. séparer identité, secret, état de verrouillage et capacité de signer ;
+4. définir migration/rollback atomiques ;
+5. conserver les capacités `Signer` nécessaires aux exécuteurs sans exposer le secret ;
+6. interdire toute propagation de secret vers config/logging/Tauri ;
+7. ajouter import/export, backup/restore et multi-wallet uniquement avec contrats de sécurité et tests correspondants.
+
+## 12. Critère de sortie de `pre.002`
+
+La prerelease peut être considérée comme cadrée lorsque :
+
+- le split logging document + schéma séparés est accepté comme cible ;
+- la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` est normative pour la migration ;
+- la propagation de sensibilité des valeurs composées est requise ;
+- les surfaces source/runtime/public sont distinctes ;
+- le format wallet legacy et sa stratégie de migration sont explicitement bornés ;
+- les tests externes manquants sont identifiés ;
+- le possible renommage `kb-*` -> `ks-*` est isolé comme décision transversale, sans toucher les identités persistées ou SQL par accident.
+
+La prochaine prerelease prévue reste `0.5.0-pre.003`, consacrée à `kb-store`, aux scénarios et au desktop.