v0.4.8-pre.008

kb-lib/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-lib/USAGE.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Utilisation de kb-lib
 
@@ -153,10 +153,16 @@ println!("status={:?}", result.status);
 
 Le tag `5` est toujours publié comme `trim`. Son ancien nom pré-stable `withdraw_excess_lamports` est conservé uniquement comme provenance, car aucune release stable ne l’expose comme instruction distincte. Les URL et références externes restent des données on-chain ; le décodeur ne réalise aucun fetch.
 
-Le matérialiseur `MtMetadataMaterializer` accepte les neuf observations d’instructions de la surface exacte `metadata.solana_program_metadata`. Il refuse les transactions échouées et produit un fait de mutation par instruction. Ces faits ne remplacent pas un snapshot de compte : l’état final doit être matérialisé depuis la lecture post-exécution.
+Les trois domaines metadata disposent de matérialiseurs instructionnels spécialisés :
+
+- `MtMetadataMetaplexTokenMetadataMaterializer` pour les observations Metaplex de famille metadata ;
+- `MtMetadataSolanaProgramMaterializer` pour les neuf instructions stables de `ProgM6…` ;
+- `MtMetadataToken2022Materializer` pour les instructions incorporées Token Metadata et Token Group de Token-2022.
+
+Chaque type possède son propre `componentName`, son propre `processorName`, ses familles acceptées et un ownership exact. Les transactions échouées sont refusées. Les faits d’instructions ne remplacent jamais les snapshots autoritatifs lus après exécution.
 
 ```rust
-let materializer = kb_lib::MtMetadataMaterializer;
+let materializer = kb_lib::MtMetadataSolanaProgramMaterializer;
 if kb_lib::MtApiEventMaterializer::accepts_observation(&materializer, &observation) {
     let result = kb_lib::MtApiEventMaterializer::materialize(&materializer, &observation);
     println!("materialization status={:?}", result.status);