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

0.5.1-pre.003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-09 22:48:31 +02:00
parent 6a680767ae
commit 6151bb25e7
333 changed files with 2200 additions and 2158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# 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_*`. Les namespaces historiques `KB_*`, `kb-lib.*` 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-*`. 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.
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.
@@ -75,15 +75,15 @@ Une configuration runtime complète ne doit jamais être sérialisée puis « ne
## 6. Identités runtime et persistées
La migration de namespace ne se limite pas au nom des crates. Les identités techniques actuellement préfixées par `kb-lib` doivent être migrées vers le domaine Khadhroony Solana lorsqu'elles identifient des composants généralistes.
La migration de namespace ne se limite pas au nom des crates. Depuis `0.5.1-pre.003`, les identités techniques généralistes anciennement préfixées par `kb-lib` utilisent le domaine Khadhroony Solana.
La convention cible retenue comprend notamment :
Le mapping de migration retenu et appliqué comprend :
- `kb-lib.decoder.*` → `ks-lib-decoder.*` ;
- `kb-lib.materializer.*` → `ks-lib-materializer.*` ;
- `kb-lib.executor.*` → `ks-lib-executor.*`.
`0.5.1-pre.001` doit produire l'inventaire exhaustif des targets de tracing, `processor_name`, identités de replay/idempotence, codes persistés et autres chaînes techniques concernées avant modification. Les anciennes identités ne doivent pas être conservées par inertie puisque la fondation et la base peuvent encore être migrées avant `0.6.x`.
`0.5.1-pre.001` a produit l'inventaire initial, puis `pre.003` l'a vérifié contre le corpus actif avant migration : 255 identités uniques ont été confirmées, soit 118 décodeurs, 112 exécuteurs et 25 matérialiseurs. Les anciennes identités ne sont conservées que dans les documents de traçabilité de migration ; elles ne doivent plus être produites par le runtime, les matrices ou les routes de logging actives.
Les segments métier internes (`solana`, `spl`, protocoles, surfaces et opérations) conservent leurs règles propres ; la migration de préfixe ne doit pas altérer arbitrairement leur sémantique.