Sasedev/khadhroony-bot3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.5.1-pre.006

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-10 02:44:24 +02:00
parent b6a286a4df
commit 34a670eaec
72 changed files with 5589 additions and 1932 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Politique de namespace Khadhroony Solana
@@ -63,19 +63,25 @@ La classification d'une valeur sensible doit survivre à la substitution. Une ch
## 5. Configuration source, runtime et publique
La restructuration `0.5.1` doit séparer au minimum :
La restructuration `0.5.1` utilise des compositions propres aux binaires et des documents spécialisés partagés :
- la configuration généraliste dans `config/app.config.json`, avec son schéma sous `config/schemas/app.config.schema.json` ;
- la configuration logging dans `config/logging.config.json`, avec son schéma sous `config/schemas/logging.config.schema.json` et des profils logging sélectionnables indépendamment des profils réseau/applicatifs ;
- des exemples conformes mais non chargés par défaut sous `config/example.app.config.json` et `config/example.logging.config.json`.
- `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 ;
- tous les schémas actifs résident sous `config/schemas/`.
D'autres documents spécialisés ne sont créés que si l'audit démontre une responsabilité, un cycle de vie ou une validation réellement indépendants.
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.
`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 :
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.
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.
Une configuration runtime complète ne doit jamais être sérialisée puis « nettoyée » après coup pour produire un payload public.