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

0.5.0-pre.003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-09 17:53:34 +02:00
parent 92dccabf53
commit a61c9ea05e
14 changed files with 438 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Plan `0.5.0` — cadrage de la fondation `0.5.x`
@@ -15,6 +15,8 @@ Le plan reste temporaire pendant le développement de `0.5.0`. Il doit être mai
**É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é.**
## 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` :
@@ -213,7 +215,7 @@ Ces écarts doivent être corrigés dans une prerelease documentaire de `0.5.0`
- rouvrir ElGamal sans possibilité de preuve nouvelle ;
- introduire de nouvelle surface protocolaire majeure.
## 8. Préparation de `0.5.1` — `kb-config`
## 8. Préparation de `0.5.1` — configuration et namespace `ks-*`
### Décisions fermées par `pre.002`
@@ -226,7 +228,7 @@ Ces écarts doivent être corrigés dans une prerelease documentaire de `0.5.0`
- 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 ;
- le renommage éventuel des crates `kb-*` -> `ks-*` doit être décidé transversalement avant de figer les nouveaux noms de types, chemins de bindings et exemples.
- 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).
@@ -368,14 +370,14 @@ Livrables réalisés :
- 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 un éventuel namespace de crates `ks-*`, sans renommage prématuré ;
- 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é. Le possible renommage de crates reste une décision transversale à fermer avant l'implémentation structurelle.
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 prévus :
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 ;
@@ -383,9 +385,13 @@ Livrables prévus :
- 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.
- 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 bibliothèques généralistes vers `ks-*` une partie de `0.5.1`, sans renommer mécaniquement les tables ou identités persistées.
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.
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`

367
docs/plans/V0_5_0_PRE_003_STORE_SCENARIOS_EXECUTION_AUDIT.md Normal file
View File

@@ -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`.