0.5.0-pre.004

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 33 -->
+<!-- version: 34 -->
 
 # ROADMAP — khadhroony-bot3
 
@@ -56,56 +56,82 @@ Version clôturée et validée.
 
 - aucun fetch HTTP, IPFS ou Arweave n’est intégré aux décodeurs canoniques ;
 - les URI restent des données on-chain observées ;
-- `kb-offchain-transport` est reportée à `0.16.x+`, lorsque les workers et consommateurs réels permettront de définir précisément cache, provenance, hash, redirections, MIME, taille, timeout et protection SSRF.
+- `ks-offchain-transport` est reportée à `0.16.x+`, lorsque les workers et consommateurs réels permettront de définir précisément cache, provenance, hash, redirections, MIME, taille, timeout et protection SSRF.
 
 ## 0.5.x — consolidation des fondations avant l’extension fonctionnelle
 
-La série `0.5.x` existe pour corriger et stabiliser les fondations transversales avant d’empiler les futurs Program IDs et matérialisations métier. L’objectif est d’éviter de devoir modifier tardivement les contrats de configuration, de wallet ou de stockage lorsque Meteora, Raydium, Pump, Orca, Jupiter et les autres protocoles commenceront à dépendre massivement de ces couches.
+La série `0.5.x` corrige et stabilise les fondations transversales avant l'ouverture des grands programmes Anchor/DEX. Elle formalise aussi la séparation entre le domaine applicatif `khadhroony-bot` et les bibliothèques généralistes `khadhroony-solana`.
+
+La politique de namespace et d'ownership adoptée pendant `0.5.0` est documentée dans [`docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`](docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md).
 
 ### 0.5.0 — cadrage et plan de restructuration
 
-- auditer l’état réel de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
-- inventorier les contrats publics, schémas, migrations, dépendances et couplages avant refactor ;
-- produire le plan détaillé de la série `0.5.x` et borner les migrations nécessaires ;
-- ne pas introduire de nouvelle surface protocolaire importante pendant ce cadrage.
+Cadrage clôturé avant toute restructuration majeure :
 
-### 0.5.1 — `kb-config` et configuration sûre
+- audit des responsabilités et couplages de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
+- inventaire des contrats publics, formats persistés, migrations, dépendances, scénarios et preuves de validation ;
+- confirmation du split futur entre configuration généraliste et configuration logging ;
+- définition de la politique de secrets et du namespace d'environnement `KS_*` ;
+- décision de migrer les dix bibliothèques Solana généralistes vers `ks-*` / `ks_*` ;
+- décision de migrer les identités techniques généralistes `kb-lib.decoder.*`, `kb-lib.materializer.*` et `kb-lib.executor.*` vers `ks-lib-decoder.*`, `ks-lib-materializer.*` et `ks-lib-executor.*` ;
+- confirmation que `kb-app-demo-desktop` reste côté Bot et peut héberger à terme des démos Solana généralistes et des démos spécifiques au bot ;
+- préparation de la normalisation future du store, notamment `block_time`, provenance, idempotence et migration des tables Solana `kb_sol_*` vers `k_sol_*` ;
+- maintien de l'exception ElGamal dans son statut synthétique actuel tant qu'aucune nouvelle preuve réseau n'est disponible.
 
-- restructurer `kb-config` par responsabilités cohérentes ;
-- créer au minimum des schémas de validation distincts pour la configuration générale et la configuration logging lorsque l’audit confirme cette frontière ;
-- ajouter d’autres schémas spécialisés seulement lorsqu’ils réduisent réellement le couplage ;
-- revoir les profils, valeurs par défaut, validations croisées, erreurs et résolutions de variables d’environnement ;
-- traiter explicitement les secrets issus de `.env` et des variables d’environnement ;
-- camoufler/redacter les secrets dans logs, diagnostics, UI, erreurs et payloads sérialisés ;
-- empêcher qu’une configuration résolue expose involontairement un secret en clair ;
-- garder exemples, schémas JSON, bindings et documentation synchronisés.
+`0.5.0` n'introduit pas de nouvelle surface protocolaire ni de restructuration runtime importante.
 
