v0.4.7-pre.013

kb-pipeline/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-pipeline/USAGE.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Utilisation de kb-pipeline
 
@@ -232,6 +232,18 @@ fn inspect_metaplex_preflight(
 
 Une opération marquée dépréciée par `kb-lib` est refusée lorsque `allow_deprecated_operation` vaut `false`.
 
+### Exigences stateful par famille
+
+Le pipeline ne doit pas considérer un intent sérialisé comme prêt à exécuter sans snapshots adaptés :
+
+- création : lire le mint et vérifier owner, décimales, supply, mint authority et freeze authority avant la construction finale ; les PDA metadata et edition doivent être absents ou compatibles selon la variante ;
+- mutation : lire metadata et, lorsque requis, edition, token account, token record, delegate record, collection metadata et rule set ;
+- vérification : prouver la relation d’autorité visée avant l’instruction et relire le bit ou l’enregistrement modifié après confirmation ;
+- délégation, verrouillage, transfert et burn : corréler le mint, le token account, le token record programmable et les autorités exactes ;
+- escrow, print, use, collect, migrate et resize : fournir les comptes spécialisés de la variante et définir une postcondition observable.
+
+Une campagne sans modèle préparé doit rester bloquée. Elle ne doit jamais réutiliser l’intent de l’opération précédemment sélectionnée.
+
 ## Valider l’enveloppe d’exécution Metaplex
 
 L’orchestration refuse la signature ou la soumission tant que la simulation exacte du message, les signers et la confirmation opérateur ne sont pas cohérents.
@@ -272,3 +284,16 @@ fn summarize_metaplex_postconditions(
 ```
 
 `Contradicted` est prioritaire sur `Confirmed`, et l’absence de postcondition applicable reste `NotApplicable`.
+
+## Orchestration des scénarios Metaplex
+
+`kb-pipeline-demo-scenarios` expose des parcours déclaratifs plutôt que cent combinaisons forcées. Chaque parcours déclare :
+
+- la famille d’asset ;
+- la fixture requise ;
+- l’état initial ;
+- les opérations ordonnées ;
+- l’état terminal attendu ;
+- les comptes et projections nécessaires aux postconditions.
+
+Lorsque `materialize_after_confirmation` est activé, une soumission exige au moins une lecture de postcondition. Après confirmation, les snapshots bornés sont décodés et projetés. Lorsque l’option est désactivée, le runner conserve la simulation, la soumission, la confirmation et les postconditions demandées, mais n’émet pas les projections de matérialisation.