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

v0.4.6

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-01 21:27:14 +02:00
parent e91d0aa2cb
commit ae85852648
38 changed files with 413 additions and 291 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md
View File

@@ -1,75 +0,0 @@
<!-- file: docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md -->
<!-- version: 2 -->
# Guide opérateur Devnet pour l’alignement `0.4.6`
## 1. Objectif
Ce guide regroupe les opérations minimales à valider avant le passage officiel de bot3 à `0.4.6`.
## 2. Préparer le profil
- sélectionner un profil Devnet valide ;
- vérifier le RPC HTTP, le WebSocket et PostgreSQL ;
- vérifier que `auto_initialize_schema` correspond à l’intention de la campagne ;
- utiliser un wallet de démonstration persistant et financé par faucet Web.
La clé privée ne doit jamais être copiée dans les logs ou l’interface.
## 3. Vérifier PostgreSQL
Depuis les fenêtres SQL :
1. charger le diagnostic général ;
2. vérifier les tables raw ;
3. vérifier les tables Core ;
4. vérifier les tables decode/materialization ;
5. noter la version de migration et les anomalies d’index ou contraintes.
## 4. Campagne raw → Core → Decode → Materialize
1. Exécuter un backfill borné sur un Program ID ou une adresse connue.
2. Vérifier l’insertion raw et les observations.
3. Exécuter Core extraction sur les nouvelles lignes.
4. Exécuter Decode replay avec les décodeurs adaptés.
5. Activer la matérialisation.
6. Vérifier les diagnostics et projections.
7. Rejouer la même sélection.
8. Confirmer l’idempotence et l’absence de duplications.
## 5. Exécutions Solana Core déjà validées
System Transfer et Memo v4 ont déjà été validés pendant `0.1.0-pre.062`. Leur réexécution n’est pas un prérequis systématique de `0.4.6`, sauf si une correction ultérieure touche directement leur exécuteur, leur transport, leur insertion canonique, leur replay ou leur matérialisation.
La preuve active est conservée dans [`PRE_062_DEVNET_VALIDATION_REPORT.md`](../validation/PRE_062_DEVNET_VALIDATION_REPORT.md).
## 6. Exécutions SPL déjà validées
ATA classique, ATA Token-2022, SPL Token classique `TransferChecked` et les huit opérations publiques Token-2022 documentées ont déjà été validés pendant `0.1.0-pre.062`, avec PostgreSQL, insertion canonique, extraction Core, replay, matérialisation et idempotence.
Ces scénarios ne doivent être rejoués que si une correction postérieure affecte leur parcours. La campagne `0.4.6` restante se concentre sur les écarts réellement modifiés et sur un backfill borné `mainnet_research`.
## 7. WebSocket
Exécuter intégralement [`WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md`](../validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md).
## 8. Résultats à consigner
Pour chaque campagne, conserver :
- profil et cluster ;
- opération ;
- comptes publics concernés ;
- signature ;
- résultat simulation ;
- résultat envoi et confirmation ;
- nombres raw/Core/decode/materialize ;
- diagnostics ;
- résultat du second replay ;
- commande CLI ou RPC de vérification finale.
## 9. Hors périmètre
Metaplex Token Metadata complet n’est pas un critère de `0.4.6`. Il sera planifié et terminé dans `0.4.7`.
Le registre ElGamal reste conditionnel tant que son déploiement réseau et les preuves nécessaires ne sont pas confirmés.