-### 0.5.2 — `kb-wallet`
+### 0.5.1 — `ks-*`, `KS_*` et configuration sûre
+
+Cette version effectue la migration de namespace des bibliothèques Solana et restructure la configuration sur la nouvelle fondation.
+
+- renommer les dix crates généralistes : `kb-core`, `kb-config`, `kb-lib`, `kb-logging`, `kb-program-ids`, `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-onchain-transport`, `kb-store` et `kb-wallet` vers leurs équivalents `ks-*` ;
+- migrer les identifiants Rust correspondants vers `ks_*`, les manifests, chemins, imports, exports, tests externes, scripts et documentation ;
+- conserver `kb-app-demo-desktop` comme application du domaine Bot, consommatrice des composants `ks-*` ;
+- migrer les identités runtime/persistées généralistes vers la nomenclature `ks-*`, notamment `ks-lib-decoder.*`, `ks-lib-materializer.*` et `ks-lib-executor.*`, après inventaire exhaustif des chaînes concernées ;
+- imposer le namespace d'environnement `KS_*` pour les variables appartenant au workspace ;
+- classifier `KS_SECRET_*` comme jamais exposable, `KS_PUBLIC_*` comme publiable uniquement via une surface explicitement autorisée et les autres `KS_*` comme internes/diagnostiques ;
+- préserver la sensibilité après substitution : toute valeur composée contenant un `KS_SECRET_*` reste secrète ;
+- séparer la configuration généraliste et la configuration logging dans des documents et schémas indépendants ;
+- permettre des profils logging indépendants des profils réseau/applicatifs ;
+- distinguer configuration source, configuration runtime résolue et DTO publics/diagnostiques ;
+- interdire qu'un secret résolu soit renvoyé en clair par logs, erreurs, diagnostics, UI, sérialisation ou payload Tauri ;
+- garder exemples, schémas JSON, TS-RS et documentation synchronisés.
+
+Les préfixes SQL ne sont pas renommés dans cette version sauf nécessité technique strictement liée au maintien d'un workspace compilable ; leur normalisation appartient à `0.5.3`.
+
+### 0.5.2 — `ks-wallet`
 
 - auditer et normaliser les frontières identité, secret, déverrouillage et signature ;
 - consolider les besoins multi-wallets et multi-profils ;
 - revoir import/export, chiffrement, verrouillage, sauvegarde et restauration lorsque ces capacités sont retenues ;
+- définir explicitement la migration du format keypair JSON `0.4.8` si un nouveau format persistant est adopté ;
 - empêcher toute fuite de secret vers la configuration, les logs, Tauri ou les DTO publics ;
 - conserver une API de signature réutilisable par les futurs exécuteurs sans couplage à un protocole particulier.
 
-### 0.5.3 — audit et normalisation de `kb-store`
+### 0.5.3 — audit et normalisation de `ks-store`
 
 - auditer DTO, entités, repositories, migrations, index, requêtes, idempotence et provenance ;
 - vérifier les champs temporels et séparer explicitement le temps blockchain du temps de persistance ;
-- distinguer notamment slot, block time ou timestamp de transaction des timestamps d’insertion et de mise à jour en base ;
-- normaliser la structure de `kb-store` avant l’arrivée des matérialisations trading ;
+- distinguer notamment `slot`, `block_time` ou timestamp de transaction des timestamps d'acquisition, d'insertion et de mise à jour en base ;
+- normaliser la structure de `ks-store` avant l'arrivée des matérialisations trading ;
+- migrer les tables Solana du préfixe historique `kb_sol_*` vers `k_sol_*` ;
+- réserver `kb_*` aux éventuelles tables dont la responsabilité appartient réellement au domaine applicatif Bot ;
+- profiter de la fenêtre pré-`0.6.x` pour reconstruire ou migrer proprement les bases Devnet/Mainnet au lieu de conserver des alias historiques sans valeur durable ;
 - préparer les index et contrats nécessaires aux faits de création de pools, liquidité, réserves, swaps, évolution de prix et séries temporelles ;
 - préparer le terrain pour routing, multi-pools et analyse croisée sans introduire prématurément des tables spécifiques à un DEX ;
 - permettre des extractions et analyses efficaces pour les futurs consommateurs de trading et de recherche historique.
 
