@@ -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.
La configuration est organisée autour de compositions propres aux binaires et de documents spécialisés réutilisables. Un binaire choisit les fichiers partagés et les profils dont il a besoin au lieu de recopier une configuration monolithique.
La configuration sépare les responsabilités Solana partagées des choix propres aux binaires. Les documents spécialisés sont autonomes grâce à leurs valeurs globales et à leur `default_profile`; une composition de binaire ne fournit que les overrides nécessaires.
## Fichiers actifs
## Documents actifs
Compositions :
Composition actuelle :
-`config/kb-app-demo-desktop.default.config.json` : composition par défaut du desktop ;
-`config/ks-pipeline-demo-scenarios.default.config.json` : composition par défaut du CLI/scénarios.
-`config/kb-app-demo-desktop.default.config.json` : composition par défaut du desktop.
-`config/schemas/resolved.app.config.schema.json` pour le contrat runtime reconstruit.
Chaque document possède un exemple `example.*.config.json`. Les schémas correspondants résident sous `config/schemas/`.
`.env`, ou le fichier sélectionné par `KS_ENV_FILE`, fournit les valeurs non versionnées.
## Defaults partagés
Chaque document spécialisé définit un `default_profile`. Lorsqu'aucune composition n'est fournie, `ks-config` combine les defaults propres à transport, listeners, store, wallet et execution ; les noms de ces profils n'ont pas besoin d'être identiques. Une composition sélectionne des sources et profils, mais ne duplique pas des paramètres arbitraires : les overrides fins restent dans le schéma propriétaire et les globals explicitement configurables passent par leur variable d'environnement dédiée.
Cette règle permet à une bibliothèque, un scénario ou un futur worker d'utiliser une configuration cohérente sans créer un fichier de composition uniquement pour répéter les choix par défaut.
## Composition d'un binaire
Une composition définit :
1. son `active_profile` ;
1. son `active_profile` applicatif ;
2. les chemins des documents partagés ;
3.pour chaque profil, le `logging_profile`, `transport_profile` et `listeners_profile` à sélectionner ;
4.temporairement, les sections qui n'ont pas encore leur document spécialisé.
3.les éventuels overrides de profils spécialisés ;
4.les paramètres propres au binaire qui ne relèvent pas d'un document partagé.
Les `active_profile` propres aux documents partagés restent utiles lorsqu'ils sont chargés seuls. Dans une composition, la référence explicite du binaire prime.
`ks-config` charge les fichiers référencés, valide leurs schémas/types et refuse une composition qui référence un profil inexistant.
## Desktop
@@ -70,65 +74,100 @@ Le chemin de composition du desktop peut être remplacé par :
KB_APP_DEMO_DESKTOP_CONFIG_PATH
```
Le logging conserve l'override opérationnel :
Le logging conserve aussi l'override opérationnel :
```text
KS_LOGGING_CONFIG_PATH
```
Sans cet override, le desktop utilise le chemin logging déclaré par sa composition.
## Scénarios Devnet
Les scénarios opt-in utilisent :
Par défaut, `ks-pipeline-demo-scenarios` utilise directement les defaults des documents partagés. Il n'existe plus de `config/ks-pipeline-demo-scenarios.default.config.json` obligatoire.
KS_DEVNET_PROFILE # sélection d'un profil runtime compatible Devnet
```
`KS_DEVNET_CONFIG_PATH` désigne désormais un fichier de composition. Sans override, les scénarios utilisent `config/ks-pipeline-demo-scenarios.default.config.json`.
## Valeurs hors profils
## Transport
Les paramètres globaux ne doivent pas être dupliqués dans chaque profil.
`transport.config.json` possède les endpoints HTTP et WebSocket ainsi que leurs rôles et limites. Le profil transport peut être consommé directement par `ks-onchain-transport` sans dépendre d'un profil applicatif complet.
### Logging
Cela prépare les futurs workers : un worker de capture pourra sélectionner un profil transport différent du desktop tout en partageant le même document.
```text
logs_directory = ${KS_LOGS_DIRECTORY:-logs}
```
## Listeners
Les chemins de fichiers des targets sont relatifs à cette racine lorsqu'ils ne sont pas absolus.
`listeners.config.json` contient les déclarations de subscriptions par logs, programme et compte. Un profil listeners peut être associé à n'importe quel profil transport compatible par le fichier de composition du consommateur.
### Wallet
La séparation évite de recopier les listes de `program_id` et les filtres lorsque plusieurs binaires observent la même surface Solana.
Chaque profil wallet ne contient plus qu'un chemin relatif et ses paramètres d'identité/persistance.
`logging.config.json` appartient à `ks-logging`. Une composition référence son fichier et son profil, mais les types et validations logging ne reviennent pas dans `ks-config`.
## Transport WebSocket
## Contrat runtime résolu
Les paramètres communs d'un type d'endpoint WebSocket sont définis dans `ws_endpoint_defaults`. Chaque endpoint choisit une classe de defaults et peut écraser individuellement :
Pendant la migration `0.5.1`, `ks-config` reconstruit encore un `AppConfig/ProfileConfig` contenant les sections nécessaires aux consommateurs existants. Ce contrat est une projection runtime, pas une configuration source.
-`connect_timeout_ms` ;
-`request_timeout_ms` ;
-`unsubscribe_timeout_ms` ;
-`write_channel_capacity` ;
-`event_channel_capacity` ;
-`auto_reconnect`.
Les tests de compatibilité utilisent les fixtures sous `test-fixtures/config/`. Aucun binaire ne doit charger ces fixtures en production.
Les classes actuelles couvrent le RPC WS standard et le RPC WS à capacité plus élevée. Une future surface Helius avancée devra avoir son propre contrat/default lorsqu'elle sera réellement implémentée.
## Étapes suivantes
## Store
Le prochain split doit extraire :
`store.config.json` porte les paramètres PostgreSQL/SQLite. Ce déplacement ne change aucune table ni migration SQL ; la normalisation SQL reste réservée à `0.5.3`.
- database vers le document store ;
-`logs_directory` vers logging ;
-`wallets_directory`, le stockage wallet et les paramètres de wallet vers un document wallet ;
- les permissions `*_send_enabled` du wallet vers la politique execution ;
- execution ;
- configuration spécifique au desktop.
## Wallet et politique d'exécution
Après cette étape seulement, les DTO publics, diagnostics et règles de camouflage seront construits sur les nouvelles frontières.
Les propriétés de stockage/identité du wallet appartiennent à `wallet.config.json`.
Les autorisations :
```text
localnet_send_enabled
devnet_send_enabled
testnet_send_enabled
mainnet_send_enabled
```
appartiennent à `execution.config.json`, avec les limites de dépense, frais, simulation et confirmation. Un wallet sait signer ; la politique d'exécution décide si une soumission est autorisée.
## Contrat runtime transitoire
Pendant `0.5.1`, `ks-config` reconstruit encore `AppConfig/ProfileConfig` afin de préserver les consommateurs existants. Il s'agit d'une projection runtime, pas d'un document source.
Les fixtures de compatibilité sont sous `test-fixtures/config/`. Elles ne doivent pas être chargées en production.
## Frontière TS-RS
L'audit `pre.007` confirme que le frontend du desktop n'importe directement aucun binding généré depuis `ks-config` ou `ks-lib`. Les dérivations TS-RS des crates généralistes seront donc réévaluées dans la prerelease suivante : les DTO réellement destinés à Tauri doivent être définis/wrappés dans l'application, sauf contrat TypeScript générique explicitement justifié.
Le document logging reste indépendant de la composition binaire. Une composition `<binary>.default.config.json` sélectionne explicitement le profil logging qu’elle veut utiliser ; le `active_profile` propre à `logging.config.json` reste disponible pour les consommateurs autonomes.
## Contrat JSON
Le schéma est `config/schemas/logging.config.schema.json`. Les exemples sont `config/logging.config.json` pour la configuration runtime de référence et `config/example.logging.config.json` pour un exemple minimal.
Une route définit notamment :
- sink console ou fichier ;
- niveau minimal ;
- format humain, compact, pretty ou JSON ;
- rotation ;
- targets exactes ou préfixes ;
- activation ANSI.
Les routes fichier ne doivent jamais écrire de secrets ou de keypairs.
## Nomenclature des targets
Les targets suivent les conventions du workspace, par exemple :
Pour un matérialisateur, la target de tracing reste distincte du `processorName` persisté.
Les targets fichier utilisent des chemins relatifs, par exemple `devnet/ks-pipeline/debug.log`. `ks-logging` les résout sous `logs_directory` au chargement. Une valeur absolue explicite reste absolue.
## Frontend desktop
Cette séparation évite de recopier `logs/` dans chaque profil et permet à l'opérateur de déplacer tous les logs par variable d'environnement ou `.env`.
Le desktop charge les documents app et logging séparément. Il ne convertit plus un type `ks_config::LoggingConfig` vers `ks_logging::LoggingConfig` : le type runtime est possédé directement par `ks-logging`.
## Sélection du profil
La surface publique de diagnostic/configuration reste volontairement inchangée jusqu’à `0.5.1-pre.006`, qui supprimera l’exposition des configurations résolues complètes.
`logging.config.json` définit `default_profile`. Un consommateur autonome l'utilise avec `default_logging_profile`.
## Diagnostic
Un binaire possédant une composition peut sélectionner un autre profil avec `logging_profile`; cette sélection ne modifie pas le document partagé.
- vérifier `KS_LOGGING_CONFIG_PATH` si le fichier par défaut n’est pas utilisé ;
- vérifier le profil logging actif indépendamment du profil app ;
- valider le document contre son schéma ;
- confirmer le niveau global et les filtres spécifiques ;
- vérifier les chemins et permissions des routes fichier ;
- ne pas réinitialiser le subscriber global pendant l’exécution.
## Flux de démarrage desktop
## Références
1. charger la composition `config/kb-app-demo-desktop.default.config.json` ;
2. résoudre le chemin `logging` référencé ;
3. charger `logging.config.json` ;
4. choisir l'override du profil ou son `default_profile` ;
5. résoudre les paths sous `logs_directory` ;
6. appeler `ks_logging::init_logging` ;
7. poursuivre l'initialisation du runtime.
-`ks-logging/README.md` ;
-`ks-logging/USAGE.md` ;
-`config/README.md` ;
-`docs/OPERATION_NAMING_CONVENTION.md`.
`KS_LOGGING_CONFIG_PATH` remplace le chemin du document et `KS_LOGS_DIRECTORY` remplace uniquement sa racine de sortie.
## Sécurité
Les logs ne doivent jamais exposer :
- une valeur `KS_SECRET_*` ou `KB_SECRET_*` ;
- un DSN avec credentials ;
- une clé privée/keypair ;
- une configuration runtime complète résolue.
Le masquage structurel et les DTO diagnostics sûrs sont finalisés dans la prochaine prerelease de `0.5.1`.
# Plan temporaire `0.5.1` — namespace Khadhroony Solana et configuration sûre
## 1. Statut et règle de cette prerelease
Ce document est le plan temporaire de `0.5.1`. `0.5.1-pre.001`a fermé l'inventaire et les contrats de migration. `0.5.1-pre.002` a renommé physiquement les dix crates Solana généralistes vers `ks-*` / `ks_*`. `0.5.1-pre.003` a migré les identités runtime et persistables hiérarchiques de `ks-lib`. `0.5.1-pre.004`migre maintenant les contrats d’environnement vers les namespaces d’ownership `KS_*` / `KB_*`, sans toucher au namespace SQL ni encore scinder les fichiers de configuration. `kb-app-demo-desktop` et le workspace racine restent nommés comme avant.
Ce document est le plan temporaire de `0.5.1`. Les prereleases `pre.001` à `pre.004`ont fermé l'inventaire puis migré crates, identités techniques et variables d'environnement. `pre.005` a séparé le logging, `pre.006` a introduit les compositions de binaires et extrait transport/listeners, et `pre.007`termine maintenant la décomposition des responsabilités partagées avec store/wallet/execution, valeurs globales hors profils et defaults autonomes. `kb-app-demo-desktop` et le workspace racine restent nommés comme avant.
La base `0.5.0-pre.004` puis `0.5.1-pre.001` ont été validées par `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, `python3 scripts/audit_rust_workspace_rules.py` et `cargo test --workspace`. `pre.002` a ensuite été acceptée après validation opérateur du renommage physique. `pre.003` a été acceptée après validation opérateur. `pre.004` doit rejouer les contrôles de référence, car les noms d’environnement sont consommés par les tests optionnels, les scénarios, le store, la configuration et le desktop.
Les contrôles Rust et le démarrage Tauri de `pre.006` ont été validés par l'opérateur le 10 août 2026. Le démarrage confirme le chargement de `kb-app-demo-desktop.default.config.json`, du document logging séparé, des profils transport et du store, avec DSN PostgreSQL masqué dans les logs. `pre.007` doit préserver le comportement runtime tout en changeant l'ownership source des paramètres.
## 2. Invariant du workspace racine
@@ -32,18 +32,18 @@ Les bibliothèques internes Solana utilisent `ks-*` / `ks_*` et leurs variables
`kb-app-demo-desktop` est adapté en dernier, mais garde son package, son répertoire et ses identifiants applicatifs.
@@ -58,18 +58,18 @@ bin : kb-pipeline-demo-scenarios-cli -> ks-pipeline-demo-scenarios-cli
Les valeurs suivantes sont des métriques d'orientation sur les fichiers actifs, hors archives et artefacts générés. Elles montrent qu'un renommage massif en une seule opération serait difficile à diagnostiquer.
La cible `KB_APP_DEMO_DESKTOP_CONFIG_PATH` remplace la transition `KS_CONFIG_PATH` de `pre.004` : une composition appartient au binaire qui la charge, alors que les documents qu’elle référence restent possédés par les crates `ks-*`.
## 8. Décomposition des documents de configuration
Le split `pre.005` a d'abord extrait le logging. L'audit suivant a confirmé que le document applicatif restant mélangeait encore des responsabilités ayant des cycles de vie et des consommateurs distincts. La cible devient donc une composition propre à chaque binaire, complétée par des documents spécialisés partageables.
Le split est désormais fondé sur deux niveaux complémentaires :
La convention de composition est :
1. chaque document spécialisé est autonome, possède ses valeurs globales et un `default_profile` ;
2. une composition `<binary>.default.config.json` n'existe que lorsqu'un binaire doit remplacer des fichiers/profils ou porter des paramètres propres à l'application.
Les documents partagés à l'issue de `pre.007` sont :
```text
config/logging.config.json
config/transport.config.json
config/listeners.config.json
config/store.config.json
config/wallet.config.json
config/execution.config.json
```
avec exemples sous `config/` et schémas source sous `config/schemas/`. Chaque composition sélectionne explicitement les profils logging, transport et listeners qu'elle consomme. Les `active_profile` propres aux documents spécialisés restent des valeurs de repli pour les consommateurs autonomes, mais ne couplent pas les sélections d'un binaire.
Le desktop conserve :
`AppConfig/ProfileConfig` demeure provisoirement un **contrat runtime résolu**, reconstruit par `ks-config`, afin de préserver les consommateurs pendant la migration. Son schéma est `config/schemas/resolved.app.config.schema.json` et ses fixtures de test sont sous `test-fixtures/config/`; il ne correspond plus à un document source chargé au démarrage.
```text
config/kb-app-demo-desktop.default.config.json
```
`pre.007` doit poursuivre la décomposition de `database/data`, wallet, execution et de la configuration réellement spécifique au desktop. À son terme, une composition doit principalement référencer des documents/profils spécialisés et une configuration dédiée au binaire, sans obliger `ks-config` à enregistrer la liste des futurs workers ou exécutables.
`ks-pipeline-demo-scenarios` n'a plus de composition dédiée par défaut. En absence de `KS_DEVNET_CONFIG_PATH`, il compose directement les `default_profile` indépendants des documents partagés. Un override explicite reste possible pour un besoin opérateur particulier.
Cette décomposition doit être terminée avant de figer les surfaces `public`/`diagnostic` et la propagation de sensibilité en `pre.008`.
Les valeurs non dépendantes d'un profil sont sorties des profils :
Les chemins relatifs de logs et de wallets sont résolus sous ces racines. Les autorisations `*_send_enabled` appartiennent désormais à `execution.config.json`, pas à `wallet.config.json`.
Le transport possède des classes WebSocket de defaults nommées. Chaque endpoint choisit une classe et peut fournir ses propres `overrides`; `auto_reconnect` appartient donc au transport et non à `AppSectionConfig`. Les classes actuelles couvrent uniquement les surfaces réellement présentes : RPC WS standard et RPC WS à capacité supérieure. Une future surface Helius avancée aura sa propre classe/contrat lorsqu'elle sera implémentée.
Lorsqu'une composition référence un profil, `ks-config` doit prouver son existence avant de construire le runtime. Lorsqu'aucune composition n'est fournie, les noms des `default_profile` n'ont pas besoin d'être identiques : chaque document est résolu indépendamment. La composition ne devient pas une seconde surface de paramètres : les overrides de champ restent dans le contrat spécialisé qui les possède, et les globals explicitement configurables utilisent leurs variables d'environnement dédiées.
`AppConfig/ProfileConfig` demeure provisoirement un **contrat runtime résolu** pour préserver les consommateurs pendant la migration. Les champs applicatifs `app`/`demo` restent dans la composition exclusive du desktop pendant cette transition ; leur ownership Rust/public est traité avec les DTO applicatifs de `pre.008`, sans réintroduire un document généraliste monolithique.
## 9. Source, runtime, public et diagnostic
@@ -640,7 +646,11 @@ Avant chaque changement structurel correspondant, conserver ou ajouter des tests
- l'interdiction des variables de configuration possédées par le workspace hors namespace d'ownership `KS_*` ou `KB_*` ;
- la propagation de sensibilité depuis `KS_SECRET_*` vers les valeurs composées ;
- l'impossibilité pour une sentinelle secrète d'apparaître dans `Debug`, logs, erreurs, payloads Tauri, sérialisation publique ou diagnostic ;
- la validation indépendante des schémas source de composition, logging, transport et listeners sous `config/schemas/` ;
- la validation indépendante des schémas source de composition, logging, transport, listeners, store, wallet et execution sous `config/schemas/` ;
- la résolution indépendante des `default_profile` sans supposer des noms identiques ;
- le refus des références de profils inexistants dans une composition ;
- le maintien de `logs_directory` et `wallets_directory` hors profils ;
- la résolution des classes de defaults WebSocket avant les overrides propres aux endpoints ;
- la validation du schéma `resolved.app.config.schema.json` uniquement comme contrat runtime transitoire ;
- l'indépendance des profils généralistes et logging ;
- l'absence de duplication structurelle des types logging entre `ks-config` et `ks-logging` ;
@@ -694,7 +704,7 @@ Les tests ne doivent pas figer comme comportement légitime la fuite actuelle de
### `0.5.1-pre.006` — composition binaire + transport + listeners
- **implémenté** : remplacement du rôle de `app.config.json` par des compositions `<binary>.default.config.json` ;
- **implémenté** : création de `kb-app-demo-desktop.default.config.json` et d’une composition propre à `ks-pipeline-demo-scenarios` ;
- **implémenté** : création de `kb-app-demo-desktop.default.config.json` et première composition transitoire propre à `ks-pipeline-demo-scenarios`, ensuite supprimée en `pre.007` au profit des defaults partagés ;
- **implémenté** : extraction des endpoints HTTP/WebSocket vers `transport.config.json` avec schéma et exemple dédiés ;
- **implémenté** : extraction des listeners vers `listeners.config.json` avec schéma et exemple dédiés ;
- **implémenté** : sélection explicite des profils logging/transport/listeners par chaque composition ;
@@ -703,22 +713,26 @@ Les tests ne doivent pas figer comme comportement légitime la fuite actuelle de
- **implémenté** : suppression des anciens fichiers source `app.config.json`, `example.app.config.json` et de leur schéma source historique ;
- ne pas encore modifier les DTO publics ni la politique de camouflage.
### `0.5.1-pre.007` — store + wallet + execution + configuration dédiée des binaires
-extraire `database` vers un document storecohérent avec les frontières de `ks-store` ;
-supprimer `DataConfig` en réaffectant`logs_directory`au document logging et `wallets_directory`au document wallet selon leur ownership réel ;
-auditer la redondance entre `data.wallets_directory` et `wallet.wallet_dir`, puis définir un répertoire racine wallet globalet des chemins/alias de profils sans duplication ;
-sortir les paramètres identité/stockage temporaire du wallet vers un document wallet et préparer le contrat `0.5.2` ;
-déplacer `localnet_send_enabled`, `devnet_send_enabled`, `testnet_send_enabled` et `mainnet_send_enabled` hors du wallet vers la politique d'exécution ;
-extraire les politiques d'exécution vers un document indépendant ;
-décider si `app.auto_reconnect_default`, actuellement conservé pour compatibilité, appartient au transport ou doit être supprimé avec migration explicite ;
-sortir `demo` de `ks-config` vers une configuration réellement possédée par `kb-app-demo-desktop` ;
-réduire les compositions à des références vers profils spécialisés et configuration dédiée du binaire ;
-vérifier qu'un nouveau worker peut ajouter son fichier de composition/dédié sans modifier `ks-config` pour enregistrer son existence.
-**implémenté** : extraction de `database` vers `store.config.json` ;
-**implémenté** : suppression de `DataConfig`, avec`logs_directory`global dans logging et `wallets_directory`global dans wallet ;
-**implémenté** : extraction du stockage/alias/persistance wallet vers `wallet.config.json` avec chemins relatifs à la racine globale ;
-**implémenté** : déplacement de `localnet_send_enabled`, `devnet_send_enabled`, `testnet_send_enabled` et `mainnet_send_enabled` vers `execution.config.json` ;
-**implémenté** : extraction complète des politiques d'exécution vers `execution.config.json` ;
-**implémenté** : déplacement de `auto_reconnect` vers des classes de defaults WebSocket nommées, avec overrides par endpoint ;
-**implémenté** : remplacement des `active_profile` des documents partagés par des `default_profile` autonomes ;
-**implémenté** : suppression de la composition par défaut de `ks-pipeline-demo-scenarios`; les scénarios utilisent les defaults partagés sauf override explicite `KS_DEVNET_CONFIG_PATH` ;
-**implémenté** : validation par `ks-config` de l'existence des profils référencés par une composition ;
-**audit TS-RS** : 17 exports `export_to` restent dans `ks-config`, 100 dans `ks-lib` et 89 dans `kb-app-demo-desktop`; le frontend desktop n'importe directement que ses bindings `kb_app_demo_desktop`, aucun binding `ks-config`/`ks-lib`.
### `0.5.1-pre.008` — surfaces publiques sûres et camouflage
Le split partagé est considéré terminé après cette prerelease. Les champs applicatifs transitoires de la composition desktop seront traités avec la frontière publique/application de `pre.008`, et non par la création d'un nouveau document généraliste.
### `0.5.1-pre.008` — surfaces publiques sûres, TS-RS et camouflage
- déplacer les DTO réellement destinés à Tauri/TypeScript vers `kb-app-demo-desktop` ou des wrappers applicatifs dédiés ;
- supprimer les dérivations/export TS-RS de `ks-config` qui n'ont aucun consommateur frontend générique et auditer les 100 exports de `ks-lib` au cas par cas ;
- propager la classification secret/public/internal lors de la résolution des placeholders et valeurs composées ;
- retirer `AppConfig`/`ProfileConfig` résolus du payload Tauri public ;
@@ -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 configurationexposé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
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
