v0.4.6

olddocs/archivekbot3/docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md

@@ -0,0 +1,75 @@
+<!-- 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.