diff --git a/Cargo.toml b/Cargo.toml index 8fe973d..3d0fa4a 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,5 +1,5 @@ # file: Cargo.toml -# version: 40 +# version: 41 [workspace] resolver = "3" @@ -18,7 +18,7 @@ members = [ ] [workspace.package] -version = "0.4.8" +version = "0.5.0-pre.1" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3" diff --git a/docs/README.md b/docs/README.md index bf181b0..fd81439 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,5 +1,5 @@ - + # Documentation active de Khadhroony Bot3 @@ -102,9 +102,9 @@ Les preuves détaillées de `0.4.8-pre.*` restent accessibles sous `../olddocs/a ## 10. Plans de version actifs -Aucun plan de version temporaire n’est actif après la clôture de `0.4.8`. Le plan `0.4.8` est archivé sous `../olddocs/archivekbot3/docs/plans/`. +- [`Plan 0.5.0 — cadrage de la fondation 0.5.x`](plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md) : plan temporaire actif créé pendant `0.5.0-pre.001`, à maintenir jusqu’à la clôture de `0.5.0`. -Le prochain plan sera créé pendant la première prerelease de `0.5.0`, après audit et brainstorming. +Le plan `0.4.8` reste archivé sous `../olddocs/archivekbot3/docs/plans/`. ## 11. Prompt de reprise diff --git a/docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md b/docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md new file mode 100644 index 0000000..602a945 --- /dev/null +++ b/docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md @@ -0,0 +1,476 @@ + + + +# 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 proposé, à valider avant toute restructuration importante.** + +## 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`. + +Cette duplication confirme l'existence d'une frontière à auditer en `0.5.1`, mais `pre.001` ne décide pas encore si le contrat source, le contrat runtime ou un adaptateur intermédiaire doit devenir canonique. La décision doit respecter la direction des dépendances du workspace et éviter de coupler `kb-config` au runtime de logging par commodité. + +### 5.3 `kb-wallet` + +Le format persistant actuel est un contrat de compatibilité réel : + +- chemin déterministe `.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` — `kb-config` + +### Questions à fermer avant code + +1. Quel contrat sépare configuration source, configuration runtime résolue et vue publique redacted ? +2. Le logging doit-il être un fichier distinct, un sous-document distinct ou seulement un schéma distinct ? +3. Qui est propriétaire du shape source logging et qui est propriétaire du shape runtime ? +4. Comment migrer l'actuel fichier unique sans casser les profils existants ? +5. Quelles valeurs sont des secrets explicites et quelles valeurs peuvent en contenir indirectement, par exemple une URL ? +6. Comment interdire une sérialisation accidentelle d'un secret résolu ? +7. Quels types ont réellement besoin d'être exportés via TS-RS ? + +### Critères d'acceptation préparés + +- compatibilité ou migration explicite du format `0.4.8` ; +- schémas JSON distincts et synchronisés si la frontière est retenue ; +- tests des profils, defaults, validations croisées et erreurs ; +- tests `.env`, `.env.local`, placeholders et fallbacks ; +- canaris secrets absents de tous les payloads publics, logs et erreurs ; +- suppression du payload frontend de configuration résolue complète ; +- adaptation explicite de `kb-logging`, transport, pipeline, scénarios et desktop ; +- aucune dépendance de `kb-store` vers `kb-config` ; +- documentation et exemples alignés. + +## 9. Préparation de `0.5.2` — `kb-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` — `kb-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 + +- ne jamais modifier `0001` à `0004` ; +- définir une nouvelle migration uniquement après validation du modèle ; +- 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 ; +- conserver les identités persistées de processeurs et clés d'idempotence ou fournir une migration explicite. + +## 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 `kb-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 prévus : + +- inventaire exhaustif des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ; +- audit de tous les chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ; +- 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 ; +- correction des documents de configuration rendus faux par l'audit, sans appliquer encore le nouveau format. + +Critère de sortie : aucune ambiguïté sur les frontières source/runtime/public de la configuration ni sur le contrat de migration wallet. + +### `0.5.0-pre.003` — audit store/scénarios/desktop et contrats de préparation + +Livrables prévus : + +- 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. + +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. + +### `0.5.0-pre.004` — clôture obligatoire de `0.5.0` + +Livrables prévus : + +- réconciliation transversale des audits et corrections résiduelles ; +- validations finales du workspace ; +- mise à jour des README/USAGE/TODO/guides rendus faux ou incomplets ; +- transfert des décisions durables dans ROADMAP/règles/architecture lorsque nécessaire ; +- archivage du présent plan et du prompt `029` sous `olddocs/archivekbot3/` ; +- préparation du prompt `0.5.1` ; +- préparation de la release finale `0.5.0` sans nouvelle fonctionnalité structurelle majeure. + +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 format wallet `0.4.8` et ses exigences de migration sont documentés ; +- le vocabulaire temporel/provenance/idempotence du store est défini 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 `0.5.1` est prêt. diff --git a/kb-app-demo-desktop/CHANGELOG.md b/kb-app-demo-desktop/CHANGELOG.md index b00bb6c..d4d979e 100644 --- a/kb-app-demo-desktop/CHANGELOG.md +++ b/kb-app-demo-desktop/CHANGELOG.md @@ -1,8 +1,13 @@ - + # CHANGELOG — kb-app-demo-desktop +## 0.5.0-pre.001 + +- aligne les versions frontend et Tauri sur `0.5.0` pour ouvrir la nouvelle version fonctionnelle ; +- ne modifie aucun parcours desktop : `0.5.0-pre.001` reste limitée au cadrage, à l’audit initial et au plan de la série `0.5.x`. + ## 0.4.8-pre.016 - corrige la sortie de build Vite pour tenir compte de `root: 'frontend'` : `build.outDir` pointe vers `../../dist` et la page `demo_execution_metadata.html` est référencée sous son nom réel ; diff --git a/kb-app-demo-desktop/package.json b/kb-app-demo-desktop/package.json index bbb6cf3..6b4ba6e 100644 --- a/kb-app-demo-desktop/package.json +++ b/kb-app-demo-desktop/package.json @@ -1,7 +1,7 @@ { "name": "kb-app-demo-desktop", "private": true, - "version": "0.4.8", + "version": "0.5.0", "type": "module", "scripts": { "dev": "vite", diff --git a/kb-app-demo-desktop/tauri.conf.json b/kb-app-demo-desktop/tauri.conf.json index ae87566..a764e0f 100644 --- a/kb-app-demo-desktop/tauri.conf.json +++ b/kb-app-demo-desktop/tauri.conf.json @@ -1,7 +1,7 @@ { "$schema": "https://schema.tauri.app/config/2", "productName": "Khadhroony Bot3 Demo Desktop", - "version": "0.4.8", + "version": "0.5.0", "identifier": "com.sasedev.kb-app-demo-desktop", "build": { "beforeDevCommand": "npm run dev",