Sasedev/khadhroony-bot3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.4.8-pre.015

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-09 12:57:24 +02:00
parent aec7b4b76a
commit 3a509acb82
17 changed files with 570 additions and 271 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
docs/DEVNET_EXECUTION_GUIDE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/DEVNET_EXECUTION_GUIDE.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# Guide d’exécution Devnet
@@ -14,8 +14,8 @@ Ce guide décrit la campagne Devnet de `kb-app-demo-desktop` et `kb-pipeline-dem
5. SPL Associated Token Account — mint Token-2022 ;
6. SPL Token classique ;
7. Token-2022 ;
8. registre ElGamal ;
9. Metaplex Token Metadata — préparation de fixture, simulation puis soumission explicite.
8. registre ElGamal — reporté tant que sa fixture de preuve réelle manque ;
9. Metadata on-chain — Solana Program Metadata, Token-2022 Token Metadata et Metaplex Token Metadata dans `demo_execution_metadata`.
Les commandes réutilisables sont centralisées en section 4. Chaque scénario référence leur identifiant `Cxx` au lieu de les recopier.
@@ -100,7 +100,7 @@ Arrêter avec `Ctrl+C`, puis relancer `T01`.
### C01 — Initialiser l’environnement de validation
```bash
cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/current" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet : %s\n' "$KB_DEVNET_WALLET";
cd ~/Projects/khadhroony-bot3 && set -o pipefail && export KB_DEVNET_PROFILE="local_devnet" && export KB_DEVNET_RPC_URL="https://api.devnet.solana.com" && export KB_DEVNET_VALIDATION_DIR="/tmp/devnet-validation/current" && export KB_DEVNET_WALLET="$PWD/wallets/temporary/local_devnet/local-devnet-operator.json" && mkdir -p "$KB_DEVNET_VALIDATION_DIR" && printf 'Profil : %s\n' "$KB_DEVNET_PROFILE" && printf 'RPC Devnet : %s\n' "$KB_DEVNET_RPC_URL" && printf 'Preuves : %s\n' "$KB_DEVNET_VALIDATION_DIR" && printf 'Wallet : %s\n' "$KB_DEVNET_WALLET";
```
### C02 — Capturer les versions CLI
@@ -114,7 +114,7 @@ Chaque campagne doit capturer les versions exactes des outils externes qu’elle
### C03 — Vérifier l’identité du réseau
```bash
solana config set --url "$KB_DEVNET_RPC_URL" && { date --iso-8601=seconds; solana config get; solana cluster-version --url "$KB_DEVNET_RPC_URL"; solana genesis-hash --url "$KB_DEVNET_RPC_URL"; solana epoch-info --url "$KB_DEVNET_RPC_URL"; } | tee "$KB_DEVNET_VALIDATION_DIR/01-devnet-network.txt";
solana config set --url "$KB_DEVNET_RPC_URL" && { date --iso-8601=seconds; solana config get; solana cluster-version --url "$KB_DEVNET_RPC_URL"; solana genesis-hash --url "$KB_DEVNET_RPC_URL"; solana epoch-info --url "$KB_DEVNET_RPC_URL"; } | tee "$KB_DEVNET_VALIDATION_DIR/01-devnet-network.txt";
```
Le genesis hash Devnet attendu est :
@@ -302,8 +302,6 @@ Le compte `TOKEN_2022_CLOSE_ACCOUNT` doit rester vide jusqu'au scénario `CloseA
### C12 — Preuves applicatives communes
Pour chaque scénario, conserver depuis l’application :
- profil et cluster résolus ;
@@ -776,37 +774,60 @@ Les champs envisagés sont :
Ne pas fabriquer une preuve de validation à partir d’un compte quelconque. La future campagne S06 devra produire sa propre fixture, exécuter simulation et envoi, confirmer la signature, puis vérifier insertion canonique, extraction Core, replay, projection admin et idempotence.
## 12. Future fenêtre Metadata
## 12. Scénario S07 — Metadata on-chain
La future fenêtre metadata devra suivre la même structure : commandes communes `C01` à `C12`, puis scénarios séparés pour les metadata incorporées Token-2022, Metaplex Token Metadata et l’enrichissement off-chain indépendant.
### Surface réellement exposée
La fenêtre `demo_execution_metadata` regroupe trois domaines on-chain distincts sans les fusionner :
- Solana Program Metadata, Program ID `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S` ;
- Token-2022 Token Metadata, exécuté par le programme Token-2022 à partir du contrat `spl-token-metadata-interface` ;
- Metaplex Token Metadata, Program ID `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`.
Le profil Devnet sélectionné est synchronisé entre les trois accordéons. Les résultats détaillés utilisent les trois accordéons **Préflight et opérations**, **Simulation et confirmation** et **Postconditions et preuves**. Le journal d’exécution reste en pleine largeur sous la grille. Aucun bouton de fetch HTTP, IPFS ou Arweave n’est exposé.
### Qualification courante
Les matrices réseau actives sont déjà qualifiées :
- Solana Program Metadata : neuf opérations `confirmed` par les deux campagnes `pre.010` ;
- Token-2022 Token Metadata : cinq opérations `confirmed` par la campagne `pre.012` (`Initialize`, `UpdateField`, `Emit`, `RemoveKey`, `UpdateAuthority`) ;
- Metaplex Token Metadata : 20 opérations courantes classées en `pre.013`, avec 15 `confirmed`, 5 `unavailable` et 0 `not_run`.
Les cinq indisponibilités Metaplex restent bornées par leurs preuves runtime : `Use`, `Resize`, `Migrate`, `Collect` et `CloseAccounts`. Une simulation négative ne doit jamais être transformée en autorisation de soumission.
### Revalidation depuis le desktop
Une revalidation complète n’est pas requise à chaque changement documentaire. En cas de régression du runtime, du transport, de l’orchestration ou du panneau :
1. démarrer Tauri avec `T01` et sélectionner un profil Devnet persistant ;
2. préparer la base depuis le panneau Metadata ;
3. conserver `simulation-first`, les limites de coût et la confirmation opérateur explicite ;
4. exécuter uniquement la campagne spécialisée concernée ;
5. vérifier la confirmation, l’hydratation canonique, l’extraction Core, le replay, la matérialisation, les postconditions et l’idempotence ;
6. comparer le résultat à la matrice Devnet active du domaine avant toute modification de statut.
Pour Metaplex, utiliser les campagnes qualifiées du panneau (`Create -> Mint`, collection, `Print -> Burn`, lifecycle pNFT, escrow, maintenance et probe `Use`) plutôt que reconstruire manuellement un intent générique. Pour Token-2022 Token Metadata et Solana Program Metadata, utiliser leurs campagnes dédiées déjà exposées par le panneau.
### Critères de validation
- le Program ID et le domaine sélectionnés restent exacts ;
- les transactions soumises sont précédées d’une simulation réussie du même message ;
- les opérations classées `unavailable` restent simulation-only ;
- les preuves canonical/Core/replay/materialization/postconditions restent cohérentes avec la matrice active ;
- les JsonViewer ne remplacent pas les preuves persistées ; ils les rendent seulement observables dans le desktop ;
- aucune résolution off-chain n’est effectuée par le replay canonique ou par le panneau Metadata.
## 13. Critères de clôture de la campagne
La campagne est clôturable uniquement lorsque :
- tous les scénarios déclarés validables dans la campagne ont été rejoués depuis une base Devnet propre ;
- toutes les signatures S01 à S05 sont confirmées sur Devnet ;
- toutes les signatures des scénarios effectivement rejoués sont confirmées sur Devnet ;
- toute surface reportée est identifiée explicitement avec ses prérequis manquants ;
- les preuves S07 restent concordantes avec les matrices Metadata actives, sans imposer un rerun réseau en l’absence de régression ;
- les identités persistées respectent la nomenclature canonique ;
- aucun ancien `processor_name`, `surface_code`, `operation_code` ou `event_code` ne subsiste ;
- le replay ciblé est sans échec ni erreur de traitement ;
- les projections sont présentes et idempotentes ;
- le présent guide reflète les commandes réellement exécutées.
## 10. Metaplex Token Metadata
Dans `demo_execution_metadata`, sélectionner un profil Devnet puis préparer sa base. Le panneau charge le même inventaire de profils que les démonstrations Solana Core et SPL.
Pour `Create`, utiliser **Préparer la fixture Create**. Cette action :
1. charge le wallet persistant du profil ;
2. crée ou réutilise un mint SPL classique à zéro décimale ;
3. dérive automatiquement les PDA `metadata` et `master edition` ;
4. génère l’intent typé prêt à simuler.
Les placeholders entre chevrons ne sont jamais des valeurs exécutables. Toujours lancer une simulation RPC avant d’activer la soumission et la confirmation opérateur. Le journal du panneau et les blocs JSON titrés constituent les preuves applicatives immédiates ; la signature, le slot et les postconditions sont requis pour déclarer une validation réseau.
### Paramètres communs du panneau Metadata
Le panneau Metaplex utilise le même modèle opérateur que Solana Core et SPL : profil Devnet préparé, limites de dépense visibles, journal commun avec une seule barre `Copier` / `Effacer`, bouton de simulation distinct du bouton de soumission et confirmation opérateur séparée. Une soumission construit un plan avec `dry_run = false`, mais la transaction ne peut être signée ou envoyée qu'après réussite de la simulation exacte du même message.