0.5.0-pre.004
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: olddocs/archivekbot3/001.README.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Archive documentaire de khadhroony-bot3
|
||||
|
||||
@@ -32,3 +32,7 @@ Le plan, le prompt de session et les rapports de prerelease de Metaplex Token Me
|
||||
## Clôture 0.4.8
|
||||
|
||||
Le plan `0.4.8`, le prompt de session `028`, les audits `V0_4_8_PRE_*` et les rapports de validation de prerelease sont archivés sous `docs/plans/`, `docs/audits/`, `docs/validation/` et `prompts/`. Le rapport fonctionnel final `0.4.8` reste actif sous `docs/validation/`.
|
||||
|
||||
## Clôture 0.5.0
|
||||
|
||||
Le plan de fondation `0.5.0`, les audits `pre.002` et `pre.003` ainsi que le prompt de session `029` sont archivés sous `docs/plans/` et `prompts/`. Les décisions durables ont été transférées au ROADMAP, aux documents d’architecture et à `docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`.
|
||||
|
||||
507
olddocs/archivekbot3/docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md
Normal file
507
olddocs/archivekbot3/docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md
Normal file
@@ -0,0 +1,507 @@
|
||||
<!-- file: docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Plan `0.5.0` — cadrage de la fondation `0.5.x`
|
||||
|
||||
## 1. Statut et rôle du document
|
||||
|
||||
Ce document est le livrable principal de `0.5.0-pre.001`.
|
||||
|
||||
`0.5.0` est une version de **cadrage, d'audit et de préparation des migrations**. Elle ne doit pas restructurer prématurément `kb-config`, `kb-wallet` ou `kb-store`, ni déplacer en masse les scénarios du desktop avant que leurs contrats actuels, leurs consommateurs et leurs preuves de validation aient été caractérisés.
|
||||
|
||||
Le plan reste temporaire pendant le développement de `0.5.0`. Il doit être maintenu à chaque prerelease, puis archivé sous `olddocs/archivekbot3/` lors de la dernière prerelease, après transfert des décisions durables vers le ROADMAP, les règles, les guides et les documents de crates appropriés.
|
||||
|
||||
**État de `pre.001` : plan validé.**
|
||||
|
||||
**État de `pre.002` : audit config/logging/wallet effectué ; les décisions détaillées sont consignées dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md). Aucune restructuration fonctionnelle n'est encore appliquée.**
|
||||
|
||||
**État de `pre.003` : audit store/scénarios/desktop effectué ; le contrat temporel, la méthode de complétude et la cible de renommage `ks-*` sont consignés dans [`V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md`](V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md). Aucun changement runtime, SQL ou exécuteur n'est appliqué.**
|
||||
|
||||
**État de `pre.004` : cadrage clôturé. La migration des dix crates généralistes vers `ks-*` / `ks_*`, des variables vers `KS_*` et des identités techniques vers `ks-lib-*` est fixée pour `0.5.1`. La migration SQL `kb_sol_*` → `k_sol_*` est fixée pour `0.5.3`. Les décisions durables sont transférées au ROADMAP et à `docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`, puis ce plan est archivé.**
|
||||
|
||||
## 2. Base `0.4.8` à préserver
|
||||
|
||||
La release `0.4.8` constitue la base fonctionnelle fermée de la série `0.5.x` :
|
||||
|
||||
- Solana Program Metadata est une surface indépendante avec neuf opérations confirmées sur Devnet ;
|
||||
- Token-2022 Token Metadata possède cinq opérations confirmées sur Devnet ;
|
||||
- la matrice Metaplex Token Metadata est fermée à 15 `confirmed`, 5 `unavailable` et 0 `not_run` ;
|
||||
- les scénarios Metadata réutilisables sont présents dans `kb-pipeline-demo-scenarios` et raccordés au desktop ;
|
||||
- les matrices, exports, registres runtime, IDL, stockage générique et documents Metadata ont été réconciliés ;
|
||||
- le workspace et le build desktop release ont été validés avant la release `0.4.8`.
|
||||
|
||||
Le registre ElGamal reste une exception connue : implémenté et validé synthétiquement, sans preuve réseau réelle disponible. `0.5.0` ne doit pas rouvrir implicitement ce sujet en l'absence d'une nouvelle possibilité de validation.
|
||||
|
||||
## 3. Sources de vérité et méthode
|
||||
|
||||
L'ordre de priorité utilisé pour le cadrage est :
|
||||
|
||||
1. code et contrats publics actuels ;
|
||||
2. règles actives sous `docs/rules/` ;
|
||||
3. schémas, migrations, matrices et tests actifs ;
|
||||
4. README, USAGE, TODO, changelogs et architecture actifs ;
|
||||
5. prompt actif `029` ;
|
||||
6. prompts archivés `027` et `028` uniquement comme références historiques et méthodologiques.
|
||||
|
||||
Les documents archivés ne sont jamais utilisés pour contredire un contrat actuel. Aucun changement de contrat public ne doit être entrepris sans recherche de ses consommateurs dans les onze crates et sans audit des tests d'API externe concernés.
|
||||
|
||||
## 4. Carte actuelle des responsabilités et couplages
|
||||
|
||||
Le workspace contient onze crates. Les six surfaces directement auditées pour `0.5.0` se placent aujourd'hui comme suit.
|
||||
|
||||
| Surface | Responsabilité actuelle | Dépendances workspace directes | Consommateurs directs principaux | Risque de migration |
|
||||
|------------------------------|--------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
|
||||
| `kb-config` | schéma JSON, parsing, validation, profils, résolution d'environnement, sérialisation | `kb-core` | `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-onchain-transport`, `kb-app-demo-desktop` | très élevé : types publics et TS-RS largement consommés |
|
||||
| `kb-logging` | runtime `tracing`, routes, formats, rotations, filtres | `kb-core` | `kb-app-demo-desktop` | moyen : contrat runtime dupliqué dans `kb-config` |
|
||||
| `kb-wallet` | alias, keypair local temporaire, persistance JSON, signature | `kb-core` | `kb-pipeline-demo-scenarios`, `kb-app-demo-desktop` | élevé : secret persistant et API signer traversant les scénarios |
|
||||
| `kb-store` | DTO, entités, repositories, migrations PostgreSQL, diagnostics, replay/persistance | `kb-core`, `kb-lib` | `kb-pipeline`, `kb-pipeline-demo-scenarios`, `kb-app-demo-desktop` | très élevé : schéma SQL publié et grande façade publique |
|
||||
| `kb-pipeline-demo-scenarios` | fixtures et campagnes synthétiques/réseau réutilisables | `kb-core`, `kb-config`, `kb-lib`, `kb-onchain-transport`, `kb-pipeline`, `kb-program-ids`, `kb-store`, `kb-wallet` | `kb-app-demo-desktop` | élevé : convergence de presque toutes les fondations |
|
||||
| `kb-app-demo-desktop` | composition applicative, état Tauri, IPC, TS-RS et UI opérateur | les dix autres crates | frontend Tauri | élevé côté IPC ; ne doit pas devenir propriétaire de logique réutilisable |
|
||||
|
||||
Cette topologie confirme l'ordre du ROADMAP : stabiliser d'abord la configuration, puis le wallet, puis le store, avant l'audit final des scénarios et exécuteurs. Une inversion de cet ordre multiplierait les adaptations transitoires.
|
||||
|
||||
## 5. Contrats publics et formats sensibles aux migrations
|
||||
|
||||
### 5.1 `kb-config` et configuration frontend
|
||||
|
||||
Les contrats sensibles sont au minimum :
|
||||
|
||||
- `AppConfig`, `ProfileConfig` et les sous-structures publiques ;
|
||||
- les dérivations `serde` et TS-RS de ces structures ;
|
||||
- `config/schema.config.json` et son équivalent embarqué ;
|
||||
- `config/example.config.json` ;
|
||||
- la syntaxe `${NAME}` et `${NAME:-fallback}` ;
|
||||
- les fonctions de parsing, validation, sélection de profil et sérialisation ;
|
||||
- les erreurs et validations dont le code est consommé par les tests ou les adaptateurs ;
|
||||
- `DemoConfigPayload` et la commande Tauri `load_demo_config`.
|
||||
|
||||
Le split futur ne doit pas être traité comme un simple déplacement de fichiers : il peut affecter schéma, chargement, migration, TS-RS, exemples, diagnostics et consommateurs.
|
||||
|
||||
### 5.2 `kb-logging`
|
||||
|
||||
`kb-config` et `kb-logging` possèdent actuellement des structures presque identiques `LoggingConfig`, `LogTargetConfig` et `LogTargetFilterConfig`. Le desktop les convertit manuellement dans `app_state.rs`.
|
||||
|
||||
`pre.002` confirme que le logging doit devenir un document et un schéma distincts de la configuration généraliste. Les profils logging doivent pouvoir évoluer indépendamment des profils réseau/applicatifs et la conversion manuelle du desktop doit disparaître lors de `0.5.1`.
|
||||
|
||||
La propriété exacte du DTO source logging doit encore respecter la direction des dépendances : `kb-config` ne doit pas dépendre du runtime `kb-logging` par commodité. `0.5.1` devra choisir un propriétaire unique du contrat source et éviter une nouvelle crate si elle ne représente pas une responsabilité autonome.
|
||||
|
||||
### 5.3 `kb-wallet`
|
||||
|
||||
Le format persistant actuel est un contrat de compatibilité réel :
|
||||
|
||||
- chemin déterministe `<alias>.json` ;
|
||||
- contenu : tableau JSON standard du keypair Solana ;
|
||||
- création sans écrasement ;
|
||||
- permissions privées Unix et refus des liens symboliques/fichiers non réguliers ;
|
||||
- buffers temporaires secrets effacés ;
|
||||
- `TemporaryWallet` garde le keypair privé mais expose `as_signer()` et `as_sync_signer()` ;
|
||||
- `WalletSummary` est le contrat non secret destiné aux adaptateurs.
|
||||
|
||||
Un futur chiffrement ou format versionné doit donc définir l'import de ce format `0.4.8`, la détection de format, la sauvegarde, l'échec atomique et la stratégie de rollback. La présence de primitives cryptographiques dans les dépendances workspace ne constitue pas, à elle seule, une décision d'architecture.
|
||||
|
||||
### 5.4 `kb-store`
|
||||
|
||||
Les migrations publiées `0001` à `0004` sont immuables. Toute évolution devra passer par une nouvelle migration.
|
||||
|
||||
Les contrats sensibles incluent :
|
||||
|
||||
- les tables `kb_sol_*`, contraintes et index ;
|
||||
- les DTO/entités `*Insert`, `*Row`, bundles atomiques et filtres ;
|
||||
- les traits de repositories publics ;
|
||||
- les identités persistées de processeur, version, input/output et source ;
|
||||
- les états de ledger et de lifecycle ;
|
||||
- les noms de tables exportés pour diagnostics/audits ;
|
||||
- le JSON canonique des transactions, dont la version de format est gérée hors du SQL.
|
||||
|
||||
Le modèle canonique et les transports portent déjà `block_time`, mais les tables raw/Core/decode/materialization ne le promeuvent pas uniformément comme colonne de premier rang. Les timestamps de persistance (`created_at`, `updated_at`, `persisted_at`) ne doivent pas être confondus avec le temps on-chain.
|
||||
|
||||
### 5.5 `kb-pipeline-demo-scenarios`
|
||||
|
||||
Les contrats publics de scénarios, identifiants de campagnes, requêtes, résultats, matrices de qualification et preuves consommées par le desktop doivent être audités avant déplacement de logique. Une campagne `confirmed`, `unavailable` ou synthétique garde son niveau de preuve tant que la frontière couverte n'a pas changé.
|
||||
|
||||
### 5.6 `kb-app-demo-desktop`
|
||||
|
||||
Les commandes Tauri et payloads TS-RS sont une API applicative externe au backend Rust, même lorsque leurs structures Rust sont `pub(crate)`. Les noms de commandes, champs sérialisés, invariants d'annulation/progression et restauration d'état doivent être caractérisés avant changement.
|
||||
|
||||
Le desktop peut conserver :
|
||||
|
||||
- sélection et saisie opérateur ;
|
||||
- mapping UI vers une requête réutilisable ;
|
||||
- adaptation d'un résultat réutilisable vers TS-RS ;
|
||||
- progression, annulation et présentation ;
|
||||
- composition d'état strictement applicative.
|
||||
|
||||
La préparation de fixture, la construction d'une campagne, l'orchestration RPC, les postconditions et la qualification réutilisable n'ont pas vocation à rester dans le desktop.
|
||||
|
||||
## 6. Problèmes réels identifiés pendant `pre.001`
|
||||
|
||||
### P0 — exposition possible de secrets résolus vers le frontend
|
||||
|
||||
C'est le risque prioritaire de `0.5.1`.
|
||||
|
||||
La configuration charge et résout des placeholders susceptibles de contenir notamment :
|
||||
|
||||
- un DSN PostgreSQL avec identifiants ;
|
||||
- une clé d'API intégrée à une URL HTTP ou WebSocket.
|
||||
|
||||
`AppConfig` et `ProfileConfig` sont sérialisables. Le desktop construit actuellement `DemoConfigPayload` en clonant la configuration complète et le profil actif, puis le frontend les affiche dans des JSON viewers.
|
||||
|
||||
Il existe donc un chemin concret permettant à un secret résolu d'atteindre un payload Tauri et l'UI. `0.5.1` devra fermer ce chemin avant de considérer la nouvelle architecture de configuration comme sûre.
|
||||
|
||||
**Contraintes de correction futures :**
|
||||
|
||||
- aucune valeur secrète résolue en clair dans un payload UI ou diagnostic ;
|
||||
- aucune valeur secrète dans `Debug`, logs ou erreurs ;
|
||||
- sérialisation publique explicitement redacted ou séparée de la représentation runtime ;
|
||||
- tests avec sentinelles secrètes couvrant DSN, URL, query string et erreurs ;
|
||||
- absence de régression sur les consommateurs backend qui ont réellement besoin des valeurs résolues.
|
||||
|
||||
### P1 — duplication du contrat logging
|
||||
|
||||
Le même shape de configuration logging existe dans `kb-config` et `kb-logging`, avec conversion manuelle dans le desktop. C'est un couplage réel, pas seulement documentaire. `0.5.1` doit choisir un propriétaire de chaque responsabilité : format de configuration, validation et runtime.
|
||||
|
||||
### P1 — migration du wallet non définie
|
||||
|
||||
Le wallet actuel est fonctionnel mais son secret est persisté en clair dans le format Solana standard. Ajouter chiffrement, verrouillage, multi-wallet ou backup sans définir un format versionné et une migration ferait courir un risque de perte ou d'incompatibilité de clés.
|
||||
|
||||
### P1 — modèle temporel du store incomplet pour les futurs faits trading
|
||||
|
||||
Le store distingue déjà plusieurs timestamps d'acquisition dans les observations, mais cette distinction n'est pas propagée uniformément vers les tables Core, decode et materialization. `block_time` existe dans la transaction canonique mais n'est pas une dimension SQL commune de premier rang.
|
||||
|
||||
Avant toute table trading, `0.5.3` devra définir les dimensions stables : identité de transaction/instruction, slot, temps on-chain lorsqu'il existe, provenance, identité de processeur, idempotence et temps de persistance.
|
||||
|
||||
### P2 — orchestration résiduelle dans le desktop
|
||||
|
||||
Plusieurs modules d'exécution desktop combinent encore des appels directs à `kb-pipeline`, `kb-lib` executor, transport, wallet ou store en plus de `kb-pipeline-demo-scenarios`. C'est un signal d'audit pour `0.5.4`, pas une preuve que tout le module doit être déplacé.
|
||||
|
||||
L'audit devra distinguer précisément :
|
||||
|
||||
- orchestration réutilisable à déplacer ;
|
||||
- adaptation Tauri légitime à conserver ;
|
||||
- logique de rendu/frontend ;
|
||||
- diagnostics généralistes qui ne sont pas des scénarios.
|
||||
|
||||
### P2 — documentation active partiellement obsolète
|
||||
|
||||
Deux divergences sont déjà confirmées :
|
||||
|
||||
- `docs/guides/CONFIGURATION.md` cite `load_config_from_str` et `load_config_from_path`, absents de l'API actuelle ;
|
||||
- `kb-config/USAGE.md` présente l'affichage du JSON résolu comme cas de diagnostic, alors que ce JSON peut contenir des secrets ;
|
||||
- les README de `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` décrivent encore le maintien de « scénarios UI » dans le desktop, formulation incompatible avec la cible `0.5.4` lorsqu'elle concerne une orchestration réutilisable.
|
||||
|
||||
Ces écarts doivent être corrigés dans une prerelease documentaire de `0.5.0` ou dans la version propriétaire de la frontière, sans réécrire l'histoire des changelogs.
|
||||
|
||||
## 7. Ce qui appartient à `0.5.0`
|
||||
|
||||
`0.5.0` doit livrer uniquement la préparation fiable de la série :
|
||||
|
||||
- cartographie des responsabilités et dépendances ;
|
||||
- inventaire des contrats publics et formats persistés ;
|
||||
- identification des risques de migration et des consommateurs ;
|
||||
- tests de caractérisation non controversés et tests d'API externe manquants lorsque nécessaires ;
|
||||
- audits ciblés des quatre axes `0.5.1` à `0.5.4` ;
|
||||
- décisions de vocabulaire et critères d'acceptation ;
|
||||
- stratégie de migration et rollback à un niveau suffisant pour coder ensuite sans improvisation ;
|
||||
- correction de la documentation rendue factuellement fausse par l'audit ;
|
||||
- préparation des prompts suivants.
|
||||
|
||||
`0.5.0` ne doit pas :
|
||||
|
||||
- scinder effectivement les fichiers ou types de `kb-config` ;
|
||||
- modifier le format wallet persistant ;
|
||||
- ajouter une migration SQL trading ;
|
||||
- créer des tables spécifiques Meteora/Raydium/Pump/Orca/Jupiter ;
|
||||
- déplacer en masse les scénarios du desktop ;
|
||||
- ajouter des exécuteurs non justifiés ;
|
||||
- rejouer automatiquement les campagnes réseau déjà qualifiées ;
|
||||
- rouvrir ElGamal sans possibilité de preuve nouvelle ;
|
||||
- introduire de nouvelle surface protocolaire majeure.
|
||||
|
||||
## 8. Préparation de `0.5.1` — configuration et namespace `ks-*`
|
||||
|
||||
### Décisions fermées par `pre.002`
|
||||
|
||||
- toutes les variables d'environnement propres au projet devront utiliser le namespace `KS_*` ;
|
||||
- `KS_SECRET_*` est strictement non exposable, y compris en debug/diagnostic ;
|
||||
- `KS_PUBLIC_*` est seulement candidate à une exposition explicitement autorisée par un DTO public ;
|
||||
- autre `KS_*` reste interne et n'est visible que par un diagnostic explicite et borné ;
|
||||
- toute valeur composée contenant un secret hérite de la classification `Secret` ;
|
||||
- la configuration source, la configuration runtime résolue et les DTO publics/diagnostics doivent être des frontières distinctes ;
|
||||
- le logging doit être extrait dans un document et un schéma JSON indépendants ;
|
||||
- le profil logging doit pouvoir évoluer indépendamment du profil généraliste ;
|
||||
- la conversion manuelle `kb-config` -> `kb-logging` actuellement située dans le desktop doit disparaître ;
|
||||
- les bibliothèques Solana généralistes doivent migrer vers le namespace Cargo `ks-*` / Rust `ks_*` pendant `0.5.1` ; la liste exacte et le traitement des identités persistées doivent être fermés avant le premier renommage.
|
||||
|
||||
L'audit a recensé 84 noms d'environnement actifs ou de fixture dans le code/configuration de référence : 67 `KB_*` et 17 sans namespace cible. La migration exacte est détaillée dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md).
|
||||
|
||||
### Critères d'acceptation préparés
|
||||
|
||||
- migration explicite du format `0.4.8` vers les documents séparés ;
|
||||
- schémas JSON général et logging distincts et synchronisés avec leurs modèles ;
|
||||
- table exhaustive ancien nom d'environnement -> nouveau nom `KS_*` ;
|
||||
- refus des variables Khadhroony hors namespace `KS_*` après migration ;
|
||||
- tests des profils, defaults, validations croisées et erreurs ;
|
||||
- tests `.env`, fichier dotenv sélectionné, placeholders et fallbacks ;
|
||||
- canaris `KS_SECRET_*` absents de tous les payloads publics, logs, diagnostics et erreurs ;
|
||||
- suppression du payload frontend de configuration résolue complète ;
|
||||
- aucun élargissement automatique de la surface publique uniquement parce que la build est debug ;
|
||||
- adaptation explicite de `kb-logging`, transport, pipeline, scénarios et desktop ;
|
||||
- aucune dépendance de `kb-store` vers `kb-config` ;
|
||||
- tests d'API externe de la façade `kb-config` avant changement structurel ;
|
||||
- documentation et exemples alignés.
|
||||
|
||||
## 9. Préparation de `0.5.2` — `ks-wallet`
|
||||
|
||||
### Frontières à concevoir
|
||||
|
||||
- identité publique d'un wallet ;
|
||||
- matériau secret persistant ;
|
||||
- état verrouillé/déverrouillé et durée de session ;
|
||||
- capacité de signature ;
|
||||
- sélection de wallet/profil ;
|
||||
- import/export, backup/restore et migration de format.
|
||||
|
||||
### Compatibilité à préserver
|
||||
|
||||
- lecture contrôlée des wallets `0.4.8` au format JSON Solana ;
|
||||
- correspondance alias -> clé publique ;
|
||||
- possibilité de fournir un signer aux exécuteurs sans exposer les octets ;
|
||||
- comportement atomique en cas de corruption ou d'échec d'écriture ;
|
||||
- permissions et protections filesystem existantes.
|
||||
|
||||
### Tests à préparer
|
||||
|
||||
- fixtures de wallet `0.4.8` ;
|
||||
- migration aller/échec/rollback ;
|
||||
- mauvais mot de passe et données corrompues ;
|
||||
- concurrence de création/import ;
|
||||
- lock/unlock et invalidation de session ;
|
||||
- absence de secret dans `Debug`, erreurs, résumés, config et Tauri ;
|
||||
- backup/restore si cette capacité est retenue.
|
||||
|
||||
## 10. Préparation de `0.5.3` — `ks-store`
|
||||
|
||||
### Vocabulaire temporel à normaliser
|
||||
|
||||
Le store doit distinguer explicitement :
|
||||
|
||||
- `slot` : ordre/position blockchain, pas un timestamp ;
|
||||
- `block_time` ou temps de transaction : temps on-chain optionnel fourni par la chaîne ;
|
||||
- temps d'observation/acquisition : `detected_at`, `received_at`, `normalized_at` lorsque pertinent ;
|
||||
- temps de persistance : `persisted_at`, `created_at`, `updated_at`.
|
||||
|
||||
Aucune requête temporelle métier ne doit utiliser `created_at` comme substitut implicite de `block_time`.
|
||||
|
||||
### Faits stables à définir avant les DEX
|
||||
|
||||
Sans inventer de table protocolaire, l'audit doit déterminer quelles dimensions génériques sont nécessaires pour que de futurs matérialisateurs puissent exprimer efficacement :
|
||||
|
||||
- création/identité d'un pool ou marché ;
|
||||
- actifs et comptes de réserve ;
|
||||
- variations de liquidité et réserves observées ;
|
||||
- swaps ;
|
||||
- prix observés et unités utilisées ;
|
||||
- séries temporelles ;
|
||||
- provenance du fait et idempotence ;
|
||||
- relation entre plusieurs pools et futures routes.
|
||||
|
||||
Le résultat attendu est un contrat de faits et d'indexation, pas un schéma Meteora ou Raydium anticipé.
|
||||
|
||||
### Migration à préparer
|
||||
|
||||
- conserver `0001` à `0004` comme historique du schéma `0.5.0` ;
|
||||
- définir la stratégie de reconstruction/migration vers le nouveau namespace SQL sans réécrire silencieusement l’historique ;
|
||||
- migrer les tables Solana `kb_sol_*` vers `k_sol_*` et réserver `kb_*` aux données réellement spécifiques au Bot ;
|
||||
- définir une nouvelle migration uniquement après validation du modèle lorsque la stratégie retenue conserve une chaîne de migrations ;
|
||||
- préciser la nullabilité et le backfill de `block_time` ;
|
||||
- tester migration sur schéma `0.4.8`, réexécution idempotente et données existantes ;
|
||||
- mesurer/inspecter les index destinés aux requêtes temporelles et multi-entités ;
|
||||
- consommer les identités `ks-lib-*` migrées en `0.5.1` et préserver leurs clés de provenance/idempotence selon le nouveau contrat.
|
||||
|
||||
## 11. Préparation de `0.5.4` — scénarios et complétude d'exécution
|
||||
|
||||
L'audit doit produire une matrice par capacité avec au minimum :
|
||||
|
||||
- décodeur ;
|
||||
- matérialiseur ;
|
||||
- exécuteur ;
|
||||
- scénario synthétique ;
|
||||
- scénario réutilisable réseau ;
|
||||
- adaptation desktop ;
|
||||
- preuve simulation ;
|
||||
- preuve soumission ;
|
||||
- postcondition ;
|
||||
- qualification finale.
|
||||
|
||||
Chaque absence doit être classée dans une des catégories imposées :
|
||||
|
||||
- `implement` ;
|
||||
- `decode-only` ;
|
||||
- `deprecated` ;
|
||||
- `unavailable` ;
|
||||
- `not-applicable` ;
|
||||
- `deferred`.
|
||||
|
||||
Un exécuteur n'est pas requis uniquement parce qu'un décodeur existe. La justification doit intégrer sécurité, programme courant, possibilité de fixture et valeur pour les versions suivantes.
|
||||
|
||||
Le déplacement d'un scénario vers `ks-pipeline-demo-scenarios` doit conserver le desktop comme adaptateur et préserver les noms/payloads Tauri lorsque leur changement n'apporte aucune valeur.
|
||||
|
||||
## 12. Découpage borné de `0.5.0`
|
||||
|
||||
### `0.5.0-pre.001` — audit initial, brainstorming et plan
|
||||
|
||||
Livrables :
|
||||
|
||||
- lecture des règles, architecture, documents de crates, schémas et migrations ;
|
||||
- cartographie des six surfaces concernées ;
|
||||
- identification des contrats sensibles et premiers écarts réels ;
|
||||
- plan vivant de `0.5.0` et de la série `0.5.x` ;
|
||||
- ouverture de `workspace.package.version` sur `0.5.0-pre.1` ;
|
||||
- alignement frontend/Tauri sur la version fonctionnelle `0.5.0` ;
|
||||
- aucun changement fonctionnel ou structurel.
|
||||
|
||||
Critère de sortie : plan complet et **validation explicite du plan avant toute restructuration**.
|
||||
|
||||
### `0.5.0-pre.002` — audit config/logging/wallet et contrats de sécurité
|
||||
|
||||
Livrables réalisés :
|
||||
|
||||
- inventaire des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ;
|
||||
- audit des chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ;
|
||||
- confirmation du split logging en document + schéma indépendants ;
|
||||
- définition de la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` et de la propagation de sensibilité ;
|
||||
- inventaire de 84 contrats d'environnement actifs ou de fixture à migrer ;
|
||||
- audit des tests TS-RS et tests d'API externe manquants ;
|
||||
- caractérisation du format de configuration `0.4.8` et du format wallet `0.4.8` ;
|
||||
- dossier de migration `0.5.1` et `0.5.2` avec compatibilité, rollback et critères de non-divulgation ;
|
||||
- ouverture de l'audit transversal sur le namespace de crates `ks-*`, sans renommage prématuré ;
|
||||
- correction des documents de configuration rendus faux ou dangereux par l'audit, sans appliquer encore le nouveau format.
|
||||
|
||||
Critère de sortie : frontières source/runtime/public fermées, namespace d'environnement cible défini, split logging confirmé et contrat de migration wallet borné. `pre.003` ferme ensuite la direction : les bibliothèques Solana généralistes migreront vers `ks-*` en `0.5.1`, avec audit séparé des identités persistées.
|
||||
|
||||
### `0.5.0-pre.003` — audit store/scénarios/desktop et contrats de préparation
|
||||
|
||||
Livrables réalisés :
|
||||
|
||||
- matrice des migrations `0001` à `0004`, colonnes temporelles, provenance, idempotence, index et requêtes ;
|
||||
- définition du vocabulaire on-chain/persistance et des faits génériques requis avant trading ;
|
||||
- dossier de migration `0.5.3`, sans créer de table DEX ;
|
||||
- inventaire des scénarios/orchestrations du desktop et de leurs équivalents réutilisables ;
|
||||
- matrice decoder/materializer/executor/scenario/network-proof préparant `0.5.4` ;
|
||||
- classification des absences sans implémenter les exécuteurs ;
|
||||
- identification précise des validations réseau à rejouer uniquement si une frontière couverte change ;
|
||||
- inventaire statique des exécuteurs : 8 actifs et 103 réservés ;
|
||||
- confirmation qu'ElGamal est le seul exécuteur actif sans scénario réseau réutilisable et reste conditionnel faute de preuve disponible ;
|
||||
- correction de la frontière normative : campagnes réutilisables dans `kb-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop ;
|
||||
- décision de faire du renommage des dix bibliothèques généralistes vers `ks-*` / `ks_*` une partie de `0.5.1` ; décision finale de migrer aussi les identités `kb-lib.*` vers `ks-lib-*` en `0.5.1`, tandis que les tables `kb_sol_*` migreront vers `k_sol_*` pendant `0.5.3`.
|
||||
|
||||
Critère de sortie : contrats de `0.5.3` et méthode de complétude `0.5.4` suffisamment fermés pour éviter une refonte spéculative. L'audit détaillé est consigné dans [`V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md`](V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md).
|
||||
|
||||
### `0.5.0-pre.004` — clôture obligatoire de `0.5.0`
|
||||
|
||||
Livrables réalisés :
|
||||
|
||||
- réconciliation transversale des audits et décisions de namespace ;
|
||||
- fixation du périmètre Khadhroony Solana : dix crates généralistes, `ks-pipeline-demo-scenarios` inclus, `kb-app-demo-desktop` exclu ;
|
||||
- fixation des conventions `KS_*`, `ks-lib-*`, `k_sol_*` et `kb_*` selon leur domaine ;
|
||||
- transfert des décisions durables dans le ROADMAP, l’architecture et la politique de namespace ;
|
||||
- archivage du présent plan, des audits `pre.002`/`pre.003` et du prompt `029` sous `olddocs/archivekbot3/` ;
|
||||
- préparation du prompt `030` pour `0.5.1` ;
|
||||
- préparation de la release finale `0.5.0` sans nouvelle fonctionnalité structurelle majeure.
|
||||
|
||||
Les validations Cargo finales restent à exécuter sur le workspace réel après application du delta `pre.004`, l’environnement de préparation ne fournissant pas Cargo.
|
||||
|
||||
Le CHANGELOG racine conserve sa règle : les entrées fonctionnelles publiées sont ajoutées au moment de la release finale, pas sous une section « non publiée » artificielle.
|
||||
|
||||
## 13. Tests et audits à préparer avant code structurel
|
||||
|
||||
### Contrats publics
|
||||
|
||||
- rechercher chaque type/fonction modifié dans les onze crates ;
|
||||
- ajouter ou compléter les tests d'API externe lorsque la façade publique n'est pas caractérisée ;
|
||||
- tester les noms et champs Tauri/TS-RS lorsqu'ils constituent une interface frontend stable ;
|
||||
- ne pas figer par test une fuite de secret ou une mauvaise frontière connue.
|
||||
|
||||
### Configuration
|
||||
|
||||
- fixture `0.4.8` complète ;
|
||||
- round-trip du format actuel ;
|
||||
- tests d'environnement/placeholder ;
|
||||
- sentinelles secrètes et assertions de redaction pour chaque sortie publique future ;
|
||||
- migration old -> new et erreurs de migration explicites.
|
||||
|
||||
### Wallet
|
||||
|
||||
- fixture persistée `0.4.8` ;
|
||||
- identité de clé publique après import/migration ;
|
||||
- tests de corruption, permissions, concurrence et atomicité ;
|
||||
- tests de verrouillage/chiffrement uniquement après décision du format.
|
||||
|
||||
### Store
|
||||
|
||||
- application des migrations historiques sur base vide ;
|
||||
- migration d'une base `0.4.8` avec données ;
|
||||
- idempotence des migrations ;
|
||||
- conservation des clés de provenance et d'idempotence ;
|
||||
- backfill/nullabilité des temps on-chain ;
|
||||
- requêtes bornées et index adaptées aux dimensions retenues.
|
||||
|
||||
### Scénarios/exécution
|
||||
|
||||
- matrice automatisable de complétude des registres ;
|
||||
- tests synthétiques et contractuels en premier ;
|
||||
- simulation RPC exacte avant soumission ;
|
||||
- réseau uniquement lorsqu'une nouvelle capacité ou frontière modifiée le justifie ;
|
||||
- postconditions et matérialisation observables avant promotion du statut.
|
||||
|
||||
## 14. Politique de validation réseau pendant `0.5.x`
|
||||
|
||||
Pour une nouvelle capacité exécutable :
|
||||
|
||||
1. contrat et tests synthétiques ;
|
||||
2. scénario réutilisable ;
|
||||
3. simulation RPC exacte ;
|
||||
4. soumission Devnet/Testnet sûre et disponible ;
|
||||
5. postconditions et matérialisation observables ;
|
||||
6. adaptateur desktop ;
|
||||
7. qualification explicite.
|
||||
|
||||
Une preuve synthétique seule ne promeut jamais un statut réseau. Inversement, une campagne `0.4.8` déjà qualifiée n'est pas rejouée après un refactor si aucune frontière qu'elle couvre n'a changé et si les tests de compatibilité restent propres.
|
||||
|
||||
## 15. Contrôles de référence
|
||||
|
||||
Après chaque delta Rust ou de contrat :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Le desktop est validé par Tauri uniquement :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Ne jamais lancer directement les scripts npm de développement ou build. Les commandes npm manuelles restent limitées à l'installation explicite de dépendances.
|
||||
|
||||
## 16. Critères de clôture de `0.5.0`
|
||||
|
||||
`0.5.0` peut être clôturée lorsque :
|
||||
|
||||
- les six surfaces ont un audit suffisamment précis pour leurs versions propriétaires ;
|
||||
- les contrats publics et formats persistés à migrer sont inventoriés ;
|
||||
- le chemin de fuite de configuration résolue est explicitement attribué à `0.5.1` avec critères de non-divulgation ;
|
||||
- le namespace d'environnement `KS_*` et les classes `Secret/Public/Internal` sont documentés avec propagation de sensibilité ;
|
||||
- le split logging en document et schéma indépendants est retenu comme cible de `0.5.1` ;
|
||||
- la liste des dix crates `ks-*`, la migration des identités `ks-lib-*`, le format wallet `0.4.8` et ses exigences de migration sont documentés ;
|
||||
- le vocabulaire temporel/provenance/idempotence du store et la cible SQL `k_sol_*` sont définis avant tout schéma trading ;
|
||||
- la méthode d'audit decoder/executor/scenario/validation de `0.5.4` est fermée ;
|
||||
- aucun chantier `0.5.1` à `0.5.4` n'a été implémenté prématurément ;
|
||||
- les documents actifs ne présentent plus les hypothèses obsolètes identifiées ;
|
||||
- les contrôles de référence sont propres sur le workspace réel ;
|
||||
- le plan et le prompt terminés sont archivés et le prompt `030` de `0.5.1` est prêt.
|
||||
@@ -0,0 +1,380 @@
|
||||
<!-- file: docs/plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Audit `0.5.0-pre.002` — configuration, logging, wallet et namespaces
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce document complète le plan temporaire [`V0_5_0_FOUNDATION_0_5_X_PLAN.md`](V0_5_0_FOUNDATION_0_5_X_PLAN.md) avec l'audit approfondi prévu pour `0.5.0-pre.002`.
|
||||
|
||||
Cette prerelease reste **non structurelle** : elle ferme les contrats à préparer pour `0.5.1` et `0.5.2`, mais ne scinde pas encore les fichiers de configuration, ne change pas les noms de variables d'environnement utilisés par le runtime, ne modifie pas le format wallet persistant et ne renomme aucune crate.
|
||||
|
||||
## 2. Décisions de cadrage fermées
|
||||
|
||||
### 2.1 Namespace des variables d'environnement
|
||||
|
||||
Toutes les variables d'environnement appartenant à Khadhroony/Solana devront obligatoirement commencer par `KS_`.
|
||||
|
||||
La convention cible comporte trois niveaux :
|
||||
|
||||
- `KS_SECRET_*` : secret absolu, utilisable uniquement côté backend et jamais exposé, sérialisé, loggé ou inclus en clair dans une erreur, y compris en mode debug ou diagnostic ;
|
||||
- `KS_PUBLIC_*` : valeur explicitement candidate à l'exposition publique, mais seulement lorsqu'un DTO public l'autorise ;
|
||||
- autre `KS_*` : valeur interne, non exposée en fonctionnement normal et consultable uniquement par un diagnostic explicite et borné.
|
||||
|
||||
Aucune variable hors namespace `KS_*` ne doit être lue comme contrat propre au projet après migration. Le runtime ne doit jamais énumérer l'environnement du processus pour décider automatiquement ce qui est exposable.
|
||||
|
||||
Le préfixe ne remplace pas la politique de type : une valeur `KS_PUBLIC_*` n'est pas envoyée au frontend si aucun DTO public ne l'autorise, et une valeur issue d'un champ sémantiquement secret reste secrète même si son nom est mal classé.
|
||||
|
||||
### 2.2 Propagation de la sensibilité
|
||||
|
||||
La résolution d'un placeholder ne doit plus perdre son origine de sécurité.
|
||||
|
||||
Si une chaîne composée contient au moins une valeur `KS_SECRET_*`, la chaîne résolue complète devient secrète. Exemple :
|
||||
|
||||
```text
|
||||
https://mainnet.helius-rpc.com/?api-key=${KS_SECRET_HELIUS_API_KEY}
|
||||
```
|
||||
|
||||
Le résultat complet doit être traité comme secret. La même règle s'applique aux DSN PostgreSQL et à toute autre composition.
|
||||
|
||||
Ordre de dominance prévu pour une valeur composée :
|
||||
|
||||
```text
|
||||
Secret > Internal/DebugOnly > Public
|
||||
```
|
||||
|
||||
Une représentation publique doit être construite explicitement à partir du runtime ; elle ne doit jamais provenir d'une sérialisation complète suivie d'une suppression opportuniste de champs.
|
||||
|
||||
### 2.3 Split de la configuration logging
|
||||
|
||||
Le split du logging n'est plus une question ouverte : `0.5.1` devra extraire le logging du document général dans **un document et un schéma JSON distincts**.
|
||||
|
||||
La cible minimale est donc :
|
||||
|
||||
- un document de configuration général ;
|
||||
- un document de configuration logging ;
|
||||
- un schéma JSON général ;
|
||||
- un schéma JSON logging.
|
||||
|
||||
Les profils généralistes et les profils logging doivent pouvoir évoluer indépendamment. Un profil réseau ne doit plus contenir une copie complète de toutes les routes logging.
|
||||
|
||||
D'autres documents spécialisés ne seront ajoutés que si l'audit de `0.5.1` démontre une responsabilité, une validation ou un cycle de vie suffisamment indépendant ; le split ne doit pas devenir une fragmentation systématique.
|
||||
|
||||
## 3. État réel de la configuration `0.4.8`
|
||||
|
||||
### 3.1 Taille et duplication
|
||||
|
||||
`config/example.config.json` représente environ 154 Ko.
|
||||
|
||||
Les trois profils actifs (`local_devnet`, `mainnet_research`, `mainnet`) embarquent chacun un bloc logging d'environ 23 à 24 Ko. Ensemble, ces blocs représentent environ **70 Ko** de configuration, soit une part disproportionnée du document général.
|
||||
|
||||
Les trois blocs ont la même structure et diffèrent principalement par :
|
||||
|
||||
- les noms de routes associés au profil ;
|
||||
- les chemins sous `logs/<profil>/...` ;
|
||||
- quelques valeurs de niveau ou de sélection liées au profil.
|
||||
|
||||
La séparation du logging est donc justifiée à la fois par la lisibilité, la maintenance et la réduction du couplage entre profil réseau et politique de tracing.
|
||||
|
||||
### 3.2 Contrat public actuel
|
||||
|
||||
`kb-config::ProfileConfig` contient directement :
|
||||
|
||||
```text
|
||||
app
|
||||
logging
|
||||
database
|
||||
data
|
||||
solana
|
||||
wallet
|
||||
execution
|
||||
demo
|
||||
```
|
||||
|
||||
`AppConfig`, `ProfileConfig` et toutes les sous-structures sont actuellement `Clone + Debug + Serialize + Deserialize + TS`.
|
||||
|
||||
Les fonctions publiques `serialize_config_json` et `serialize_config_json_pretty` peuvent sérialiser la configuration runtime complète. Après résolution d'environnement, cette configuration peut contenir des secrets en clair.
|
||||
|
||||
`DemoConfigPayload` clone aujourd'hui `AppConfig` et `ProfileConfig` complets et le frontend les affiche intégralement dans des JSON viewers avec copie activée. Cette surface doit disparaître dans `0.5.1` au profit d'un DTO public explicitement borné.
|
||||
|
||||
### 3.3 Consommateurs actuels
|
||||
|
||||
L'audit des onze crates confirme les principaux couplages suivants :
|
||||
|
||||
- `AppConfig` est consommé directement par le desktop et `kb-pipeline-demo-scenarios` ;
|
||||
- `ProfileConfig` traverse le desktop, `kb-onchain-transport`, `kb-pipeline-demo-scenarios` et certaines fixtures/tests de `kb-pipeline` ;
|
||||
- les types logging de `kb-config` ne sont convertis vers `kb-logging` que par le desktop aujourd'hui ; cette conversion constitue donc un adaptateur applicatif accidentel à supprimer ;
|
||||
- `kb-wallet` est consommé principalement par `kb-pipeline-demo-scenarios` et quelques adaptations desktop ; les scénarios utilisent directement `TemporaryWallet`, `TemporaryWalletStore`, `WalletAlias`, `WalletSummary`, `as_signer()` et `as_sync_signer()`.
|
||||
|
||||
Cette concentration permet de préparer des migrations bornées, mais `ProfileConfig` reste suffisamment diffus pour interdire un changement de shape sans phase de compatibilité/test.
|
||||
|
||||
### 3.4 Résolution d'environnement actuelle
|
||||
|
||||
`resolve_environment_placeholders` :
|
||||
|
||||
- accepte n'importe quel nom dans `${NAME}` ;
|
||||
- lit directement `std::env::var(name)` ;
|
||||
- retourne une `String` ordinaire ;
|
||||
- ne conserve ni origine, ni visibilité, ni indicateur de secret ;
|
||||
- peut donc transformer une URL ou un DSN contenant un secret en simple chaîne indistinguable d'une valeur publique.
|
||||
|
||||
Le futur resolver devra refuser les variables de projet hors namespace `KS_*` et conserver suffisamment de métadonnées pour empêcher la perte de sensibilité.
|
||||
|
||||
## 4. Inventaire des contrats d'environnement
|
||||
|
||||
L'audit du code, de `config/example.config.json`, de `.env.example` et des fichiers de fixture `.env` Token-2022 trouve **84 noms de variables/entrées de type environnement actuellement utilisés comme contrats actifs ou de fixture** :
|
||||
|
||||
- 67 commencent par `KB_` ;
|
||||
- 17 ne commencent ni par `KB_` ni par `KS_` ;
|
||||
- aucune n'utilise encore le namespace cible `KS_`.
|
||||
|
||||
Les variables non conformes comprennent notamment :
|
||||
|
||||
- `HELIUS_API_KEY` ;
|
||||
- les familles `TOKEN_2022_*` ;
|
||||
- des entrées de fixture ElGamal/validity proof.
|
||||
|
||||
Les guides opérateur contiennent en plus des variables shell historiques qui devront être réconciliées avec la même règle lors de la migration documentaire.
|
||||
|
||||
### 4.1 Secrets certains
|
||||
|
||||
Les contrats suivants doivent devenir explicitement secrets :
|
||||
|
||||
- `HELIUS_API_KEY` -> cible de famille `KS_SECRET_HELIUS_*` ;
|
||||
- `KB_POSTGRES_MAINNET_URL` -> cible `KS_SECRET_POSTGRES_MAINNET_URL` ;
|
||||
- `KB_POSTGRES_DEVNET_URL` -> cible `KS_SECRET_POSTGRES_DEVNET_URL` ;
|
||||
- `KB_POSTGRES_TEST_URL` -> cible `KS_SECRET_POSTGRES_TEST_URL`.
|
||||
|
||||
Une URL ou un DSN complet contenant l'un de ces secrets hérite de la classification `Secret` après résolution.
|
||||
|
||||
### 4.2 Variables internes
|
||||
|
||||
Les sélecteurs de profil, chemins, opt-ins de tests, confirmations opérateur, paramètres de campagnes et valeurs de fixture ne doivent pas être promus artificiellement en `KS_PUBLIC_*`. Par défaut, ils deviennent des `KS_*` internes.
|
||||
|
||||
`KS_PUBLIC_*` doit rester réservé aux valeurs dont une exposition publique est réellement requise et testée.
|
||||
|
||||
### 4.3 Migration
|
||||
|
||||
`0.5.1` devra fournir une table de migration exhaustive ancien nom -> nouveau nom avant changement du runtime et de `.env.example`.
|
||||
|
||||
La migration ne doit pas laisser le code lire durablement les anciens alias `KB_*`, `TOKEN_2022_*` ou `HELIUS_API_KEY`, car cela contredirait la règle du namespace unique. Si une compatibilité transitoire est nécessaire pendant une prerelease de migration, elle doit être explicitement bornée, détecter les conflits et être supprimée avant clôture de la version propriétaire.
|
||||
|
||||
## 5. Frontières source / runtime / public
|
||||
|
||||
Le futur contrat de `0.5.1` doit distinguer trois représentations conceptuelles.
|
||||
|
||||
### 5.1 Source
|
||||
|
||||
La représentation source conserve les documents utilisateur, les placeholders et les valeurs non résolues nécessaires à la validation/migration.
|
||||
|
||||
Elle ne doit pas être confondue avec un objet sûr à afficher.
|
||||
|
||||
### 5.2 Runtime
|
||||
|
||||
La représentation runtime contient les valeurs effectivement utilisables par les consommateurs backend.
|
||||
|
||||
Elle peut contenir des secrets résolus et ne doit donc pas dériver automatiquement une surface de sérialisation/TS-RS générale. Les champs sensibles connus doivent être encapsulés ou accompagnés d'une classification qui empêche `Debug`, sérialisation ou erreur accidentelle.
|
||||
|
||||
### 5.3 Public/diagnostic
|
||||
|
||||
Les DTO publics sont construits explicitement à partir du runtime :
|
||||
|
||||
- vue publique normale : uniquement les champs autorisés et valeurs `KS_PUBLIC_*` nécessaires ;
|
||||
- diagnostic explicite : peut ajouter des valeurs `KS_*` internes sélectionnées ;
|
||||
- secrets : jamais de valeur, uniquement un état non secret tel que `configured: true` lorsque cela apporte une valeur opérateur.
|
||||
|
||||
Le simple fait qu'une build Rust utilise `debug_assertions` ne doit pas élargir automatiquement la surface Tauri.
|
||||
|
||||
## 6. Propriété du contrat logging
|
||||
|
||||
### 6.1 Duplication actuelle
|
||||
|
||||
`kb-config` et `kb-logging` exposent chacun :
|
||||
|
||||
- `LoggingConfig` ;
|
||||
- `LogTargetConfig` ;
|
||||
- `LogTargetFilterConfig`.
|
||||
|
||||
Leurs champs sont pratiquement identiques. `kb-app-demo-desktop/src/app_state.rs` effectue une conversion champ par champ avant `kb_logging::init_logging`.
|
||||
|
||||
`kb-logging::LogFileRoute` n'a aucun consommateur actif hors de `kb-logging` et constitue un contrat legacy à réévaluer pendant la migration.
|
||||
|
||||
### 6.2 Direction de dépendance à préserver
|
||||
|
||||
`kb-config` ne doit pas dépendre du runtime logging simplement pour réutiliser ses types.
|
||||
|
||||
La solution de `0.5.1` devra choisir un propriétaire unique du contrat source logging et supprimer la conversion manuelle du desktop. Deux solutions restent architecturalement acceptables avant implémentation :
|
||||
|
||||
1. `kb-config` possède le DTO source logging séparé et `kb-logging` le consomme directement ou via un adaptateur propriétaire du runtime ;
|
||||
2. une frontière de configuration logging est déplacée dans une surface dédiée sans faire dépendre la configuration générale de l'initialisation `tracing`.
|
||||
|
||||
Le choix final doit minimiser la duplication sans réintroduire une crate artificielle si elle n'apporte pas de responsabilité autonome.
|
||||
|
||||
## 7. Audit `kb-wallet`
|
||||
|
||||
### 7.1 Points déjà solides
|
||||
|
||||
Le wallet actuel protège correctement plusieurs frontières :
|
||||
|
||||
- `TemporaryWallet` ne dérive ni `Serialize` ni `Clone` ;
|
||||
- son implémentation `Debug` n'affiche que l'alias, la clé publique et le chemin ;
|
||||
- les octets du keypair restent privés ;
|
||||
- les buffers temporaires de lecture/écriture sont zeroized ;
|
||||
- les fichiers existants ne sont pas écrasés ;
|
||||
- les liens symboliques et permissions trop ouvertes sont refusés ;
|
||||
- `as_signer()` et `as_sync_signer()` fournissent la capacité de signature sans exposer les octets.
|
||||
|
||||
### 7.2 Contrat persistant à migrer
|
||||
|
||||
Le format `0.4.8` est un contrat réel :
|
||||
|
||||
```text
|
||||
<alias>.json
|
||||
```
|
||||
|
||||
contient le tableau JSON standard du keypair Solana, sans enveloppe de version et sans chiffrement applicatif.
|
||||
|
||||
`0.5.2` devra donc traiter ce format comme **legacy importable**, et non le modifier in-place sans stratégie.
|
||||
|
||||
### 7.3 Exigences de migration `0.5.2`
|
||||
|
||||
Avant implémentation, le design devra préciser :
|
||||
|
||||
- format versionné du nouveau conteneur ;
|
||||
- détection sûre du format legacy ;
|
||||
- import sans perte de clé publique ;
|
||||
- écriture atomique du nouveau format avant suppression éventuelle de l'ancien ;
|
||||
- rollback après échec ;
|
||||
- corruption et mauvais secret de déverrouillage ;
|
||||
- séparation identité / secret / état verrouillé / capacité de signer ;
|
||||
- absence de secret dans config, logs, erreurs, Tauri et backup metadata ;
|
||||
- politique d'import/export et sauvegarde/restauration si ces capacités sont retenues.
|
||||
|
||||
Aucun mot de passe ou matériau de déchiffrement ne devra être stocké dans la configuration générale. Une automatisation non interactive éventuelle devra utiliser une source secrète dédiée, classée `KS_SECRET_*`.
|
||||
|
||||
## 8. Tests d'API externe manquants
|
||||
|
||||
Le workspace possède des tests d'API externe pour `kb-lib`, `kb-pipeline` et une partie de `kb-pipeline-demo-scenarios`, mais aucun dossier `tests/` équivalent pour `kb-config`, `kb-logging` ou `kb-wallet`.
|
||||
|
||||
Avant les refactors propriétaires, il faudra ajouter des tests de caractérisation externes couvrant au minimum :
|
||||
|
||||
### `kb-config`
|
||||
|
||||
- chargement du format `0.4.8` de référence ;
|
||||
- profil actif et invariants publics ;
|
||||
- contrat de schéma embarqué ;
|
||||
- migration vers les documents séparés ;
|
||||
- refus des variables de projet hors `KS_*` ;
|
||||
- canaris `KS_SECRET_*` absents de toute vue publique, erreur et diagnostic.
|
||||
|
||||
Ces tests ne doivent pas figer la sérialisation dangereuse actuelle d'une configuration résolue complète.
|
||||
|
||||
### `kb-logging`
|
||||
|
||||
- initialisation depuis le futur contrat source canonique ;
|
||||
- conservation des routes/niveaux/filtres/formats ;
|
||||
- migration sans dépendance au desktop.
|
||||
|
||||
### `kb-wallet`
|
||||
|
||||
- lecture d'une fixture legacy `0.4.8` ;
|
||||
- identité de clé publique après migration ;
|
||||
- corruption, permissions et atomicité ;
|
||||
- absence de secret dans `Debug` et surfaces publiques ;
|
||||
- tests de lock/unlock seulement après choix du format chiffré.
|
||||
|
||||
## 9. Audit du possible renommage `kb-*` -> `ks-*`
|
||||
|
||||
La demande de namespace `KS_` pour l'environnement ouvre légitimement la question du nom des crates généralistes. Cette question ne doit cependant pas être traitée par remplacement global.
|
||||
|
||||
### 9.1 Crates candidates
|
||||
|
||||
Les responsabilités actuelles rendent les crates suivantes plausiblement généralistes Solana et donc candidates à un préfixe `ks-*` si le renommage est retenu :
|
||||
|
||||
- `kb-core` ;
|
||||
- `kb-config` ;
|
||||
- `kb-lib` ;
|
||||
- `kb-logging` ;
|
||||
- `kb-program-ids` ;
|
||||
- `kb-pipeline` ;
|
||||
- `kb-onchain-transport` ;
|
||||
- `kb-store` ;
|
||||
- `kb-wallet`.
|
||||
|
||||
`kb-pipeline-demo-scenarios` doit être classée séparément : sa logique est réutilisable et non spécifique au frontend, mais son rôle de validation/scénarios peut justifier un nom différent de la simple substitution de préfixe.
|
||||
|
||||
`kb-app-demo-desktop` reste clairement une application Khadhroony Bot et n'est pas candidate au même renommage automatique.
|
||||
|
||||
### 9.2 Namespaces à ne pas confondre
|
||||
|
||||
Un éventuel renommage de packages Cargo touche plusieurs espaces de noms distincts :
|
||||
|
||||
1. nom de répertoire ;
|
||||
2. nom `[package]` Cargo ;
|
||||
3. identifiant Rust (`kb_config` -> éventuellement `ks_config`) ;
|
||||
4. chemins TS-RS/bindings ;
|
||||
5. targets `tracing` ;
|
||||
6. noms de binaires/CLI ;
|
||||
7. identités persistées de décodeurs, matérialiseurs et exécuteurs ;
|
||||
8. préfixes SQL et noms de tables.
|
||||
|
||||
Ces couches ne doivent pas être renommées en bloc.
|
||||
|
||||
En particulier :
|
||||
|
||||
- les tables `kb_sol_*` sont des contrats SQL publiés et ne doivent pas changer de nom du seul fait d'un renommage Cargo ;
|
||||
- les identités telles que `kb-lib.decoder.*`, `kb-lib.materializer.*` et `kb-lib.executor.*` peuvent être persistées dans le ledger, les événements ou les clés d'idempotence ; leur changement exige un audit de migration propre ;
|
||||
- les targets `tracing` peuvent être renommés séparément, mais cela impose une migration du document logging et de ses filtres.
|
||||
|
||||
### 9.3 Décision à prendre avant implémentation structurelle
|
||||
|
||||
Avant de lancer `0.5.1`, la clôture de `0.5.0` devra statuer sur l'une des stratégies suivantes :
|
||||
|
||||
- conserver `kb-*` comme namespace historique pour toutes les crates ;
|
||||
- renommer uniquement les packages/libs réellement généralistes en `ks-*`, en laissant les applications `kb-*` ;
|
||||
- planifier un chantier de renommage dédié dans le ROADMAP si l'impact est trop transversal pour être absorbé proprement par `0.5.1`.
|
||||
|
||||
Aucun renommage n'est livré par `pre.002`.
|
||||
|
||||
## 10. Dossier de migration préparé pour `0.5.1`
|
||||
|
||||
`0.5.1` devra au minimum :
|
||||
|
||||
1. introduire le namespace `KS_*` et la classification Secret/Public/Internal ;
|
||||
2. fournir la table exhaustive de renommage des variables actuelles ;
|
||||
3. remplacer le resolver non typé par une résolution conservant la sensibilité ;
|
||||
4. séparer la configuration générale et la configuration logging en deux documents et deux schémas ;
|
||||
5. supprimer `logging` de chaque `ProfileConfig` généraliste ;
|
||||
6. rendre la sélection du profil logging indépendante du profil général ;
|
||||
7. supprimer la duplication de types logging ou la conversion manuelle desktop ;
|
||||
8. séparer source, runtime et DTO publics/diagnostics ;
|
||||
9. retirer `AppConfig`/`ProfileConfig` complets des payloads Tauri ;
|
||||
10. ajouter les tests de migration `0.4.8` -> nouveau format et les canaris de non-divulgation.
|
||||
|
||||
Le détail des noms de fichiers et types Rust sera fixé dans la première prerelease d'implémentation de `0.5.1`, après décision sur le namespace de crates.
|
||||
|
||||
## 11. Dossier de migration préparé pour `0.5.2`
|
||||
|
||||
`0.5.2` devra :
|
||||
|
||||
1. caractériser le format legacy `0.4.8` par fixture externe ;
|
||||
2. définir un conteneur wallet versionné avant chiffrement ;
|
||||
3. séparer identité, secret, état de verrouillage et capacité de signer ;
|
||||
4. définir migration/rollback atomiques ;
|
||||
5. conserver les capacités `Signer` nécessaires aux exécuteurs sans exposer le secret ;
|
||||
6. interdire toute propagation de secret vers config/logging/Tauri ;
|
||||
7. ajouter import/export, backup/restore et multi-wallet uniquement avec contrats de sécurité et tests correspondants.
|
||||
|
||||
## 12. Critère de sortie de `pre.002`
|
||||
|
||||
La prerelease peut être considérée comme cadrée lorsque :
|
||||
|
||||
- le split logging document + schéma séparés est accepté comme cible ;
|
||||
- la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` est normative pour la migration ;
|
||||
- la propagation de sensibilité des valeurs composées est requise ;
|
||||
- les surfaces source/runtime/public sont distinctes ;
|
||||
- le format wallet legacy et sa stratégie de migration sont explicitement bornés ;
|
||||
- les tests externes manquants sont identifiés ;
|
||||
- le possible renommage `kb-*` -> `ks-*` est isolé comme décision transversale, sans toucher les identités persistées ou SQL par accident.
|
||||
|
||||
La prochaine prerelease prévue reste `0.5.0-pre.003`, consacrée à `kb-store`, aux scénarios et au desktop.
|
||||
@@ -0,0 +1,367 @@
|
||||
<!-- file: docs/plans/V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Audit `0.5.0-pre.003` — store, scénarios, desktop et complétude d'exécution
|
||||
|
||||
## 1. Objet et frontière
|
||||
|
||||
`0.5.0-pre.003` reste une prerelease de cadrage. Elle n'introduit ni nouvelle migration SQL, ni table trading, ni nouvel exécuteur, ni déplacement de logique runtime.
|
||||
|
||||
Elle ferme quatre sujets nécessaires avant les versions d'implémentation :
|
||||
|
||||
- état réel de `kb-store` et contraintes de migration vers `0.5.3` ;
|
||||
- frontière entre scénarios réutilisables et adaptation desktop en préparation de `0.5.4` ;
|
||||
- état de complétude réel des décodeurs/exécuteurs déjà actifs ;
|
||||
- positionnement du futur namespace `ks-*` dans la fondation `0.5.x`.
|
||||
|
||||
Les migrations `kb-store/migrations/0001` à `0004` restent immuables. Les preuves réseau `0.4.8` ne sont pas rejouées puisque cette prerelease ne modifie aucune frontière qu'elles couvrent.
|
||||
|
||||
## 2. Positionnement de la fondation `ks-*`
|
||||
|
||||
L'orientation de projet est désormais la suivante :
|
||||
|
||||
- **Khadhroony Project** est destiné à devenir l'umbrella de plusieurs projets liés au trading et aux crypto-actifs ;
|
||||
- **Khadhroony Solana** regroupe les bibliothèques généralistes dédiées à Solana ;
|
||||
- ces bibliothèques doivent converger vers les namespaces Cargo `ks-*`, Rust `ks_*` et environnement `KS_*` ;
|
||||
- **Khadhroony Bot / bot3** devient l'application de trading consommatrice de ces bibliothèques, avec à terme une partie d'analyse/création de stratégies et un exécutable de trading automatique ;
|
||||
- `kb-app-demo-desktop` reste pour l'instant un banc opérateur de démonstration et de validation des composants généralistes ; il ne préjuge pas de l'architecture applicative finale du bot après `1.0`.
|
||||
|
||||
Cette orientation générale est aussi conservée dans `docs/IDEA_REMINDERS.md`. Le renommage concret des bibliothèques généralistes est préparé pour `0.5.1`, mais les identités persistées et SQL sont traitées séparément.
|
||||
|
||||
### 2.1 Candidats au namespace `ks-*`
|
||||
|
||||
Les crates suivantes sont des bibliothèques ou composants de support Solana généralistes et sont donc candidates au renommage direct en `0.5.1` :
|
||||
|
||||
| Actuel | Cible de travail |
|
||||
|---|---|
|
||||
| `kb-core` | `ks-core` |
|
||||
| `kb-config` | `ks-config` |
|
||||
| `kb-lib` | `ks-lib` |
|
||||
| `kb-logging` | `ks-logging` |
|
||||
| `kb-program-ids` | `ks-program-ids` |
|
||||
| `kb-pipeline` | `ks-pipeline` |
|
||||
| `kb-onchain-transport` | `ks-onchain-transport` |
|
||||
| `kb-store` | `ks-store` |
|
||||
| `kb-wallet` | `ks-wallet` |
|
||||
| `kb-pipeline-demo-scenarios` | `ks-pipeline-demo-scenarios` à confirmer comme composant de validation Khadhroony Solana |
|
||||
|
||||
`kb-app-demo-desktop` reste hors de cette substitution automatique : c'est une application Khadhroony Bot, même si son rôle courant est surtout de tester les composants `ks-*`.
|
||||
|
||||
### 2.2 Ce qui ne doit pas suivre mécaniquement le renommage
|
||||
|
||||
Le changement de nom d'une crate ne justifie pas à lui seul de modifier :
|
||||
|
||||
- les tables SQL `kb_sol_*` déjà publiées ;
|
||||
- les clés d'idempotence existantes ;
|
||||
- les identités de processeurs persistées ;
|
||||
- les noms historiques `kb-lib.decoder.*`, `kb-lib.materializer.*` et `kb-lib.executor.*` lorsqu'ils sont enregistrés dans le store ;
|
||||
- les données déjà persistées dans le processing ledger ;
|
||||
- les identités de validation historiques présentes dans les preuves `0.4.x`.
|
||||
|
||||
Les targets de tracing peuvent être renommés avec les crates, mais uniquement avec une migration synchronisée du futur document logging et de ses filtres.
|
||||
|
||||
## 3. Audit actuel de `kb-store`
|
||||
|
||||
### 3.1 Structure et contrats publiés
|
||||
|
||||
`kb-store` possède déjà une séparation interne exploitable :
|
||||
|
||||
- `contracts/dto/*` pour les entrées et filtres ;
|
||||
- `contracts/entity/*` pour les lignes persistées ;
|
||||
- `contracts/repository.rs` pour les frontières async ;
|
||||
- `postgres/query/*` pour le SQL ;
|
||||
- `postgres/repository/*` pour les implémentations ;
|
||||
- `postgres/migrations.rs` et quatre migrations SQL publiées.
|
||||
|
||||
Le schéma actif contient **13 tables** :
|
||||
|
||||
- 2 raw/observation ;
|
||||
- 6 Core ;
|
||||
- 1 processing ledger ;
|
||||
- 3 tables decode/coverage ;
|
||||
- 1 table de matérialisation générique.
|
||||
|
||||
La crate expose neuf familles principales de repository : health, raw, Core transaction, Core extraction, decode pipeline, observation de programme, événements décodés, événements matérialisés et processing ledger.
|
||||
|
||||
La structure n'est donc pas à remplacer. `0.5.3` doit normaliser ce qui gêne les futures requêtes et réduire les gros modules internes lorsque cela améliore la lisibilité, tout en conservant les façades publiques tant qu'une rupture n'est pas justifiée.
|
||||
|
||||
### 3.2 Propriétés déjà solides
|
||||
|
||||
Plusieurs contrats doivent être conservés :
|
||||
|
||||
- signature comme identité canonique de transaction raw ;
|
||||
- slot explicitement séparé des timestamps ;
|
||||
- observation d'acquisition distincte de la transaction canonique ;
|
||||
- provenance d'acquisition détaillée (`provider`, protocole, méthode, origin, session, filtre) ;
|
||||
- timestamps locaux d'acquisition distincts (`detected_at`, `received_at`, `normalized_at`, `persisted_at`) ;
|
||||
- identités de processeur et versions explicites ;
|
||||
- `input_key`, `input_hash`, `event_key` et `output_key` pour l'idempotence ;
|
||||
- transactions atomiques decode/materialization ;
|
||||
- index uniques empêchant le double effet d'un même processeur/version/input/output ;
|
||||
- conversion bornée `u64` vers `BIGINT` avec refus des valeurs non représentables ;
|
||||
- JSON canonique raw conservant actuellement le `block_time` même lorsque celui-ci n'est pas une colonne SQL de premier rang.
|
||||
|
||||
### 3.3 Lacune temporelle réelle
|
||||
|
||||
Le modèle canonique `MdCanonicalTransaction` contient :
|
||||
|
||||
```text
|
||||
slot
|
||||
block_time: Option<i64>
|
||||
```
|
||||
|
||||
et le transport HTTP conserve cette valeur depuis `getTransaction`.
|
||||
|
||||
En revanche :
|
||||
|
||||
- `kb_sol_raw_transactions` possède `slot`, `created_at`, `updated_at`, mais pas `block_time` ;
|
||||
- `kb_sol_core_transactions` et les tables Core portent `slot` et des timestamps de persistance, mais pas le temps on-chain ;
|
||||
- `kb_sol_decode_events` et `kb_sol_mat_events` portent `slot`, mais pas `block_time` ;
|
||||
- les observations d'acquisition ont des timestamps locaux riches, ce qui ne remplace pas le temps on-chain.
|
||||
|
||||
Le contrat `0.5.3` doit donc imposer la distinction suivante :
|
||||
|
||||
| Dimension | Sens |
|
||||
|---|---|
|
||||
| `slot` | ordre/position Solana ; jamais assimilé à un temps civil |
|
||||
| `block_time` | temps on-chain Unix optionnel observé depuis le cluster |
|
||||
| `detected_at` / `received_at` / `normalized_at` | temps locaux d'acquisition |
|
||||
| `persisted_at` | instant d'écriture de l'observation |
|
||||
| `created_at` / `updated_at` | cycle de vie de la ligne SQL |
|
||||
|
||||
Une requête de prix ou série temporelle ne doit jamais prendre `created_at` comme substitut implicite de `block_time`.
|
||||
|
||||
### 3.4 Limites de la matérialisation générique pour le futur trading
|
||||
|
||||
`kb_sol_mat_events` est aujourd'hui volontairement générique. Il contient notamment :
|
||||
|
||||
- identité/version du matérialiseur ;
|
||||
- identité de l'input et de l'output ;
|
||||
- provenance vers l'événement décodé ;
|
||||
- signature et slot ;
|
||||
- `materialized_family` ;
|
||||
- `payload_jsonb`.
|
||||
|
||||
Ce contrat est adapté au replay et à l'audit, mais il ne suffit pas encore à des requêtes trading efficaces. Il manque en colonnes de premier rang plusieurs dimensions qui pourront être nécessaires selon le contrat de faits retenu :
|
||||
|
||||
- temps on-chain ;
|
||||
- programme/surface/event d'origine ;
|
||||
- identités d'entités métier stables ;
|
||||
- actifs concernés ;
|
||||
- pool/market/route lorsqu'ils existent ;
|
||||
- dimensions permettant des index temporels multi-entités.
|
||||
|
||||
Il ne faut pas résoudre ce manque par une accumulation d'index JSONB spécifiques à Meteora/Raydium/Pump/Orca/Jupiter. `0.5.3` doit d'abord définir **l'enveloppe stable des faits produits par les matérialisateurs**.
|
||||
|
||||
### 3.5 Faits stables à spécifier avant toute table trading
|
||||
|
||||
La spécification `0.5.3` doit déterminer comment représenter, indépendamment du protocole :
|
||||
|
||||
- création et identité d'un pool/marché ;
|
||||
- paire ou ensemble d'actifs ;
|
||||
- comptes de réserve et état de réserves observé ;
|
||||
- ajout/retrait/variation de liquidité ;
|
||||
- swap avec actifs entrée/sortie et montants bruts ;
|
||||
- prix observé avec unité et base de calcul explicites ;
|
||||
- snapshot d'état et événement de mutation ;
|
||||
- relation d'un fait à plusieurs pools ou à une route ;
|
||||
- provenance complète jusqu'à signature, slot, `block_time`, instruction et processeur ;
|
||||
- clé d'idempotence stable par projection.
|
||||
|
||||
Les tables spécialisées ne seront choisies qu'après ce contrat. Le but est d'autoriser des matérialisateurs futurs pour plusieurs DEX sans figer leur wire ou leur architecture dans `ks-store`.
|
||||
|
||||
### 3.6 Migrations et tests à préparer pour `0.5.3`
|
||||
|
||||
Les migrations `0001` à `0004` sont publiées et ne doivent jamais être réécrites.
|
||||
|
||||
Avant toute migration `0005+`, il faut :
|
||||
|
||||
1. un test d'API externe de `kb-store` caractérisant les principaux DTO/repositories actuels ;
|
||||
2. une fixture de schéma `0.4.8` permettant de tester la migration réelle ;
|
||||
3. une politique de backfill de `block_time` explicitant que la valeur peut rester inconnue ;
|
||||
4. des tests d'idempotence sur une migration réexécutée ;
|
||||
5. des tests de données existantes et de rollback/échec ;
|
||||
6. une justification de chaque nouvel index par une requête cible ;
|
||||
7. un test prouvant que `created_at` et `block_time` ne sont pas interchangeables ;
|
||||
8. une décision sur le maintien de `kb_sol_mat_events` comme journal générique parallèlement aux futures projections normalisées.
|
||||
|
||||
Aucune modification SQL n'est livrée dans `pre.003`.
|
||||
|
||||
## 4. Audit scénarios / desktop
|
||||
|
||||
### 4.1 Frontière normative corrigée
|
||||
|
||||
Une ancienne règle disait que les scénarios UI Devnet/Testnet devaient rester dans le desktop. Cette formulation est devenue trop large et contredit la trajectoire `0.5.4`.
|
||||
|
||||
La frontière retenue est désormais :
|
||||
|
||||
- orchestration générique : `kb-pipeline` ;
|
||||
- fixture, séquence, simulation/soumission, postconditions et qualification réutilisables de Devnet/Testnet : `kb-pipeline-demo-scenarios` ;
|
||||
- état Tauri, sélection opérateur, progression UI, TS-RS et présentation : `kb-app-demo-desktop`.
|
||||
|
||||
Un preset purement visuel ou une séquence réellement spécifique à une interaction UI peut rester dans le desktop, mais une campagne réutilisable ne doit pas y avoir une seconde implémentation.
|
||||
|
||||
### 4.2 État réel de la couverture des exécuteurs actifs
|
||||
|
||||
L'inventaire statique de `kb-lib` trouve :
|
||||
|
||||
- **8 exécuteurs fonctionnels non réservés** ;
|
||||
- **103 exécuteurs réservés** servant de placeholders de surfaces futures ;
|
||||
- les placeholders ne sont pas des exécuteurs manquants à compléter en `0.5.0`.
|
||||
|
||||
Les huit exécuteurs actifs sont :
|
||||
|
||||
| Exécuteur actif | Scénario réutilisable actuel | Qualification |
|
||||
|---|---|---|
|
||||
| Solana Core | oui | plusieurs parcours Devnet ; matrice native existante |
|
||||
| SPL Memo v4 | oui | Devnet ; v1/v3 restent decode-only |
|
||||
| SPL Associated Token Account | oui | scénario Devnet |
|
||||
| SPL Token classique | oui | scénarios et lifecycle Devnet |
|
||||
| SPL Token-2022 | oui | scénarios Devnet et campagne Token Metadata |
|
||||
| SPL ElGamal registry | non | implémenté + synthétique seulement ; preuve réseau indisponible |
|
||||
| Metaplex Token Metadata | oui | matrice `15 confirmed / 5 unavailable` |
|
||||
| Solana Program Metadata | oui | 9 opérations confirmées Devnet |
|
||||
|
||||
Le seul exécuteur actif sans scénario réseau réutilisable est donc ElGamal, et son absence est **`unavailable`/report conditionnel**, pas `implement`, tant qu'une nouvelle possibilité de preuve n'existe pas.
|
||||
|
||||
Deux autres exclusions importantes restent intentionnelles :
|
||||
|
||||
- Memo v1 et v3 : `decode-only` ;
|
||||
- Token-2022 `Batch` : `decode-only` tant que l'interface officielle ne publie pas de builder correspondant.
|
||||
|
||||
Les 103 exécuteurs réservés appartiennent aux surfaces futures du ROADMAP. Ils doivent être classés `deferred`, sauf audit futur démontrant qu'une surface est obsolète, non applicable ou doit changer de statut.
|
||||
|
||||
### 4.3 Le desktop n'instancie plus directement les exécuteurs actifs
|
||||
|
||||
Aucune des huit structures d'exécuteur actives n'est directement instanciée dans `kb-app-demo-desktop/src`.
|
||||
|
||||
C'est une bonne frontière : le desktop appelle déjà `kb-pipeline-demo-scenarios` pour l'exécution réseau. `0.5.4` ne doit donc pas entreprendre une réécriture totale du desktop ; il doit cibler les morceaux d'orchestration qui restent autour de ces runners.
|
||||
|
||||
### 4.4 Orchestration encore résiduelle dans le desktop
|
||||
|
||||
Les principaux candidats identifiés sont :
|
||||
|
||||
#### Metaplex Token Metadata
|
||||
|
||||
`demo_execution_metadata_metaplex_token_metadata.rs` reste très volumineux et contient encore :
|
||||
|
||||
- inventaire/presets de campagnes qualifiées ;
|
||||
- préparation conditionnelle de fixtures ;
|
||||
- dispatch d'une campagne vers plusieurs runners réutilisables ;
|
||||
- calcul de critères `completed` ;
|
||||
- classification de probes confirmées/unavailable ;
|
||||
- construction de projections intermédiaires avant mapping UI.
|
||||
|
||||
La sérialisation TS-RS et la présentation JSON doivent rester desktop. Le dispatch, les critères de complétion et la projection de preuve commune sont candidats à `kb-pipeline-demo-scenarios` en `0.5.4`.
|
||||
|
||||
#### Solana Core, Memo, ATA, Token classique et Token-2022
|
||||
|
||||
Les runners réutilisables acceptent encore, selon les cas, des slices de décodeurs et matérialisateurs fournis par l'appelant. Le desktop assemble donc lui-même une partie de la pile de validation attendue.
|
||||
|
||||
`0.5.4` devra déterminer si la crate scénario doit fournir des bundles qualifiés par défaut, par exemple une composition canonique de décodeurs/matérialisateurs pour un scénario donné, afin que le desktop n'ait pas à connaître cette composition.
|
||||
|
||||
Le desktop peut continuer à :
|
||||
|
||||
- choisir un profil ;
|
||||
- demander l'autorisation opérateur ;
|
||||
- ouvrir la connexion/store via l'état applicatif lorsqu'il s'agit d'une responsabilité d'application ;
|
||||
- fournir un observer de progression/annulation ;
|
||||
- mapper le résultat vers un DTO TS-RS.
|
||||
|
||||
Il ne doit pas être le propriétaire de la liste métier exacte de décodeurs/matérialisateurs requise pour qualifier une campagne réutilisable.
|
||||
|
||||
#### Token-2022 Metadata et Solana Program Metadata
|
||||
|
||||
Ces panneaux sont déjà proches de la cible : ils appellent une campagne réutilisable et transforment principalement son résultat pour le frontend. Ils servent de référence pour la réduction des autres panneaux.
|
||||
|
||||
#### Journaux SQL et diagnostics
|
||||
|
||||
Les requêtes de journal et les filtres destinés à l'affichage ne sont pas automatiquement des « scénarios ». Ils peuvent rester dans le desktop tant qu'ils ne dupliquent pas une règle métier ou une requête générique qui devrait appartenir à `kb-store`.
|
||||
|
||||
## 5. Méthode de complétude à appliquer en `0.5.4`
|
||||
|
||||
La future matrice transversale doit comparer uniquement les **surfaces actives ou explicitement ouvertes par le ROADMAP**. La présence d'un fichier réservé ne suffit pas à créer une dette.
|
||||
|
||||
Pour chaque capacité, enregistrer :
|
||||
|
||||
| Dimension | Valeur attendue |
|
||||
|---|---|
|
||||
| decoder | actif / réservé / absent |
|
||||
| materializer | actif / state-only / réservé / non applicable |
|
||||
| executor | actif / decode-only / deprecated / réservé / absent |
|
||||
| synthetic | présent / absent / non applicable |
|
||||
| reusable scenario | présent / absent / unavailable / non applicable |
|
||||
| simulation | prouvée / non exécutée / unavailable |
|
||||
| submission | confirmed / non exécutée / unsafe / unavailable |
|
||||
| postcondition | stateful / replay/materialization / non applicable |
|
||||
| desktop | adaptateur / logique réutilisable résiduelle / absent |
|
||||
| final status | `implement`, `decode-only`, `deprecated`, `unavailable`, `not-applicable`, `deferred` |
|
||||
|
||||
### Classification actuelle de départ
|
||||
|
||||
- huit exécuteurs actifs : aucun « exécuteur manquant » de niveau surface ;
|
||||
- Memo v1/v3 : `decode-only` ;
|
||||
- Token-2022 Batch : `decode-only` ;
|
||||
- ElGamal réseau : `unavailable` tant qu'aucune nouvelle preuve n'est possible ;
|
||||
- 103 exécuteurs réservés : `deferred` par défaut selon les versions `0.6.x+` ;
|
||||
- scénarios desktop avec orchestration résiduelle : `implement` en `0.5.4` uniquement pour le déplacement de logique réutilisable, pas pour rejouer des campagnes déjà qualifiées.
|
||||
|
||||
## 6. Validations réseau à ne pas rejouer automatiquement
|
||||
|
||||
Cette prerelease ne modifie aucune frontière d'exécution. Il n'y a donc pas de raison de rejouer :
|
||||
|
||||
- les 9 opérations Solana Program Metadata ;
|
||||
- les 5 opérations Token-2022 Token Metadata ;
|
||||
- les 15 opérations Metaplex confirmées ;
|
||||
- les probes Metaplex déjà classées `unavailable` ;
|
||||
- les validations SPL/Core qui ne changent pas de contrat.
|
||||
|
||||
En `0.5.4`, un rerun réseau ne devient nécessaire que si le déplacement d'un scénario change réellement :
|
||||
|
||||
- la construction d'intent ;
|
||||
- l'ordre des instructions ;
|
||||
- les signers/comptes ;
|
||||
- les paramètres de simulation/soumission ;
|
||||
- les postconditions ;
|
||||
- la composition decoder/materializer utilisée pour la preuve.
|
||||
|
||||
Un simple déplacement de mapping TS-RS ou de dispatch sans changement sémantique doit être couvert par tests synthétiques/contractuels et comparaison de sortie, pas par dépense réseau systématique.
|
||||
|
||||
## 7. Dossiers préparés pour les versions suivantes
|
||||
|
||||
### `0.5.1`
|
||||
|
||||
- migration `KB_*`/variables historiques vers `KS_*` ;
|
||||
- split configuration générale / logging ;
|
||||
- protection Secret/Public/Internal ;
|
||||
- renommage coordonné des crates généralistes `kb-*` vers `ks-*` ;
|
||||
- adaptation des imports Rust, manifests, bindings, targets de tracing et documentation ;
|
||||
- maintien ou migration séparée des identités persistées et tables SQL.
|
||||
|
||||
### `0.5.3`
|
||||
|
||||
- contrat temporel incluant `block_time` ;
|
||||
- enveloppe de provenance des faits ;
|
||||
- définition des projections trading génériques ;
|
||||
- nouvelle migration seulement après caractérisation `0.4.8` ;
|
||||
- index justifiés par les requêtes cibles multi-pools/multi-routes.
|
||||
|
||||
### `0.5.4`
|
||||
|
||||
- centralisation de l'orchestration réutilisable restante ;
|
||||
- composition qualifiée decoder/materializer par scénario lorsque justifiée ;
|
||||
- matrice de complétude active/réservée ;
|
||||
- conservation du desktop comme adaptateur opérateur.
|
||||
|
||||
## 8. Critère de sortie de `pre.003`
|
||||
|
||||
`pre.003` peut être considérée comme cadrée lorsque :
|
||||
|
||||
- le modèle temporel du store distingue sans ambiguïté temps on-chain et temps de persistance ;
|
||||
- aucune table DEX n'est inventée avant le contrat de faits ;
|
||||
- les migrations `0001` à `0004` restent explicitement immuables ;
|
||||
- la frontière scénario réutilisable / desktop est corrigée dans les règles actives ;
|
||||
- les huit exécuteurs réellement actifs et leurs niveaux de scénario/preuve sont caractérisés ;
|
||||
- ElGamal reste une exception conditionnelle et non une tâche implicite ;
|
||||
- le renommage des bibliothèques généralistes vers `ks-*` est retenu comme partie de `0.5.1`, avec exclusion des migrations SQL/identités persistées automatiques ;
|
||||
- `0.5.0-pre.004` peut se concentrer sur réconciliation, décisions finales, validations et préparation du prompt `0.5.1`.
|
||||
@@ -0,0 +1,234 @@
|
||||
<!-- file: prompts/029_v0_5_0_foundation_restructuring_plan.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompt de session — 0.5.0 cadrage de la fondation `0.5.x`
|
||||
|
||||
## Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture validée de `0.4.8` et préparer la série `0.5.x` consacrée à la fondation du workspace avant l’ouverture des grands programmes Anchor/DEX.
|
||||
|
||||
`0.5.0` doit commencer par un audit et un plan complet. Il ne faut pas lancer immédiatement une restructuration de `kb-config`, `kb-wallet` ou `kb-store` sans avoir vérifié les frontières actuelles, les contrats publics, les schémas, les tests et les dépendances du workspace.
|
||||
|
||||
La trajectoire cible est :
|
||||
|
||||
- `0.5.1` : restructuration de `kb-config` et contrats de configuration ;
|
||||
- `0.5.2` : restructuration de `kb-wallet` ;
|
||||
- `0.5.3` : audit et normalisation de `kb-store` en préparation des matérialisations trading/routing ;
|
||||
- `0.5.4` : centralisation des scénarios dans `kb-pipeline-demo-scenarios` et audit des exécuteurs/validations manquants.
|
||||
|
||||
La première prerelease de `0.5.0` doit produire le plan temporaire de la version et le découpage détaillé des prereleases avant tout changement structurel important.
|
||||
|
||||
## Base validée à préserver
|
||||
|
||||
La release `0.4.8` ferme :
|
||||
|
||||
- Solana Program Metadata comme surface indépendante, avec neuf opérations confirmées sur Devnet ;
|
||||
- les cinq opérations Token-2022 Token Metadata confirmées sur Devnet ;
|
||||
- la matrice courante Metaplex Token Metadata à 15 `confirmed`, 5 `unavailable`, 0 `not_run` ;
|
||||
- les scénarios Metadata réutilisables dans `kb-pipeline-demo-scenarios` et leur intégration desktop ;
|
||||
- la réconciliation des matrices, exports, registres runtime, IDL, stockage générique et documentation Metadata ;
|
||||
- la validation finale du workspace par formatage, check, Clippy, audit et `cargo test --workspace` ;
|
||||
- le build desktop de release par `cargo tauri build`, produisant les bundles Linux prévus.
|
||||
|
||||
Le registre ElGamal reste une exception connue : implémenté et validé synthétiquement, sans preuve réseau réelle disponible. Ne pas convertir cette exception en tâche implicite de `0.5.0` sans nouvelle possibilité de validation.
|
||||
|
||||
## Lectures obligatoires avant toute proposition
|
||||
|
||||
1. `README.md`, `ROADMAP.md`, `CHANGELOG.md`, `RULES.md` et ce prompt ;
|
||||
2. toutes les règles actives sous `docs/rules/`, en particulier :
|
||||
- `RULES_GENERAL.md` ;
|
||||
- `RULES_RUST.md` ;
|
||||
- `RULES_SPECIFIC_KHADHROONY.md` ;
|
||||
- `CRATE_DOCUMENTATION_RULES.md` ;
|
||||
- `VERSION_DEVELOPMENT_LIFECYCLE.md` ;
|
||||
3. `README.md`, `USAGE.md`, `TODO.md` et `CHANGELOG.md` de chaque crate directement concernée ;
|
||||
4. les documents d’architecture et de stockage actifs ;
|
||||
5. les schémas, exemples de configuration, migrations SQL, matrices contractuelles et tests existants ;
|
||||
6. les prompts archivés `027` et `028` uniquement comme références de méthode et d’historique, jamais comme source prioritaire sur le code actuel.
|
||||
|
||||
Avant de modifier un contrat public, vérifier son usage réel dans les onze crates et les tests d’API externe.
|
||||
|
||||
## Règles de développement à conserver
|
||||
|
||||
- Rust 2024 ;
|
||||
- aucune utilisation de `unsafe`, `unwrap`, `expect` ou `panic` dans le code de production ;
|
||||
- imports réservés aux traits nécessaires, chemins explicites pour les autres symboles ;
|
||||
- respect des en-têtes `file:` / `version:` et incrément des versions locales des fichiers modifiés ;
|
||||
- documentation Rust en anglais, documentation Markdown en français ;
|
||||
- aucune ligne vide interne artificielle dans les fonctions Rust et exactement une newline en fin de fichier ;
|
||||
- aucune logique métier nouvelle dans `kb-app-demo-desktop` lorsqu’elle peut résider dans une crate réutilisable ;
|
||||
- les commandes Tauri restent des adaptateurs minces et n’utilisent ni `?` ni unwrap ;
|
||||
- les archives sous `olddocs/` ne sont jamais réécrites hors opération d’archivage explicitement demandée.
|
||||
|
||||
## Règle frontend/Tauri obligatoire
|
||||
|
||||
Ne jamais lancer directement :
|
||||
|
||||
```text
|
||||
npm run dev
|
||||
npm run build
|
||||
npm --prefix kb-app-demo-desktop run build
|
||||
```
|
||||
|
||||
Les commandes npm manuelles sont limitées à l’installation explicite de dépendances nécessaires, notamment `npm i` et `npm i -D`.
|
||||
|
||||
Le développement desktop est piloté par :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Le build de release est piloté par :
|
||||
|
||||
```bash
|
||||
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Tauri déclenche lui-même les scripts frontend configurés. Le `dist` Vite et `frontendDist` Tauri doivent continuer à désigner le même répertoire de sortie du workspace.
|
||||
|
||||
## Première prerelease obligatoire de `0.5.0`
|
||||
|
||||
La première prerelease est exclusivement consacrée au plan et au brainstorming. Elle doit :
|
||||
|
||||
- inventorier les responsabilités et couplages de `kb-config`, `kb-logging`, `kb-wallet`, `kb-store`, `kb-pipeline-demo-scenarios` et `kb-app-demo-desktop` ;
|
||||
- identifier les contrats publics et formats persistés qui ne peuvent pas être modifiés sans migration ;
|
||||
- comparer le code aux README/USAGE/TODO/changelogs et supprimer les hypothèses obsolètes du plan ;
|
||||
- établir les problèmes réels et les priorités ;
|
||||
- proposer un découpage de prereleases bornées pour atteindre les objectifs de `0.5.0` ;
|
||||
- préciser ce qui appartient réellement à `0.5.0` et ce qui doit rester réservé à `0.5.1` à `0.5.4` ;
|
||||
- définir les tests, audits, migrations et validations nécessaires avant code ;
|
||||
- créer un plan temporaire sous `docs/plans/`, à archiver lors de la dernière prerelease de `0.5.0`.
|
||||
|
||||
La planification doit être validée avant toute restructuration importante.
|
||||
|
||||
## Axe `0.5.1` — `kb-config`
|
||||
|
||||
Le plan doit préparer une version dédiée qui :
|
||||
|
||||
- restructure `kb-config` par responsabilités cohérentes ;
|
||||
- sépare au minimum le schéma de configuration générale du schéma de logging si l’audit confirme cette frontière ;
|
||||
- autorise d’autres schémas spécialisés uniquement lorsqu’ils réduisent réellement le couplage ;
|
||||
- audite les profils, valeurs par défaut, validations croisées et erreurs ;
|
||||
- audite la résolution des variables d’environnement et `.env` ;
|
||||
- introduit un camouflage systématique des secrets dans logs, diagnostics, UI, sérialisation et erreurs ;
|
||||
- interdit qu’un secret résolu soit renvoyé en clair par un payload de configuration ;
|
||||
- garde les exemples, schémas JSON, TS-RS et documentation alignés.
|
||||
|
||||
## Axe `0.5.2` — `kb-wallet`
|
||||
|
||||
Préparer :
|
||||
|
||||
- l’audit des types de wallets et signers existants ;
|
||||
- la séparation identité / secret / déverrouillage / signature ;
|
||||
- les besoins multi-wallets et multi-profils ;
|
||||
- import/export, chiffrement, sauvegarde/restauration et verrouillage lorsque ces capacités sont retenues ;
|
||||
- des frontières strictes empêchant la fuite de secrets vers config, logs ou Tauri ;
|
||||
- des scénarios réutilisables lorsque des validations opérateur sont nécessaires.
|
||||
|
||||
## Axe `0.5.3` — `kb-store`
|
||||
|
||||
Préparer un audit de fond avant migration :
|
||||
|
||||
- contrats DTO, entités, repositories, migrations, index et requêtes ;
|
||||
- timestamps on-chain et timestamps de persistance séparés explicitement ;
|
||||
- distinction entre slot, block time ou temps de transaction et temps d’insertion/mise à jour en base ;
|
||||
- provenance et idempotence ;
|
||||
- normalisation de la structure du store ;
|
||||
- champs et index nécessaires aux futures matérialisations trading/routing/multi-pools ;
|
||||
- interrogation efficace de la création de pools, actifs, liquidité, réserves, prix observés, swaps et séries temporelles ;
|
||||
- possibilité d’analyser plusieurs pools et routes sans couplage prématuré à Meteora, Raydium, Pump, Orca ou Jupiter.
|
||||
|
||||
Aucune table trading spécifique ne doit être inventée avant d’avoir défini les faits stables produits par les matérialisateurs futurs.
|
||||
|
||||
## Axe `0.5.4` — scénarios et complétude des exécuteurs
|
||||
|
||||
Préparer un audit transversal qui :
|
||||
|
||||
- détecte les scénarios encore assemblés directement dans `kb-app-demo-desktop` ;
|
||||
- déplace leur logique réutilisable vers `kb-pipeline-demo-scenarios` ;
|
||||
- laisse le desktop comme adaptateur UI/Tauri uniquement ;
|
||||
- compare les décodeurs aux exécuteurs disponibles ;
|
||||
- identifie les exécuteurs manquants réellement justifiés ;
|
||||
- compare les exécuteurs aux scénarios et validations réseau existants ;
|
||||
- identifie les capacités présentes dans le desktop sans scénario réutilisable ;
|
||||
- classe chaque manque comme à implémenter, decode-only, deprecated, unavailable, non applicable ou reporté.
|
||||
|
||||
## Suite du ROADMAP à respecter
|
||||
|
||||
Après `0.5.x` :
|
||||
|
||||
- `0.6.x` : infrastructure Anchor générique et seulement les programmes SPL apportant une valeur directe aux DEX suivants ;
|
||||
- `0.7.x` : Meteora avec alternance decode/materialize puis executor/scénarios ;
|
||||
- `0.8.x` : Raydium selon la même discipline ;
|
||||
- `0.9.x` : Pump ;
|
||||
- `0.10.x` : Orca ;
|
||||
- `0.11.x` : Jupiter ;
|
||||
- `0.12.x` : autres routers/protocoles prioritaires ;
|
||||
- `0.13.x` : transports temps réel ;
|
||||
- `0.14.x` : workers et applications consommatrices ;
|
||||
- `0.15.x` : programmes SPL et Metaplex complémentaires reportés ;
|
||||
- `0.16.x+` : extensions futures et éventuel `kb-offchain-transport`.
|
||||
|
||||
Ne pas réintroduire en `0.6.x` une couverture exhaustive des programmes SPL ou Metaplex qui a été explicitement reportée.
|
||||
|
||||
## Discipline des scénarios et validations
|
||||
|
||||
Pour toute nouvelle capacité exécutable :
|
||||
|
||||
1. tests contractuels et synthétiques ;
|
||||
2. logique de scénario réutilisable dans `kb-pipeline-demo-scenarios` ;
|
||||
3. simulation RPC exacte ;
|
||||
4. soumission Devnet/Testnet lorsque sûre et disponible ;
|
||||
5. postconditions et matérialisation observables ;
|
||||
6. panneau desktop seulement comme adaptateur opérateur ;
|
||||
7. statut de qualification explicite et jamais promu depuis une preuve synthétique seule.
|
||||
|
||||
Les scénarios déjà qualifiés ne doivent pas être rejoués automatiquement à chaque refactor si aucune frontière qu’ils couvrent n’a changé.
|
||||
|
||||
## Documentation et deltas
|
||||
|
||||
À chaque prerelease ou correctif :
|
||||
|
||||
- mettre à jour uniquement les documents rendus faux ou incomplets ;
|
||||
- conserver les README/USAGE généralistes ;
|
||||
- utiliser les changelogs pour la chronologie ;
|
||||
- supprimer les TODO terminés ;
|
||||
- maintenir le plan temporaire de la version ;
|
||||
- livrer uniquement un ZIP delta avec `delta.md` ;
|
||||
- ne jamais livrer `Cargo.lock`, les lockfiles frontend, `node_modules`, `dist`, `target` ou les bindings générés sans nécessité explicite ;
|
||||
- ne jamais fournir de SHA/checksum dans la réponse de livraison ;
|
||||
- recommencer la numérotation `fix-001` à chaque nouvelle prerelease.
|
||||
|
||||
## Dernière prerelease obligatoire
|
||||
|
||||
La dernière prerelease de `0.5.0` devra :
|
||||
|
||||
- exécuter les validations finales ;
|
||||
- corriger les écarts résiduels ;
|
||||
- finaliser README, ROADMAP, changelogs, TODO et guides concernés ;
|
||||
- transférer les décisions durables du plan vers les documents normatifs ;
|
||||
- archiver le plan et le prompt de session terminés sous `olddocs/archivekbot3/` ;
|
||||
- préparer le prompt de la session suivante ;
|
||||
- préparer la release finale sans introduire une nouvelle fonctionnalité structurelle majeure.
|
||||
|
||||
## Contrôles de référence
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Lorsque le desktop doit être validé :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Pour une validation de release desktop :
|
||||
|
||||
```bash
|
||||
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
Reference in New Issue
Block a user