v0.1.0-pre.062-fix
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/DEVNET_EXECUTION_GUIDE.md -->
|
||||
<!-- version: 19 -->
|
||||
<!-- version: 20 -->
|
||||
|
||||
# Guide d’exécution Devnet
|
||||
|
||||
@@ -755,24 +755,25 @@ puis `50b`, `50c`, etc., avant chaque appel à `C07`.
|
||||
- chaque replay est sans échec ;
|
||||
- le second replay est idempotent.
|
||||
|
||||
## 11. Scénario S06 — Registre ElGamal
|
||||
## 11. Scénario S06 — Registre ElGamal — reporté
|
||||
|
||||
### Objectif
|
||||
### Statut de `0.1.0-pre.062`
|
||||
|
||||
Valider le programme indépendant de registre ElGamal sans le confondre avec Token-2022.
|
||||
Le registre ElGamal reste implémenté mais **non validé sur Devnet** dans cette campagne. Ce report ne remet pas en cause les validations S01 à S05.
|
||||
|
||||
### Procédure
|
||||
Deux prérequis manquent :
|
||||
|
||||
1. Définir puis exécuter `C06` :
|
||||
- une fixture créant un compte de contexte de preuve `PubkeyValidity` valide et owned par le programme natif ZK ElGamal Proof ;
|
||||
- le raccordement complet du panneau desktop : lecture des champs, handler du bouton **Construire le plan Registry**, commande Tauri, rendu du plan et affichage borné des erreurs.
|
||||
|
||||
```bash
|
||||
export KB_DEVNET_SCENARIO="60-spl-elgamal-registry"
|
||||
```
|
||||
Les champs envisagés sont :
|
||||
|
||||
2. Vérifier le Program ID, le PDA de registre, l’owner, la longueur exacte du compte et les preuves requises.
|
||||
3. Simuler create/update selon le scénario disponible.
|
||||
4. Confirmer l’envoi, exécuter `C07`, puis appliquer `C08`.
|
||||
5. Vérifier la projection admin du registre et l’absence de fausse projection Token-2022.
|
||||
- fee payer : wallet opérateur ;
|
||||
- owner du registre : wallet opérateur ;
|
||||
- opération initiale : `CreateRegistry` ;
|
||||
- proof context state account : compte de contexte `PubkeyValidity` réel, jamais une adresse arbitraire.
|
||||
|
||||
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
|
||||
|
||||
@@ -782,8 +783,9 @@ La future fenêtre metadata devra suivre la même structure : commandes communes
|
||||
|
||||
La campagne est clôturable uniquement lorsque :
|
||||
|
||||
- tous les scénarios disponibles ont été rejoués depuis une base Devnet propre ;
|
||||
- toutes les signatures sont confirmées sur Devnet ;
|
||||
- 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 ;
|
||||
- toute surface reportée est identifiée explicitement avec ses prérequis manquants ;
|
||||
- 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 ;
|
||||
|
||||
Reference in New Issue
Block a user