diff --git a/Cargo.toml b/Cargo.toml index ff7888d..efa49d7 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,5 +1,5 @@ # file: Cargo.toml -# version: 73 +# version: 74 [workspace] resolver = "3" @@ -19,7 +19,7 @@ members = [ ] [workspace.package] -version = "0.5.3-pre.4" +version = "0.5.3-pre.5" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3" diff --git a/ROADMAP.md b/ROADMAP.md index 4f9d687..b4baf39 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # ROADMAP — khadhroony-bot3 @@ -135,6 +135,7 @@ Le schéma ne doit pas être organisé en familles de tables par protocole ou Pr ### 0.5.4 — scénarios, exécuteurs et validations +- réconcilier le cas de decode CPI Metaplex Token Metadata observé en `0.5.3-pre.004` (`transfer`, chemin `2/0`, diagnostic `transfer account 9 lacks required signer/writable privileges`) afin de déterminer si le contrat d’accounts du décodeur doit accepter les privilèges runtime observés ; ce point relève du décodeur/scénario, pas de `ks-store` ; - diagnostiquer et corriger la régression observée dans `demo_execution_spl_token_2022` lors du chargement de fixture (`unable to read configured Token-2022 fixture`) après séparation des racines wallet/fixtures ; - inventorier non destructivement les keypairs historiques sous `wallets/temporary/**`, extraire les pubkeys des formats supportés et préparer une migration sélective des seuls signers devant devenir persistants ; - garder toute classification on-chain éventuelle chez le consommateur/scénario, à partir de la pubkey et du profil réseau, sans dépendance `ks-wallet -> ks-onchain-transport` ni rôle métier inventé depuis les bytes du secret ; diff --git a/docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md b/docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md index 74abc4d..ad7173a 100644 --- a/docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md +++ b/docs/plans/V0_5_3_KS_STORE_NORMALIZATION_PLAN.md @@ -1,5 +1,5 @@ - + # Plan `0.5.3` — audit et normalisation de `ks-store` @@ -47,7 +47,7 @@ Les décisions suivantes sont retenues pour les tranches suivantes : 6. **`kb_sol_mat_events` reste le journal générique versionné des sorties de matérialisation**, mais son nom durable devient `k_sol_mat_outputs`, cohérent avec son rôle réel ; les projections métier spécialisées seront additives ; 7. **aucune table DEX/trading n'est créée en `0.5.3`** : aucun chantier DEX n'a encore fourni les invariants nécessaires à un contrat SQL gelable ; lorsque ces matérialisations arriveront, les tables devront être génériques par fait/concept et non par protocole ; 8. **aucune projection metadata N4 n'est créée en `0.5.3`**, mais deux cibles conceptuelles sont déjà retenues : asset/token metadata commune Metaplex + Token-2022 et program metadata distincte pour SPM ; elles seront ajoutées lorsque leurs premiers contrats queryables seront suffisamment audités, puis resteront plus évolutives que les fondations N1-N3 ; -9. **les bases Devnet/Mainnet/test actuelles sont considérées destructibles pour `0.5.3`** : la cible est une reconstruction propre, pas une compatibilité in-place avec le schéma `0.5.2` ; l'ancien schéma doit être détecté/refusé plutôt que silencieusement mélangé au nouveau ; +9. **`ks-store` ne possède et ne valide que ses ressources `k_sol_*` courantes** : une reconstruction des bases Devnet/Mainnet/test reste acceptable pour `0.5.3`, mais une base non vide, des tables applicatives étrangères ou d'anciens objets `kb_sol_*` peuvent coexister sans blocage tant qu'aucun contrat courant de `ks-store` ne les utilise ; 10. **les ressources SQL PostgreSQL sont rangées sous `ks-store/migrations/postgres/`** et chaque fichier contient une seule instruction SQL ; les fonctions privées PostgreSQL utilisent `include_str!` pour exécuter la ressource correspondante ; 11. **tables, contraintes/keys, index et opérations de maintenance (`DROP`, `TRUNCATE`) sont séparés** en ressources/fonctions explicites et assemblés par un orchestrateur d'initialisation PostgreSQL transactionnel ; 12. **le DDL dupliqué en chaînes Rust disparaît** : le fichier SQL inclus est l'unique source du texte SQL exécuté ; @@ -625,36 +625,39 @@ La migration ne fait pas un simple remplacement textuel. Elle doit couvrir : - documentation active ; - chaînes visibles du desktop. -### 15.2 Base vide +### 15.2 Base PostgreSQL hôte -Une base vide est la **cible normale de `0.5.3`**. +`ks-store` ne requiert pas une base vide et ignore les tables étrangères au contrat courant, y compris d'éventuels objets historiques `kb_sol_*`. `auto_initialize_schema` est un mécanisme d'évolution **additive seulement** du schéma géré. -L'auto-initialisation PostgreSQL exécute l'orchestrateur des ressources SQL unitaires dans un ordre déterministe : tables, contraintes, index, puis vérification du snapshot logique. Le résultat final ne doit contenir aucun objet actif `kb_sol_*`. +À l'ouverture, les ressources gérées déjà présentes sont contrôlées avant toute initialisation. Une définition existante incompatible (type/nullabilité/défaut de colonne, définition PK/FK ou définition d'index) est bloquante et n'est jamais modifiée implicitement. En revanche, une table, colonne, clé/contrainte ou index attendu mais absent peut être ajouté lorsque l'auto-initialisation est active. L'orchestrateur applique ces ajouts transactionnellement dans l'ordre tables -> colonnes -> contraintes -> index, puis revalide le contrat complet. Il n'exécute aucun retrait, renommage ni mutation d'une colonne existante. Une base hôte peut donc être un sur-ensemble du schéma `ks-store` sans devenir incompatible. -### 15.3 Bases `0.5.2` Devnet/Mainnet/test +### 15.3 Compatibilité du schéma géré -La décision de session est de **supprimer et recréer** les bases actuelles. `0.5.3` n'investit donc pas dans une migration in-place des données historiques. +`0.5.3` n'investit pas dans une migration in-place des données historiques `0.5.2`, mais leur simple présence ne constitue plus une erreur. Le comportement attendu est : -Le comportement attendu est : +1. table gérée trouvée + colonnes, clés et index compatibles -> `OK`, sans exécuter d'initialisation ; +2. ressource gérée existante avec une définition incompatible -> `ERR`, même avec `auto_initialize_schema=true` ; +3. table/colonne/clé/index géré absent + `auto_initialize_schema=false` -> `ERR` ; +4. table/colonne/clé/index géré absent + `auto_initialize_schema=true` -> tenter l'ajout uniquement de la ressource absente, sans supprimer ni modifier les colonnes existantes, puis `ERR` si l'ajout ou la validation complète échoue ; +5. ignorer les tables et objets non possédés par `ks-store`, quel que soit leur préfixe ; +6. accepter les extensions additives compatibles, mais refuser une colonne additive étrangère obligatoire sans défaut qui casserait les écritures courantes. -1. si la base est vide, initialiser le nouveau schéma ; -2. si le nouveau schéma `k_sol_*` est déjà conforme, vérifier puis continuer ; -3. si des objets historiques `kb_sol_*` sont détectés, refuser l'auto-initialisation avec un diagnostic non destructif demandant une reconstruction explicite ; -4. ne jamais mélanger silencieusement ancien et nouveau namespace. +Le contrat de `pre.005` compare les **16 tables, 248 colonnes, 25 clés PK/FK et 79 index physiques** du baseline courant. Le snapshot exhaustif des checks et autres détails frozen reste consolidé en `pre.006`. -Les opérations `DROP`/`TRUNCATE` restent disponibles comme maintenance backend-interne explicite ; elles ne sont pas déclenchées automatiquement par `Store::open()` sur une base non vide. +Les opérations `DROP`/`TRUNCATE` restent des opérations de maintenance backend-internes explicites et ne sont jamais déclenchées automatiquement sur les ressources étrangères. ### 15.4 Conséquence sur les tests -Le test de migration `0.5.2 -> 0.5.3` n'est plus requis. Il est remplacé par : +Le test de migration `0.5.2 -> 0.5.3` n'est pas requis. Il est remplacé par : -- init d'une base vide ; +- validation du contrat structurel de toutes les tables gérées ; - réouverture idempotente d'une base déjà initialisée ; -- refus propre d'un schéma historique `kb_sol_*` ; -- reconstruction explicite via les opérations de maintenance retenues ; -- snapshot exact du schéma final. +- coexistence non bloquante avec des tables étrangères et des objets historiques `kb_sol_*` ; +- acceptation des extensions additives compatibles et réparation additive des ressources gérées absentes lorsque l'auto-initialisation est active ; +- refus des dérives existantes qui nécessiteraient une modification ou suppression pour redevenir compatibles ; +- snapshot exact du schéma frozen lors de la tranche de gel. -Cette stratégie est acceptable parce que les bases actuelles ne constituent pas encore des contrats de production à préserver. +Cette stratégie permet aux projections N4 futures d'être additives sans affaiblir le contrat N1/N2/N3 courant. ## 16. Source de vérité des migrations PostgreSQL @@ -1075,11 +1078,12 @@ La même règle s'applique à tout autre protocole : une table nommée d'après ### 25.1 Contrat de schéma -- initialisation sur base vide ; -- réouverture idempotente d'une base déjà initialisée ; -- refus propre d'une base contenant encore des objets `kb_sol_*` ; -- absence finale de tables, contraintes, index et séquences `kb_sol_*` après reconstruction ; - présence des **16 tables du baseline candidat au gel** retenu en `pre.003` ; +- validation dans `ks-store` des colonnes requises, types, nullabilités, précisions numériques et défauts nécessaires aux modèles/queries courants ; +- validation avant toute auto-initialisation des 25 clés PK/FK et des 79 index physiques attendus ; une dérive d'une table existante est bloquante et n'est pas auto-réparée ; +- acceptation d'une base contenant des tables étrangères ou historiques non gérées, y compris `kb_sol_*` ; +- acceptation de colonnes additives compatibles et refus d'une colonne additive `NOT NULL` sans défaut qui casserait les écritures courantes ; +- réouverture idempotente d'une base déjà initialisée ; - snapshot exact des colonnes/types/nullabilités/PK/FK/uniques/checks frozen ; - présence et contrat séparé des tables top-level/CPI ; - test de lecture logique combinée top-level+CPI sans perte, doublon ni ordre instable ; @@ -1149,8 +1153,8 @@ Avec `KS_SECRET_POSTGRES_TEST_URL` local : - transaction rollback ; - replay ; - diagnostics ; -- introspection du contrat frozen ; -- reconstruction propre d'une base de test et refus contrôlé d'un schéma historique `kb_sol_*`. +- introspection du contrat géré puis du contrat frozen ; +- vérification que les ressources étrangères/non gérées ne bloquent pas `ks-store` et que toute dérive structurelle d'une ressource gérée est détectée. ## 26. Snapshot de contrat frozen @@ -1253,20 +1257,22 @@ Le découpage suivant est une **trajectoire fonctionnelle**. Il ne force pas la ### `0.5.3-pre.005` — finalisation `demo_store`, consommateurs et validation PostgreSQL réelle +La pagination de consultation retenue sépare explicitement deux niveaux : blocs Store fixes de 500 lignes, parcourus par curseurs `Premier/Précédent/Suivant`, puis pagination/tri/filtre DataTables uniquement dans le bloc chargé lorsque la vue utilise DataTables. Chaque chargement ou navigation recalcule le nombre total de lignes/blocs correspondant exactement aux filtres serveur ; aucun champ `offset` ni `limit` éditable n’est exposé pour ces listings. Cette règle couvre Replay Candidates, annotations et journaux matérialisés SPL Token/ATA, sans modifier les limites métier des campagnes, backfills ou RPC. + - supprimer les derniers `Postgres*` de `ks-pipeline-demo-scenarios` ; - finaliser les surfaces `demo_store_*` de `kb-app-demo-desktop` autour de résultats tabulaires génériques indépendants du backend ; la nomenclature technique a déjà été migrée en `pre.002` ; - refaire `demo_config` afin qu'elle n'expose/interprète plus les champs PostgreSQL/SQLite et consomme uniquement le résumé store sanitisé ; - refaire les informations store du splash autour d'une vérification par modèle logique et de compteurs (tables/index attendus, présents, créés), sans afficher les noms physiques ; - confirmer que `ks-pipeline` reste inchangé dans son rôle d'orchestration ; -- tests base vide + réouverture + refus ancien schéma ; -- validations PostgreSQL réelles ; +- validation de compatibilité structurelle des ressources gérées + réouverture, avec coexistence non bloquante des ressources étrangères/historiques ; +- validations PostgreSQL réelles depuis `ks-store`, les consommateurs ne réimplémentant aucune introspection ; - lancer Tauri parce que les diagnostics/surfaces desktop auront changé. ### `0.5.3-pre.006` — gel de contrat et réconciliation technique - produire le snapshot machine-readable frozen avec le nombre réel de tables N1/N2/N3 après canari future-decoder, sans imposer artificiellement la baseline de 13 ; - canari exact du schéma logique ; -- audit workspace anti-`kb_sol_` actif ; +- audit workspace vérifiant qu’aucune ressource/requête active de `ks-store` n’utilise `kb_sol_*`, sans interdire leur coexistence physique ; - audit anti-PostgreSQL hors `ks-store` ; - audit secrets/logging ; - confirmer qu'aucune table trading/DEX ni projection metadata N4 non auditée n'a été introduite ; @@ -1319,7 +1325,7 @@ cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json La version ne peut être clôturée que si : -- il n'existe plus d'objet actif `kb_sol_*` ; +- aucune ressource gérée ni requête active de `ks-store` n’utilise `kb_sol_*` ; leur coexistence comme objets non gérés reste tolérée ; - les 16 tables du baseline candidat retenu en `pre.003` correspondent exactement au snapshot frozen documenté ; - `block_time` est conservé lorsqu'il existe et reste `NULL` sinon ; - les top-level et CPI restent physiquement séparées mais peuvent être sélectionnées séparément ou comme flux logique commun pour le decode ; @@ -1551,21 +1557,21 @@ La nouvelle arborescence contient : migrations/postgres/ schema/tables/ 16 schema/constraints/ 129 - schema/indexes/ 59 + schema/indexes/ 63 maintenance/truncate/16 maintenance/drop/ 16 ``` -Soit **236 ressources SQL**. Chaque ressource contient une seule instruction top-level et est embarquée une seule fois par `include_str!`. +Soit **240 ressources SQL**. Chaque ressource contient une seule instruction top-level et est embarquée une seule fois par `include_str!`. L'orchestrateur PostgreSQL global : - valide les ressources ; -- refuse les objets historiques `kb_sol_*` ; -- ouvre une transaction ; -- prend un advisory lock ; -- applique tables, contraintes et index dans l'ordre ; -- commit uniquement lorsque le baseline complet est cohérent. +- inspecte d'abord les tables gérées déjà présentes et refuse toute dérive de colonnes, PK/FK ou index ; +- ignore les objets étrangers ou historiques non gérés, y compris `kb_sol_*` ; +- si aucune table gérée ne manque, n'exécute aucune initialisation ; +- si des tables gérées manquent et que l'auto-initialisation est autorisée, ouvre une transaction, prend un advisory lock et applique uniquement les tables manquantes, leurs contraintes puis leurs index ; +- commit la création puis revalide le baseline complet. Les initialiseurs partiels raw/Core/decode sont supprimés, y compris des tests. Une initialisation ne peut donc plus valider accidentellement un sous-schéma comme si le baseline complet était prêt. @@ -1582,7 +1588,7 @@ Le résumé backend-agnostique expose : sans publier les noms physiques. -Le backend PostgreSQL attend actuellement **75 index** : 59 index explicites et les 16 index de clés primaires produits par PostgreSQL. +Le backend PostgreSQL attend actuellement **79 index** : 63 index explicites et les 16 index de clés primaires produits par PostgreSQL. ### 33.8 Conclusion du canari future-decoder @@ -1609,7 +1615,6 @@ Les autres metadata transactionnelles auditées (`fee`, rewards, compute units, - les projections N4 metadata/trading. Ces points restent dans les tranches suivantes et peuvent décaler le premier candidat de clôture au-delà de `pre.007`. - ## 34. État réalisé de `0.5.3-pre.004` `pre.004` ferme la tranche repositories/replay sans ajouter de table et sans déclarer encore le gel formel N1/N2/N3. diff --git a/kb-app-demo-desktop/CHANGELOG.md b/kb-app-demo-desktop/CHANGELOG.md index 93fa44e..c620a46 100644 --- a/kb-app-demo-desktop/CHANGELOG.md +++ b/kb-app-demo-desktop/CHANGELOG.md @@ -1,8 +1,24 @@ - + # CHANGELOG — kb-app-demo-desktop +## `0.5.3-pre.005` + +- centralise la résolution et la préparation du Store des profils Devnet dans `demo_devnet_common`, utilisé par Solana Core, SPL et Metadata au lieu de rattacher ce contrat partagé à `demo_execution_solana_core` ; +- ajoute des traces `frontendDebug` explicites pour les clics et invocations de chargement des journaux SPL Token/ATA ainsi que pour la préparation des profils SPL/Metadata, afin de distinguer la réutilisation normale du Store partagé d’une absence de requête ; +- corrige la préparation automatique des profils Execution Devnet afin qu’elle utilise elle aussi le `ks_store::Store` partagé par profil : l’ouverture d’une seconde fenêtre Devnet et le premier chargement de journal ne rouvrent plus un pool PostgreSQL ni ne relancent `schema_initialize` après que le profil a déjà été préparé ; +- réutilise désormais un `ks_store::Store` partagé par profil pour toutes les surfaces Execution Devnet : les lectures de journaux et exécutions successives ne recréent plus un pool PostgreSQL ni ne relancent `schema_initialize` à chaque commande, tout en conservant le Store du profil actif séparé des profils Devnet ; +- corrige la restauration des boutons de navigation Store après le chargement initial parallèle de Replay Candidates : chaque contrôleur déjà chargé retrouve son état `Premier/Précédent/Suivant` une fois toutes les opérations concurrentes terminées, sans exiger un second clic sur `Charger` ; +- supprime les champs éditables de limite des listings de consultation Store : cinq listes Replay Candidates, annotations de transactions, journal SPL Token et journal ATA ; la taille backend est fixée à 500 lignes par bloc ; +- ajoute une navigation Store supérieure `Premier bloc / Bloc précédent / Bloc suivant` indépendante de la pagination locale DataTables ; +- recalcule `totalRows` et `totalBlocks` à chaque chargement ou navigation ; tout bouton `Charger` repart du bloc 1 avec les filtres courants, tandis que `Premier/Précédent/Suivant` rafraîchissent également le nombre de blocs ; +- invalide les curseurs mémorisés dès qu’un filtre serveur change et exige alors un nouveau chargement du premier bloc ; +- étend DataTables jusqu’à 500 lignes affichables localement dans le bloc courant ; +- applique le même contrôleur de blocs aux annotations de Decode Replay et aux journaux SPL Token/ATA ; leurs comptages backend utilisent exactement les filtres serveur visibles, y compris les contraintes de payload, sans `OFFSET` ; +- termine le nettoyage des identifiants frontend `refreshSql*` / `copySql*` au profit de `refreshStore*` / `copyStore*` ; +- conserve `demo_config` et le splash sur les résumés Store backend-agnostiques déjà introduits, sans noms physiques d’objets PostgreSQL. + ## `0.5.3-pre.004` - aligne la limite maximale de la fenêtre technique de candidats replay Store sur la nouvelle borne interactive backend-agnostique de 500 lignes ; diff --git a/kb-app-demo-desktop/README.md b/kb-app-demo-desktop/README.md index f2e5c18..fa93b82 100644 --- a/kb-app-demo-desktop/README.md +++ b/kb-app-demo-desktop/README.md @@ -1,5 +1,5 @@ - + # kb-app-demo-desktop @@ -20,7 +20,7 @@ Les commandes Tauri sont des adaptateurs minces. La logique réutilisable appartient à `ks-pipeline`, `ks-pipeline-demo-scenarios`, `ks-lib`, `ks-store` et `ks-onchain-transport`. -Depuis `0.5.3-pre.002`, l'application conserve une façade `ks_store::Store` unique dans `AppState`. Les commandes ne construisent plus de `PostgresStore` et les payloads de configuration/diagnostic ne transportent plus de champs PostgreSQL/SQLite concrets. Les anciennes surfaces `demo_sql_*` sont renommées en `demo_store_*` dès `pre.002`; la refonte fonctionnelle finale de leurs tableaux et compteurs reste planifiée en `pre.005`. +Depuis `0.5.3-pre.002`, l'application conserve une façade `ks_store::Store` unique dans `AppState`. Les commandes ne construisent plus de backend concret et les payloads de configuration/diagnostic ne transportent plus de champs PostgreSQL/SQLite concrets. Depuis `0.5.3-pre.005`, les listings de consultation Store utilisent des blocs fixes de 500 parcourus par curseurs : Replay Candidates, annotations de transactions et journaux SPL Token/ATA partagent le même principe. Chaque chargement recalcule le nombre total de blocs pour les filtres actifs. Lorsqu’une vue utilise DataTables, sa pagination/son tri/son filtre restent strictement locaux au bloc déjà chargé. Les campagnes Devnet/Testnet réutilisables appartiennent à `ks-pipeline-demo-scenarios`. Le desktop conserve leurs adaptateurs UI/Tauri, la sélection opérateur, la progression, les payloads TS-RS et la présentation ; `0.5.4` doit retirer les orchestrations réutilisables qui subsistent encore localement. diff --git a/kb-app-demo-desktop/TODO.md b/kb-app-demo-desktop/TODO.md index 2221d12..6548ad0 100644 --- a/kb-app-demo-desktop/TODO.md +++ b/kb-app-demo-desktop/TODO.md @@ -1,11 +1,11 @@ - + # TODO — kb-app-demo-desktop ## Évolutions générales -- [ ] `0.5.3` — finaliser en `pre.005` la présentation des surfaces `demo_store_*`, puis aligner `demo_config` et le splash sur les modèles/compteurs du nouveau baseline sans exposer de noms physiques ; le renommage technique est terminé en `pre.002`. +- [x] `0.5.3-pre.005` — finaliser les listings de consultation Store avec blocs fixes de 500, curseurs stables, total de blocs recalculé à chaque chargement/navigation et pagination DataTables locale lorsqu’elle existe ; Replay Candidates, annotations et journaux SPL Token/ATA suivent le même contrat, tandis que `demo_config` et le splash consomment les résumés génériques/sanitisés sans noms physiques. - [ ] `0.5.4` — réduire les panneaux d'exécution à l'adaptation UI/Tauri en déplaçant toute orchestration de campagne encore réutilisable vers `ks-pipeline-demo-scenarios`. - [ ] UX — empêcher les doubles déclenchements pendant une préparation, simulation ou soumission active. - [ ] Observabilité — afficher explicitement les comptes relus et les projections matérialisées. diff --git a/kb-app-demo-desktop/USAGE.md b/kb-app-demo-desktop/USAGE.md index d948580..dc5d016 100644 --- a/kb-app-demo-desktop/USAGE.md +++ b/kb-app-demo-desktop/USAGE.md @@ -1,5 +1,5 @@ - + # Utilisation de kb-app-demo-desktop @@ -125,6 +125,14 @@ Les autres fenêtres sont ouvertes par les commandes Tauri dédiées : - exécution Solana Core ; - exécution SPL. +## Pagination des listings Store + +Les listings de consultation Store n’exposent plus de champ `limit` éditable lorsqu’ils utilisent la borne interactive de 500. Le backend charge un bloc fixe de 500 lignes maximum et recalcule `totalRows`/`totalBlocks` à chaque action `Charger`, `Premier bloc`, `Bloc précédent` ou `Bloc suivant`. + +Le curseur reste opaque et n’est jamais saisi par l’opérateur. Modifier un filtre serveur invalide les curseurs mémorisés et impose de recharger le premier bloc. Lorsqu’une vue utilise DataTables, sa pagination, son tri et son filtre restent locaux aux lignes du bloc courant et ne modifient jamais la pagination Store. + +Cette règle s’applique aux Replay Candidates, aux annotations de transaction et aux journaux SPL Token/ATA. Les limites métier de backfill, de campagne decode/Core ou de requêtes RPC restent indépendantes et peuvent demeurer configurables. + ## Interface Tauri publique Les commandes Tauri constituent l’interface applicative frontend/backend. Elles ne sont pas des APIs Rust publiques pour les autres crates. diff --git a/kb-app-demo-desktop/frontend/demo_decode_replay.html b/kb-app-demo-desktop/frontend/demo_decode_replay.html index 5a2fb44..2fb8fc7 100644 --- a/kb-app-demo-desktop/frontend/demo_decode_replay.html +++ b/kb-app-demo-desktop/frontend/demo_decode_replay.html @@ -1,5 +1,5 @@ - + @@ -131,11 +131,13 @@ -
Annotations non chargées.