From 28bc7748984748c05be2394c398761da1f4792f4 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Sun, 9 Aug 2026 15:58:11 +0200 Subject: [PATCH] v0.4.8-pre.016-fix003 --- docs/architecture/ARCHITECTURE.md | 16 +++++----- docs/architecture/CRATE_MAP.md | 30 +++++++++--------- docs/architecture/PIPELINE_ARCHITECTURE.md | 12 ++++---- docs/architecture/PROJECT_OBJECTIVES.md | 24 +++++++++------ docs/architecture/STORAGE_ARCHITECTURE.md | 6 ++-- docs/architecture/SURFACE_CRATE_MATRIX.md | 36 +++++++++++++--------- 6 files changed, 69 insertions(+), 55 deletions(-) diff --git a/docs/architecture/ARCHITECTURE.md b/docs/architecture/ARCHITECTURE.md index 77d3752..6766e09 100644 --- a/docs/architecture/ARCHITECTURE.md +++ b/docs/architecture/ARCHITECTURE.md @@ -1,5 +1,5 @@ - + # Architecture générale @@ -66,10 +66,10 @@ Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacité ### 2.5 Démonstrations et applications -- `kb-pipeline-demo-scenarios` fournit les fixtures et les campagnes automatisées spécifiques à Devnet/Testnet. Ces campagnes peuvent reproduire en parallèle les parcours de démonstration du desktop afin de les valider par des tests sans déplacer les scénarios UI hors de `kb-app-demo-desktop`. -- Le binaire `kb-pipeline-demo-scenarios-cli` a été introduit pour préparer les fixtures SPL Token-2022 utilisées ensuite par les démonstrations d’exécution Devnet ; il ne constitue pas, par défaut, une interface générale de tous les scénarios. -- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. -- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Son périmètre reste incomplet. +- `kb-pipeline-demo-scenarios` fournit les fixtures et campagnes réseau réutilisables spécifiques aux validations Devnet/Testnet. Les scénarios réutilisables doivent être appelables sans dépendre du desktop. +- Le binaire `kb-pipeline-demo-scenarios-cli` reste un outil ciblé ; son existence n’impose pas d’exposer chaque scénario par un CLI. +- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. Les commandes et projections UI y restent, tandis que la logique de scénario réutilisable doit être déléguée à `kb-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`. +- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Sa restructuration est planifiée en `0.5.2`. ## 3. Flux principal de données @@ -99,11 +99,13 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh - Les IDs canoniques ne doivent pas être dispersés lorsqu’ils appartiennent au registre de `kb-program-ids`. - Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `kb-lib`. - Les commandes Tauri et payloads frontend spécifiques restent dans `kb-app-demo-desktop`. -- Les scénarios UI spécifiques à Devnet/Testnet restent dans `kb-app-demo-desktop`. Lorsqu’un même parcours doit être validé automatiquement, un scénario équivalent est ajouté en parallèle dans les tests de `kb-pipeline-demo-scenarios` ; cette duplication contrôlée de parcours de validation ne déplace pas le scénario UI. +- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `kb-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`. - Toute primitive ou orchestration réellement généraliste, indépendante de l’UI et d’une campagne de démonstration précise, appartient à `kb-pipeline` ou à la crate métier propriétaire. - Les fixtures contractuelles communes restent sous `test-fixtures/contract-matrices/` lorsqu’elles sont consommées par plusieurs tests. - Les archives documentaires ne participent ni au build ni aux décisions normatives. ## 5. État de migration -L’architecture bot3 est alignée fonctionnellement sur le périmètre bot2 `0.4.6`. Tout le travail Metaplex Token Metadata réalisé dans bot2 a été migré dans bot3 ; `0.4.7` achève cette surface à partir de cette base migrée complète. +La migration bot2 vers bot3 est close pour le périmètre fonctionnel repris jusqu’à `0.4.7`. La version `0.4.8` complète ensuite la fondation Metadata on-chain en distinguant Solana Program Metadata, Token-2022 Token Metadata et Metaplex Token Metadata, avec leurs décodeurs, matérialisateurs, exécuteurs lorsque applicables, orchestration stateful, scénarios réutilisables et intégration desktop. + +La série `0.5.x` ne vise pas à étendre immédiatement la couverture protocolaire : elle stabilise d’abord `kb-config`, `kb-wallet`, `kb-store` et les frontières de scénarios afin d’éviter de devoir casser ces fondations après l’arrivée des protocoles trading. `0.6.x` introduira ensuite le décodeur Anchor générique avant la séquence Meteora/Raydium/Pump/Orca/Jupiter. diff --git a/docs/architecture/CRATE_MAP.md b/docs/architecture/CRATE_MAP.md index 7ebd231..658a51f 100644 --- a/docs/architecture/CRATE_MAP.md +++ b/docs/architecture/CRATE_MAP.md @@ -1,23 +1,23 @@ - + # Carte des crates ## 1. Inventaire -| Crate | Type | Responsabilité principale | État documentaire | -|------------------------------|------------------------|--------------------------------------------------------------------|------------------------------------| -| `kb-core` | bibliothèque | erreurs, résultat et identité de module partagés | contrat par crate à créer | -| `kb-config` | bibliothèque | configuration JSON, environnement, validation et profils | contrat par crate à créer | -| `kb-lib` | bibliothèque | modèles, décodeurs, exécuteurs et matérialisateurs consolidés | contrat par crate à créer | -| `kb-logging` | bibliothèque | initialisation du logging et du tracing | contrat par crate à créer | -| `kb-program-ids` | bibliothèque | registre des programmes et comptes Solana connus | contrat par crate à créer | -| `kb-pipeline` | bibliothèque | backfill, extraction, replay, stateful, préflight et orchestration | contrat par crate à créer | -| `kb-pipeline-demo-scenarios` | bibliothèque + binaire | scénarios Devnet réutilisables et CLI | contrat par crate à créer | -| `kb-onchain-transport` | bibliothèque | transports RPC HTTP/WebSocket et pools d’endpoints | contrat par crate à créer | -| `kb-store` | bibliothèque | contrats de stockage et adaptateur PostgreSQL | contrat par crate à créer | -| `kb-wallet` | bibliothèque | wallet temporaire et frontière de signataire | ébauche à documenter explicitement | -| `kb-app-demo-desktop` | bibliothèque + binaire | application de démonstration Tauri | contrat par crate à créer | +| Crate | Type | Responsabilité principale | État documentaire | +|------------------------------|------------------------|--------------------------------------------------------------------|------------------------------------------| +| `kb-core` | bibliothèque | erreurs, résultat et identité de module partagés | README/TODO/USAGE/CHANGELOG présents | +| `kb-config` | bibliothèque | configuration JSON, environnement, validation et profils | documentée ; restructuration en `0.5.1` | +| `kb-lib` | bibliothèque | modèles, décodeurs, exécuteurs et matérialisateurs consolidés | README/TODO/USAGE/CHANGELOG présents | +| `kb-logging` | bibliothèque | initialisation du logging et du tracing | README/TODO/USAGE/CHANGELOG présents | +| `kb-program-ids` | bibliothèque | registre des programmes et comptes Solana connus | README/TODO/USAGE/CHANGELOG présents | +| `kb-pipeline` | bibliothèque | backfill, extraction, replay, stateful, préflight et orchestration | README/TODO/USAGE/CHANGELOG présents | +| `kb-pipeline-demo-scenarios` | bibliothèque + binaire | scénarios Devnet réutilisables et CLI | documentée ; réconciliation en `0.5.4` | +| `kb-onchain-transport` | bibliothèque | transports RPC HTTP/WebSocket et pools d’endpoints | README/TODO/USAGE/CHANGELOG présents | +| `kb-store` | bibliothèque | contrats de stockage et adaptateur PostgreSQL | documentée ; audit structurel en `0.5.3` | +| `kb-wallet` | bibliothèque | wallet temporaire et frontière de signataire | documentée ; restructuration en `0.5.2` | +| `kb-app-demo-desktop` | bibliothèque + binaire | application de démonstration Tauri | documentée ; réconciliation en `0.5.4` | ## 2. Consolidations principales depuis bot2 @@ -48,4 +48,4 @@ Cette carte n’est pas une table de compatibilité exhaustive des anciennes cra ## 4. Relations documentaires -Chaque crate devra disposer de `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`. Les documents transversaux présents dans `docs/architecture/` évitent de répéter l’architecture complète dans chaque README. +Chaque crate dispose de `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`. Les documents transversaux présents dans `docs/architecture/` évitent de répéter l’architecture complète dans chaque README. diff --git a/docs/architecture/PIPELINE_ARCHITECTURE.md b/docs/architecture/PIPELINE_ARCHITECTURE.md index 732f3d3..bcf15f0 100644 --- a/docs/architecture/PIPELINE_ARCHITECTURE.md +++ b/docs/architecture/PIPELINE_ARCHITECTURE.md @@ -1,5 +1,5 @@ - + # Architecture du pipeline @@ -23,7 +23,7 @@ Le replay sélectionne des candidats, applique les décodeurs compatibles de `kb ### 2.4 Traitements stateful -Les modules stateful corrèlent instructions, comptes, états précédents et résultats de transaction lorsque le protocole l’exige. Les surfaces SPL Token, ATA, Token-2022 et registre ElGamal disposent de traitements spécialisés à des niveaux différents. +Les modules stateful corrèlent instructions, comptes, états précédents et résultats de transaction lorsque le protocole l’exige. Les surfaces SPL Token, ATA, Token-2022, registre ElGamal et les trois domaines Metadata de `0.4.8` disposent de traitements spécialisés lorsque leur contrat l’exige. ### 2.5 Préflight et exécution @@ -42,13 +42,13 @@ kb-wallet -> signataires lorsque requis ## 4. Scénarios de démonstration -`kb-pipeline-demo-scenarios` contient les fixtures, aides de campagne et tests automatisés spécifiques à Devnet ou Testnet. Ses tests peuvent reproduire les mêmes parcours fonctionnels que les démonstrations UI afin de fournir une validation automatisée parallèle, sans retirer ni déplacer les scénarios Devnet/Testnet de `kb-app-demo-desktop`. +`kb-pipeline-demo-scenarios` contient les fixtures, aides de campagne et scénarios réutilisables spécifiques à Devnet ou Testnet. Le desktop doit appeler ces scénarios lorsqu’ils existent plutôt que maintenir une seconde implémentation métier du même parcours. Cette crate peut préparer des wallets temporaires, demander des airdrops, créer des mints ou comptes de test, enchaîner plusieurs opérations et réunir les preuves d’une campagne réseau. Ces responsabilités spécifiques aux validations réseau ne doivent pas remonter dans `kb-pipeline`. Le binaire `kb-pipeline-demo-scenarios-cli` est actuellement un outil ciblé de préparation des fixtures SPL Token-2022 réutilisées par les démonstrations Devnet. Son existence ne signifie pas que chaque scénario doit être exposé par un CLI ni que le desktop doit consommer ses scénarios. -`kb-app-demo-desktop` conserve ses commandes, états et parcours UI de démonstration Devnet/Testnet. Les tests parallèles de `kb-pipeline-demo-scenarios` vérifient des parcours équivalents à partir des APIs généralistes ; ils ne remplacent pas les démonstrations desktop. La dépendance inverse de `kb-pipeline` vers les scénarios reste interdite. +`kb-app-demo-desktop` conserve ses commandes Tauri, états, payloads et parcours de présentation Devnet/Testnet. La logique réutilisable de préparation et d’exécution de campagne appartient à `kb-pipeline-demo-scenarios`. `0.5.4` auditera les scénarios encore déclarés directement dans le desktop et déplacera ceux qui sont réutilisables. La dépendance inverse de `kb-pipeline` vers les scénarios reste interdite. ## 5. Contrats de preuve @@ -57,5 +57,5 @@ Les tests unitaires, tests d’intégration et matrices de `test-fixtures/contra ## 6. Limites connues - Le registre ElGamal n’est pas déclaré validé sur Devnet ou Mainnet. -- La couverture automatisée parallèle des scénarios desktop reste à étendre progressivement dans `kb-pipeline-demo-scenarios`, notamment pendant la série `0.5.x`. -- La documentation détaillée des APIs publiques du pipeline sera produite dans `kb-pipeline/USAGE.md` après inventaire des exports. +- La réconciliation finale des scénarios encore dupliqués entre desktop et `kb-pipeline-demo-scenarios` est planifiée en `0.5.4`. +- Les futurs protocoles doivent conserver cette frontière : orchestration généraliste dans `kb-pipeline`, scénarios réseau réutilisables dans `kb-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop. diff --git a/docs/architecture/PROJECT_OBJECTIVES.md b/docs/architecture/PROJECT_OBJECTIVES.md index 0b7a71c..9fe19e0 100644 --- a/docs/architecture/PROJECT_OBJECTIVES.md +++ b/docs/architecture/PROJECT_OBJECTIVES.md @@ -1,5 +1,5 @@ - + # Objectifs du projet Khadhroony Bot3 @@ -20,7 +20,8 @@ Le projet vise à : - permettre les campagnes historiques, le traitement temps réel et les validations Devnet ; - conserver les preuves de couverture sous forme de tests, fixtures, matrices contractuelles et rapports de validation ; - fournir des scénarios réutilisables indépendamment de l’application desktop ; -- préparer l’ajout progressif de protocoles Solana sans réintroduire une fragmentation excessive du workspace. +- préparer l’ajout progressif de protocoles Solana sans réintroduire une fragmentation excessive du workspace ; +- conserver une vocation généraliste de couverture des Program IDs Solana, même lorsque l’ordre de développement privilégie temporairement les protocoles utiles au trading. ## 3. Principes de conception @@ -46,27 +47,30 @@ La documentation active est réécrite pour bot3 à partir du code, des tests, d ## 4. Périmètre actuel -Le noyau migré couvre notamment : +Le noyau livré jusqu’à `0.4.8` couvre notamment : - Solana Core ; - SPL Memo, avec exécution limitée à Memo v4 ; - SPL Token classique ; - SPL Associated Token Account ; - Token-2022 ; -- registre SPL ElGamal au niveau de certaines couches internes, sans validation Devnet/Mainnet déclarée ; -- décodeur Metaplex Token Metadata partiellement repris pendant le développement de `0.4.7` ; +- registre SPL ElGamal aux couches decoder/executor/stateful/materialization, sans validation réseau réelle déclarée ; +- Solana Program Metadata, avec neuf opérations stables validées sur Devnet ; +- Token-2022 Token Metadata, avec cinq opérations d’interface validées sur Devnet ; +- Metaplex Token Metadata, avec une matrice courante close à 15 `confirmed`, 5 `unavailable` et 0 `not_run` ; - acquisition HTTP et WebSocket ; - stockage PostgreSQL ; -- replay, extraction Core, décodage, matérialisation et scénarios Devnet. +- replay, extraction Core, décodage, matérialisation et scénarios Devnet réutilisables. ## 5. Hors périmètre immédiat Ne sont pas considérés comme achevés : -- l’intégralité de Metaplex Token Metadata ; -- un wallet utilisateur complet ; -- l’autonomie complète de tous les scénarios de démonstration ; -- tous les protocoles Anchor, SPL, Metaplex, AMM, launchpads et routers planifiés ; +- la restructuration des fondations `kb-config`, `kb-wallet` et `kb-store`, planifiée en `0.5.x` ; +- la réconciliation complète des scénarios réutilisables entre `kb-pipeline-demo-scenarios` et le desktop ; +- le décodeur Anchor générique planifié en `0.6.x` ; +- les protocoles trading prioritaires Meteora, Raydium, Pump, Orca et Jupiter ; +- la couverture généraliste différée des autres Program IDs Solana, qui reste un objectif du projet après la séquence trading prioritaire ; - l’application de trading et les workers de production ; - la validation réelle du registre ElGamal sur un cluster où son déploiement et ses prérequis sont confirmés. diff --git a/docs/architecture/STORAGE_ARCHITECTURE.md b/docs/architecture/STORAGE_ARCHITECTURE.md index 350b9a1..d0289af 100644 --- a/docs/architecture/STORAGE_ARCHITECTURE.md +++ b/docs/architecture/STORAGE_ARCHITECTURE.md @@ -1,5 +1,5 @@ - + # Architecture du stockage @@ -47,7 +47,7 @@ Le stockage couvre plusieurs niveaux : - états de campagne et candidats de replay ; - informations opérationnelles et de santé. -Les noms exacts de tables et APIs publiques seront documentés dans `kb-store/USAGE.md` à partir des exports et migrations actuels. +Les noms de tables, contrats de replay et APIs publiques sont documentés dans `kb-store/USAGE.md` à partir des exports et migrations actuels. ## 4. Propriétés attendues @@ -59,6 +59,8 @@ Les noms exacts de tables et APIs publiques seront documentés dans `kb-store/US - erreurs explicites ; - séparation entre données brutes, résultats de décodage et matérialisations. +La série `0.5.3` réauditera cette fondation avant l’arrivée des protocoles trading. Cet audit doit notamment distinguer les timestamps observés sur la blockchain des timestamps d’insertion et de mise à jour locaux, normaliser la structure interne de `kb-store`, vérifier les champs et index manquants et préparer les futures matérialisations trading, routing et multi-pools sans casser les contrats de replay existants. + ## 5. Données de test Les fixtures privées, bases locales et preuves temporaires ne font pas partie des livraisons. Les matrices contractuelles partagées restent sous `test-fixtures/contract-matrices/` lorsqu’elles sont nécessaires aux tests. diff --git a/docs/architecture/SURFACE_CRATE_MATRIX.md b/docs/architecture/SURFACE_CRATE_MATRIX.md index bbf0720..c9a39bf 100644 --- a/docs/architecture/SURFACE_CRATE_MATRIX.md +++ b/docs/architecture/SURFACE_CRATE_MATRIX.md @@ -1,5 +1,5 @@ - + # Matrice des responsabilités par surface @@ -13,23 +13,29 @@ ## 2. Matrice -| Surface | `kb-lib` | `kb-pipeline` | `kb-store` | `kb-onchain-transport` | scénarios | desktop | -|-------------------------|-------------------------------------------------------------------------------------------|---------------------------------------------|--------------------------------------------------------|------------------------|--------------------------------------------|----------------------------------------------| -| Solana Core | décodeurs, exécuteurs, matérialisateurs | extraction, replay, exécution | persistance | RPC | validations Devnet | panneaux fonctionnels | -| SPL Memo | décodage v1/v3/v4, exécution v4 | replay et exécution v4 | persistance | RPC | scénario Memo v4 | panneau Memo v4 | -| SPL Token classique | contrats et implémentations | stateful, préflight, orchestration | persistance | RPC | scénarios Devnet | panneaux fonctionnels | -| SPL ATA | contrats et implémentations | état et orchestration | persistance | RPC | scénarios classique/Token-2022 | panneaux fonctionnels | -| Token-2022 | contrats et implémentations | corrélation, preuves, préflight, validation | persistance | RPC | scénarios Devnet | panneaux fonctionnels | -| Registre ElGamal | implémentation partielle confirmée | traitement stateful à vérifier par API | persistance selon flux | acquisition de comptes | pas de validation réelle déclarée | présentation non raccordée fonctionnellement | -| Metaplex Token Metadata | décodeurs de comptes/instructions et matérialisation migrés ; exécuteur réservé à achever | pipeline généraliste Metaplex à achever | persistance générique présente ; projections à auditer | acquisition standard | scénarios Devnet/Testnet à créer/compléter | adaptateurs et panneaux à créer/compléter | +| Surface | `kb-lib` | `kb-pipeline` | `kb-store` | `kb-onchain-transport` | `kb-pipeline-demo-scenarios` | `kb-app-demo-desktop` | +|---------------------------|--------------------------------------------------------------------------------|------------------------------------------------------|-----------------------|-------------------------------|--------------------------------------------------------|-----------------------------------------------------| +| Solana Core | décodeurs, exécuteurs et matérialisateurs | extraction, replay, stateful et exécution | persistance générique | RPC HTTP/WS | validations Devnet | panneaux fonctionnels | +| SPL Memo | décodage v1/v3/v4 ; exécution v4 | replay et exécution v4 | persistance générique | RPC | scénario Memo v4 | panneau Memo v4 | +| SPL Token classique | décodeur, exécuteur et matérialisateurs | stateful, préflight et orchestration | persistance générique | RPC | scénarios Devnet | panneaux fonctionnels | +| SPL ATA | décodeur, exécuteur et matérialisateurs | stateful et orchestration | persistance générique | RPC | scénarios classique/Token-2022 | panneaux fonctionnels | +| Token-2022 | décodeur, exécuteur et matérialisateurs | corrélation, preuves, stateful, préflight et replay | persistance générique | RPC | scénarios Devnet | panneaux fonctionnels | +| Registre SPL ElGamal | décodeur, exécuteur et matérialisation administrative | stateful et orchestration | persistance générique | acquisition de comptes et RPC | scénarios déclarés ; validation réseau réelle reportée | construction de plans et présentation | +| Solana Program Metadata | décodeur comptes/instructions, exécuteur et matérialiseur | stateful, préflight et orchestration d’exécution | persistance générique | RPC et lectures de comptes | 2 parcours Devnet ; 9 opérations `confirmed` | campagne dédiée dans `demo_execution_metadata` | +| Token-2022 Token Metadata | décodage interface/TLV, exécution des 5 opérations et matérialisation Metadata | stateful, préflight, replay et postconditions | persistance générique | RPC et lectures de comptes | campagne Devnet complète ; 5 opérations `confirmed` | campagne dédiée dans `demo_execution_metadata` | +| Metaplex Token Metadata | décodeurs comptes/instructions, exécuteur courant/deprecated et matérialiseur | stateful, préflight, orchestration et postconditions | persistance générique | RPC et lectures de comptes | campagnes qualifiées ; 15 `confirmed`, 5 `unavailable` | campagnes qualifiées dans `demo_execution_metadata` | ## 3. Interprétation -Cette matrice décrit les responsabilités observées au niveau architectural. Elle ne déclare pas une couverture exhaustive de chaque instruction ou compte. La couverture détaillée reste démontrée par le code, les tests et les matrices sous `test-fixtures/contract-matrices/`. +Cette matrice décrit les responsabilités observées au niveau architectural. Elle ne déclare pas une couverture exhaustive de chaque instruction ou compte. La couverture détaillée reste démontrée par le code, les tests, les matrices sous `test-fixtures/contract-matrices/` et les rapports de validation actifs ou archivés. + +La persistance des surfaces Metadata repose sur les contrats génériques de decode/materialization de `kb-store`. Leur séparation métier est portée notamment par les identités de processeur, les familles matérialisées, les clés de sortie et les payloads versionnés ; `0.4.8` n’introduit donc pas de schéma PostgreSQL spécialisé par protocole Metadata. ## 4. Statuts sensibles -- Memo v1 et v3 restent non exécutables. -- Memo v4 est exécutable. -- Le registre ElGamal ne doit pas être présenté comme validé Devnet/Mainnet. -- Tout le travail Metaplex Token Metadata réalisé dans bot2 a été migré dans bot3. `0.4.7` doit achever la surface sans présenter cette migration comme partielle. +- Memo v1 et v3 restent non exécutables ; Memo v4 est exécutable. +- Le registre SPL ElGamal est implémenté aux couches decoder/executor/stateful/materialization, mais ne doit pas être présenté comme validé sur Devnet ou Mainnet tant qu’une fixture réelle de preuve `PubkeyValidity` et de `Proof Context State` n’est pas disponible et confirmée. +- Solana Program Metadata est couvert par neuf opérations stables, toutes validées sur Devnet. +- Token-2022 Token Metadata est couvert par cinq opérations d’interface, toutes validées sur Devnet. +- Metaplex Token Metadata est clos pour la matrice courante de `0.4.8` avec 15 opérations `confirmed`, 5 `unavailable` et 0 `not_run` ; les opérations indisponibles ne doivent pas être promues sans nouvelle preuve réseau. +- La priorité trading des versions suivantes n’altère pas la vocation généraliste de `kb-lib` : les autres Program IDs restent dans le périmètre de couverture et peuvent être différés selon leur priorité de développement.