v0.4.7-pre.011

docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/V0_4_7_METAPLEX_TOKEN_METADATA_COMPLETION_PLAN.md -->
-<!-- version: 11 -->
+<!-- version: 13 -->
 
 # Plan `0.4.7` — achèvement de Metaplex Token Metadata
 
@@ -304,7 +304,7 @@ Les scénarios UI Devnet/Testnet restent dans `kb-app-demo-desktop`. `kb-pipelin
 - envoi et postcondition uniquement avec fixture contrôlée ;
 - statut réseau exact consigné par opération.
 
-**Recommandation : Option B.** La version peut clôturer avec certaines opérations validées synthétiquement seulement, à condition que ce statut soit explicite et que leur exécution publique soit limitée en conséquence.
+**Décision révisée : validation Devnet obligatoire pour la surface courante.** Les niveaux de preuve restent distincts, mais `0.4.7` ne peut plus être clôturée tant que les opérations `executable_current` n'ont pas été exercées sur Devnet par des scénarios réels. Les opérations `executable_deprecated` restent hors campagne réseau obligatoire et ne sont exécutées que dans une campagne séparée, volontaire et explicitement approuvée. Une impossibilité réseau démontrée doit être documentée opération par opération et ne peut pas être remplacée par une preuve synthétique.
 
 ## 7. Ordonnancement proposé par prerelease
 
@@ -484,7 +484,65 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
 - matrice, tests, rapports et runtime alignés ;
 - écarts résiduels fermés ou reportés explicitement.
 
-### `0.4.7-pre.011` — clôture
+### `0.4.7-pre.011` — infrastructure et premières campagnes Devnet réelles
+
+**Dépendance** : exécuteur, pipeline, fixtures synthétiques et desktop stabilisés.
+
+**Travaux**
+
+- rouvrir la version après le rejet de la clôture prématurée ;
+- produire une liste machine-readable fermée des 20 opérations `executable_current` ;
+- définir pour chacune la fixture, les autorités, les fonds, les comptes préexistants, les effets attendus et la stratégie de nettoyage ;
+- ajouter les primitives réutilisables de préparation de fixtures Devnet dans `kb-pipeline-demo-scenarios` ;
+- exécuter réellement sur Devnet un premier lot cohérent couvrant au minimum création, mise à jour, vérification et révocation de vérification ;
+- enregistrer endpoint/cluster, signature, slot, logs de simulation, résultat de soumission, états avant/après et postconditions ;
+- interdire qu'un résultat synthétique puisse satisfaire un contrat de preuve réseau.
+
+**Acceptation**
+
+- le profil et la base Devnet sont chargés et vérifiés ;
+- chaque scénario du premier lot effectue au minimum une simulation RPC réelle ;
+- les scénarios mutateurs retenus effectuent une soumission réelle après garde-fou explicite ;
+- les preuves sont persistées dans des résultats structurés et réutilisables ;
+- aucune opération dépréciée n'est exécutée automatiquement.
+
+### `0.4.7-pre.012` — couverture Devnet des opérations courantes restantes
+
+**Travaux**
+
+- compléter les campagnes automatisées pour toutes les opérations `executable_current` restantes ;
+- couvrir les familles metadata, collections/créateurs, délégations, programmable NFT, éditions, uses, escrow et maintenance de comptes lorsque leurs préconditions sont disponibles ;
+- créer ou réutiliser des fixtures NFT, SFT, fungible, collection et pNFT ;
+- tester les échecs attendus : mauvaise autorité, mauvais PDA, owner invalide, rule set incohérent, comptes manquants et plafond de dépense ;
+- conserver simulation-only par défaut, avec soumission activée uniquement par une option explicite de campagne ;
+- consigner toute impossibilité Devnet démontrée avec cause externe précise, tentative reproductible et preuve associée.
+
+**Acceptation**
+
+- les 20 opérations `executable_current` ont chacune un scénario Devnet réel ;
+- chaque opération possède une simulation RPC observée ou une impossibilité réseau démontrée et documentée ;
+- chaque opération mutatrice réalisable possède au moins une soumission confirmée et une postcondition stateful observée ;
+- les résultats ne dépendent pas du desktop et utilisent exclusivement les APIs généralistes de `kb-pipeline`.
+
+### `0.4.7-pre.013` — démonstrations desktop Devnet et validation croisée finale
+
+**Travaux**
+
+- raccorder le panneau Metadata aux scénarios réseau réutilisables, sans déplacer leur logique métier dans Tauri ;
+- conserver les scénarios UI dans `kb-app-demo-desktop` et les tests automatisés parallèles dans `kb-pipeline-demo-scenarios` ;
+- afficher profil, cluster, base, wallet, fixture, mode simulation/soumission, signature, slot, logs et postconditions ;
+- permettre l'exécution manuelle des opérations courantes retenues depuis le desktop avec confirmation opérateur ;
+- comparer les résultats automatisés et desktop sur les mêmes contrats de preuve ;
+- exécuter les validations croisées outer/CPI, succès/échec et replay PostgreSQL idempotent.
+
+**Acceptation**
+
+- le mode Devnet déclenche réellement les appels RPC et ne se limite jamais à changer un JSON frontend ;
+- les scénarios desktop et automatisés produisent des preuves compatibles ;
+- les 20 opérations courantes ont un statut réseau final exact ;
+- les opérations dépréciées restent clairement séparées et désactivées par défaut.
+
+### `0.4.7-pre.014` — clôture
 
 **Travaux**
 
@@ -493,13 +551,14 @@ La numérotation ci-dessous est un plan fermé initial. Elle peut être regroup
 - documentation générale et des crates ;
 - nettoyage des TODO, outils temporaires et références obsolètes ;
 - archivage du présent plan et des rapports devenus historiques ;
-- prompt `0.4.8` avec prerelease initiale de planification et prerelease finale de clôture ;
+- préparation seulement à ce stade du prompt `0.4.8`, avec prerelease initiale de planification et prerelease finale de clôture ;
 - livraison finale.
 
 **Acceptation**
 
 - commandes de validation finales réussies ;
-- code, matrices, registres, bindings et documentation alignés ;
+- preuves Devnet des opérations courantes alignées avec code, matrices, registres, bindings et documentation ;
+- aucun cas `executable_current` laissé avec un statut réseau ambigu ;
 - archive finale conforme aux règles du workspace.
 
 ## 8. Dépendances et ordre critique
@@ -513,8 +572,9 @@ L’ordre critique est :
 5. pipeline stateful ;
 6. fixtures et validations automatisées Devnet/Testnet ;
 7. scénarios UI desktop ;
-8. validation croisée ;
-9. clôture.
+8. campagnes Devnet réelles automatisées ;
+9. démonstrations desktop Devnet et validation croisée finale ;
+10. clôture.
 
 Le desktop ne doit pas précéder la stabilisation des APIs généralistes et des contrats de fixtures. `kb-pipeline-demo-scenarios` ne doit pas absorber une orchestration généraliste ni remplacer les scénarios UI du desktop. Le pipeline ne doit pas autoriser la préparation ou l’envoi d’une opération avant stabilisation de son intent et de son contrat stateful. Une instruction ne doit pas être déclarée envoyable uniquement parce qu’un builder SDK existe, mais tout builder officiellement constructible doit être implémenté dans `kb-lib` sauf statut historique, obsolète ou remplacé documenté.
 
@@ -573,7 +633,7 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
 3. propriété des faits par domaines metadata/admin/lifecycle/risk ;
 4. rule sets programmables fail-closed ;
 5. niveaux de preuve distincts pour les validations synthétiques, simulation réseau et envoi réel ;
-6. séquence de prereleases `pre.002` à `pre.011` décrite ci-dessus.
+6. séquence de prereleases `pre.002` à `pre.014` décrite ci-dessus, la clôture étant repoussée à `pre.014`.
 
 
 ## État de `0.4.7-pre.007`
@@ -601,3 +661,12 @@ Le développement fonctionnel peut commencer après acceptation des recommandati
 - affichage des exigences de préflight, simulation-first et postconditions ;
 - scénario sélectionné restauré à la réouverture ;
 - aucune logique métier dupliquée et aucune soumission automatique.
+
+
+## État de `0.4.7-pre.011`
+
+- matrice fermée des 20 opérations courantes ;
+- runner Devnet réel générique avec simulation RPC, soumission contrôlée, confirmation et lectures stateful avant/après ;
+- premier lot attribué à `Create`, `Update`, `Verify` et `Unverify` ;
+- preuves réseau encore `not_run` jusqu’aux exécutions locales et à la validation des postconditions métier ;
+- opérations dépréciées refusées dans les campagnes automatiques.