0.5.1-pre.004
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: prompts/030_v0_5_1_khadhroony_solana_namespace_and_config.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Khadhroony Bot3 — `0.5.1` — migration Khadhroony Solana et configuration sûre
|
||||
|
||||
@@ -10,7 +10,7 @@ Reprendre `khadhroony-bot3` après la clôture validée de `0.5.0` et exécuter
|
||||
`0.5.1` doit accomplir deux objectifs liés :
|
||||
|
||||
1. séparer explicitement le domaine des bibliothèques Solana généralistes du domaine applicatif Khadhroony Bot en migrant les bibliothèques vers les namespaces `ks-*` / `ks_*` ;
|
||||
2. restructurer la configuration sur cette nouvelle fondation, avec namespace d'environnement `KS_*`, séparation du logging et politique stricte de non-divulgation des secrets.
|
||||
2. restructurer la configuration sur cette nouvelle fondation, avec `KS_*` pour les contrats Solana, `KB_*` réservé aux contrats Bot, séparation du logging et politique stricte de non-divulgation des secrets.
|
||||
|
||||
Cette version est une migration de fondation. Elle ne doit pas ouvrir de nouveau programme Anchor/DEX et ne doit pas absorber prématurément les chantiers `ks-wallet`, `ks-store` ou de complétude des scénarios réservés respectivement à `0.5.2`, `0.5.3` et `0.5.4`.
|
||||
|
||||
@@ -21,7 +21,7 @@ La release `0.5.0` est une version de cadrage sans restructuration runtime majeu
|
||||
- la séparation de domaine entre `khadhroony-solana` et `khadhroony-bot` ;
|
||||
- l'inventaire des frontières de configuration, logging, wallet, store, scénarios et desktop ;
|
||||
- la cible de renommage des dix crates Solana généralistes ;
|
||||
- la convention d'environnement `KS_*` ;
|
||||
- la convention d'environnement par ownership : `KS_*` pour Khadhroony Solana et `KB_*` pour les futurs contrats spécifiques au Bot ;
|
||||
- le split obligatoire de la configuration généraliste et de la configuration logging ;
|
||||
- la nécessité de séparer configuration source, runtime résolue et surfaces publiques/diagnostiques ;
|
||||
- la migration future des identités techniques `kb-lib.*` vers le domaine `ks-lib-*` ;
|
||||
@@ -76,8 +76,8 @@ Elle doit produire au minimum :
|
||||
- la table exhaustive des dix crates et identifiants Rust à migrer ;
|
||||
- la table des dépendances workspace et ordre de renommage ;
|
||||
- l'inventaire des noms de packages, bins, libs, imports, exports, tests externes, scripts et documentation concernés ;
|
||||
- l'inventaire exhaustif des variables d'environnement actuellement utilisées et leur nouveau nom `KS_*` ;
|
||||
- la classification de chaque variable en `KS_SECRET_*`, `KS_PUBLIC_*` ou `KS_*` interne ;
|
||||
- l'inventaire exhaustif des variables d'environnement actuellement utilisées, leur propriétaire `KS` ou `KB` et leur nom canonique ;
|
||||
- la classification de chaque variable en `*_SECRET_*`, `*_PUBLIC_*` ou interne dans le namespace de son propriétaire ;
|
||||
- l'inventaire des identités runtime/persistées et targets techniques à migrer ;
|
||||
- l'inventaire des payloads Tauri/TS-RS pouvant actuellement transporter de la configuration résolue ;
|
||||
- l'inventaire des structures dupliquées entre configuration et logging ;
|
||||
@@ -172,45 +172,22 @@ Cependant, le renommage physique des tables et la normalisation des migrations a
|
||||
|
||||
## Namespace obligatoire des variables d'environnement
|
||||
|
||||
Après migration, toute variable d'environnement appartenant au workspace doit commencer par `KS_`.
|
||||
|
||||
La convention retenue est :
|
||||
Le namespace suit le propriétaire fonctionnel du contrat :
|
||||
|
||||
```text
|
||||
KS_SECRET_* secret absolu
|
||||
KS_PUBLIC_* valeur explicitement candidate à une surface publique
|
||||
KS_* valeur interne/diagnostique
|
||||
Khadhroony Solana / ks-* : KS_SECRET_* / KS_PUBLIC_* / KS_*
|
||||
Khadhroony Bot / kb-* : KB_SECRET_* / KB_PUBLIC_* / KB_*
|
||||
```
|
||||
|
||||
Une ancienne variable `KB_*` ou une variable projet sans préfixe `KS_` ne doit pas subsister dans le code, les exemples, tests ou documentation après fermeture de la migration.
|
||||
Une variable de scénario ou de configuration Solana reste `KS_*` même si `kb-app-demo-desktop` la consomme. `KB_*` est réservé aux besoins réellement propres au desktop ou aux futures crates du Bot. Les variables standard de l'OS, de Cargo ou d'outils tiers ne sont pas renommées artificiellement.
|
||||
|
||||
Les variables du système d'exploitation ou de dépendances tierces ne sont pas renommées artificiellement si elles ne constituent pas un contrat de configuration Khadhroony.
|
||||
Les classes ont la même sémantique dans les deux namespaces :
|
||||
|
||||
### `KS_SECRET_*`
|
||||
- `*_SECRET_*` : secret absolu, jamais exposé ni loggé ;
|
||||
- `*_PUBLIC_*` : candidate explicite à une surface publique, sans autorisation automatique d'exposition ;
|
||||
- autres `KS_*` / `KB_*` : internes, absentes des payloads normaux.
|
||||
|
||||
Une valeur issue de `KS_SECRET_*` :
|
||||
|
||||
- peut être utilisée côté backend lorsque nécessaire ;
|
||||
- ne doit jamais apparaître dans les logs ;
|
||||
- ne doit jamais apparaître dans une erreur publique ;
|
||||
- ne doit jamais être sérialisée vers Tauri ;
|
||||
- ne doit jamais être exposée dans un diagnostic, même debug ;
|
||||
- ne doit jamais être exportée par TS-RS comme valeur résolue ;
|
||||
- doit rester secrète lorsqu'elle est incorporée dans une URL, DSN ou autre valeur composée.
|
||||
|
||||
Un diagnostic peut indiquer qu'un secret est configuré ou absent sans exposer sa valeur.
|
||||
|
||||
### `KS_PUBLIC_*`
|
||||
|
||||
Le préfixe `KS_PUBLIC_*` classe la variable comme publiable, mais ne constitue pas une autorisation automatique de parcourir l'environnement et de l'envoyer au frontend.
|
||||
|
||||
L'exposition doit être explicitement définie par un DTO ou une API publique.
|
||||
|
||||
### autres `KS_*`
|
||||
|
||||
Les autres variables `KS_*` sont internes. Elles ne sont pas exposées par les payloads normaux. Elles peuvent apparaître dans un diagnostic explicitement demandé lorsque leur sémantique n'est pas sensible.
|
||||
|
||||
Le simple fait de compiler en mode debug ne doit pas automatiquement exposer toutes les valeurs internes.
|
||||
La migration des noms et la fermeture des alias legacy appartiennent à `pre.004`. La propagation de sensibilité dans les valeurs composées, le camouflage et les DTO publics sûrs sont réalisés après le split config/logging.
|
||||
|
||||
## Split obligatoire de la configuration
|
||||
|
||||
@@ -248,7 +225,7 @@ La restructuration doit empêcher qu'une configuration résolue complète puisse
|
||||
|
||||
Distinguer au minimum :
|
||||
|
||||
1. représentation source : fichiers, placeholders et références `${KS_*}` ;
|
||||
1. représentation source : fichiers, placeholders et références `${KS_*}` / `${KB_*}` ;
|
||||
2. représentation runtime : valeurs validées et résolues nécessaires au backend ;
|
||||
3. représentation publique/diagnostique : DTO explicitement construits pour l'UI, les diagnostics ou une API externe.
|
||||
|
||||
@@ -302,12 +279,12 @@ Les commandes Tauri restent des adaptateurs minces :
|
||||
|
||||
Ajouter des tests prouvant notamment que :
|
||||
|
||||
- une sentinelle issue de `KS_SECRET_*` n'apparaît dans aucune sérialisation publique ;
|
||||
- une sentinelle issue de `KS_SECRET_*` ou `KB_SECRET_*` n'apparaît dans aucune sérialisation publique ;
|
||||
- elle n'apparaît pas dans les erreurs publiques ;
|
||||
- elle n'apparaît pas dans les diagnostics debug ;
|
||||
- une URL ou DSN composée avec un secret est entièrement traitée comme sensible ;
|
||||
- `KS_PUBLIC_*` n'est exposé que par une surface explicitement autorisée ;
|
||||
- une variable `KS_*` interne n'apparaît pas dans le payload normal ;
|
||||
- `KS_PUBLIC_*` / `KB_PUBLIC_*` n'est exposé que par une surface explicitement autorisée ;
|
||||
- une variable interne `KS_*` / `KB_*` n'apparaît pas dans le payload normal ;
|
||||
- les anciens noms d'environnement sont absents après migration ;
|
||||
- les schémas JSON général et logging valident leurs documents respectifs ;
|
||||
- le choix d'un profil logging est indépendant du profil général ;
|
||||
@@ -336,29 +313,36 @@ Le détail doit être confirmé par `0.5.1-pre.001`, mais la trajectoire cible e
|
||||
- maintenir un workspace compilable et auditable ;
|
||||
- conserver `kb-app-demo-desktop`.
|
||||
|
||||
### `0.5.1-pre.003` — identités techniques et environnement `KS_*`
|
||||
### `0.5.1-pre.003` — identités techniques `ks-lib-*`
|
||||
|
||||
- migrer les targets/processor identities généralistes ;
|
||||
- migrer les variables d'environnement ;
|
||||
- mettre en place la classification Secret/Public/Internal ;
|
||||
- mettre à jour exemples et tests sans encore réinventer le store SQL.
|
||||
- migrer les targets et identités runtime/persistables généralistes ;
|
||||
- synchroniser matrices, tracing, diagnostics et provenance/replay ;
|
||||
- conserver encore les variables d'environnement pour la prerelease suivante.
|
||||
|
||||
### `0.5.1-pre.004` — split configuration/logging
|
||||
### `0.5.1-pre.004` — environnement et classification nominale
|
||||
|
||||
- migrer les contrats Solana vers `KS_*` et réserver `KB_*` aux futurs contrats Bot ;
|
||||
- classer les secrets en `*_SECRET_*`, les valeurs explicitement publiques en `*_PUBLIC_*` et le reste en interne ;
|
||||
- consolider les alias historiques Token-2022 ;
|
||||
- mettre à jour `.env.example`, configuration, fixtures, scénarios, store, desktop et guides ;
|
||||
- ne pas encore implémenter le camouflage ou la propagation de sensibilité.
|
||||
|
||||
### `0.5.1-pre.005` — split configuration/logging
|
||||
|
||||
- documents et schémas indépendants ;
|
||||
- profils logging indépendants ;
|
||||
- propriété unique des contrats logging ;
|
||||
- migration/compatibilité explicite des fichiers `0.5.0`.
|
||||
- migration/compatibilité explicite du document monolithique précédent.
|
||||
|
||||
### `0.5.1-pre.005` — runtime/public et Tauri sûr
|
||||
### `0.5.1-pre.006` — runtime/public, camouflage et Tauri sûr
|
||||
|
||||
- séparer source/runtime/public ;
|
||||
- séparer source/runtime/public/diagnostic ;
|
||||
- propager la sensibilité des valeurs composées ;
|
||||
- supprimer les payloads de config complète ;
|
||||
- diagnostics sûrs ;
|
||||
- tests de non-divulgation ;
|
||||
- TS-RS aligné.
|
||||
- diagnostics sûrs et camouflage systématique ;
|
||||
- tests de non-divulgation et TS-RS aligné.
|
||||
|
||||
### `0.5.1-pre.006` — réconciliation et clôture
|
||||
### `0.5.1-pre.007` — réconciliation et clôture
|
||||
|
||||
- audit exhaustif des anciens préfixes ;
|
||||
- documentation finale ;
|
||||
@@ -367,7 +351,7 @@ Le détail doit être confirmé par `0.5.1-pre.001`, mais la trajectoire cible e
|
||||
- archivage du plan/prompt ;
|
||||
- préparation de `0.5.2`.
|
||||
|
||||
Ce découpage peut évoluer si `pre.001` démontre qu'une étape doit être scindée pour garder chaque prerelease compilable et bornée.
|
||||
Ce découpage reste borné : aucun chantier SQL `k_sol_*`, wallet ou DEX n'est absorbé dans `0.5.1`.
|
||||
|
||||
## Règles de développement à conserver
|
||||
|
||||
|
||||
Reference in New Issue
Block a user