+Aucune table trading spécifique à Meteora, Raydium, Pump, Orca ou Jupiter n'est inventée avant définition des faits stables produits par les futurs matérialisateurs.
+
 ### 0.5.4 — scénarios, exécuteurs et validations
 
 - auditer les scénarios encore déclarés ou assemblés directement dans `kb-app-demo-desktop` ;
-- déplacer toute logique de scénario réutilisable vers `kb-pipeline-demo-scenarios` et laisser le desktop comme adaptateur UI/Tauri ;
+- déplacer toute logique de scénario réutilisable vers `ks-pipeline-demo-scenarios` et laisser le desktop comme adaptateur UI/Tauri ;
 - comparer les décodeurs existants aux exécuteurs disponibles et identifier les exécuteurs réellement manquants ;
 - comparer les exécuteurs aux scénarios synthétiques, campagnes Devnet/Testnet et validations existantes ;
 - identifier les capacités présentes dans le desktop sans scénario réutilisable ;
-- classer chaque absence comme à implémenter, decode-only, deprecated, unavailable, non applicable ou explicitement reportée.
+- classer chaque absence comme à implémenter, decode-only, deprecated, unavailable, non applicable ou explicitement reportée ;
+- ne pas transformer les surfaces réservées ni l'exception ElGamal en dette implicite sans changement de possibilité de validation.
 
 ## 0.6.x — infrastructure Anchor générique et prérequis prioritaires
 
@@ -117,7 +143,7 @@ La série `0.6.x` prépare directement l’accélération sur les protocoles sui
 - implémenter uniquement les programmes/interfaces SPL ou autres prérequis dont Meteora, Raydium, Pump, Orca, Jupiter ou les couches de trading suivantes ont réellement besoin ;
 - reporter à `0.15.x` les programmes SPL non prioritaires, les compléments Metaplex non nécessaires à court terme et, plus généralement, les autres Program IDs déjà recensés ou découverts ultérieurement qui ne bloquent pas la séquence trading prioritaire.
 
-Le report vers `0.15.x` est un choix d’ordre de développement, pas une réduction du périmètre de `kb-lib`. L’objectif à long terme reste de décoder et matérialiser le maximum de Program IDs Solana utiles, qu’ils soient liés ou non au trading.
+Le report vers `0.15.x` est un choix d’ordre de développement, pas une réduction du périmètre de `ks-lib` après la migration `0.5.1`. L’objectif à long terme reste de décoder et matérialiser le maximum de Program IDs Solana utiles, qu’ils soient liés ou non au trading.
 
 ## 0.7.x — Meteora
 
@@ -251,9 +277,9 @@ Reprendre les Program IDs volontairement différés pour accélérer la séquenc
 - Program IDs trading secondaires qui n’étaient pas bloquants ;
 - autres surfaces Solana dont le décodage/matérialisation apporte une valeur durable.
 
-Cette phase réaffirme la vocation généraliste de `kb-lib` : la priorité trading des versions précédentes ne transforme pas la bibliothèque en moteur exclusivement DEX.
+Cette phase réaffirme la vocation généraliste de `ks-lib` : la priorité trading des versions précédentes ne transforme pas la bibliothèque en moteur exclusivement DEX.
 
 ## 0.16.x+ — extensions futures et off-chain
 
 - nouveaux protocoles, transports, backfills, observabilité, administration et optimisations validés par des contrats bornés ;
-- étudier puis créer `kb-offchain-transport` seulement lorsqu’un consommateur réel le justifie, avec premiers modules metadata HTTP(S), IPFS et Arweave, cache et provenance bornés, hash, contrôle des redirections, limites MIME/taille/timeout et protection SSRF IPv4/IPv6.
+- étudier puis créer `ks-offchain-transport` seulement lorsqu’un consommateur réel le justifie, avec premiers modules metadata HTTP(S), IPFS et Arweave, cache et provenance bornés, hash, contrôle des redirections, limites MIME/taille/timeout et protection SSRF IPv4/IPv6.