v0.1.0-pre.076

docs/README.md

@@ -93,3 +93,6 @@ Les onze crates possèdent désormais `README.md`, `TODO.md`, `USAGE.md` et `CHA
 - [Extraction Core, replay et matérialisation](guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md)
 - [PostgreSQL et stockage](guides/POSTGRES_STORAGE.md)
 - [Validation Devnet](guides/DEVNET_VALIDATION.md)
+- [`validation/PRE_062_DEVNET_VALIDATION_REPORT.md`](validation/PRE_062_DEVNET_VALIDATION_REPORT.md) ;
+- [`validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md`](validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md) ;
+- [`validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md`](validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md) ;

docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/guides/DEVNET_0_4_6_OPERATOR_GUIDE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Guide opérateur Devnet pour l’alignement `0.4.6`
 
@@ -37,41 +37,17 @@ Depuis les fenêtres SQL :
 7. Rejouer la même sélection.
 8. Confirmer l’idempotence et l’absence de duplications.
 
-## 5. Exécution Solana Core
+## 5. Exécutions Solana Core déjà validées
 
-Pour System Transfer :
+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.
 
-- vérifier le wallet et la balance ;
-- générer ou saisir un destinataire ;
-- utiliser un montant minimal ;
-- exécuter d’abord la simulation ;
-- confirmer explicitement l’envoi ;
-- vérifier la signature finalisée ;
-- effectuer backfill, Core extraction et replay ;
-- vérifier les observations et projections attendues.
+La preuve active est conservée dans [`PRE_062_DEVNET_VALIDATION_REPORT.md`](../validation/PRE_062_DEVNET_VALIDATION_REPORT.md).
 
-## 6. Exécution SPL
+## 6. Exécutions SPL déjà validées
 
-Valider séparément :
+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.
 
-- Memo v4 ;
-- ATA classique ;
-- ATA Token-2022 ;
-- SPL Token classique `TransferChecked` ;
-- opérations Token-2022 documentées comme supportées.
-
-Pour chaque scénario :
-
-1. vérifier les préconditions et comptes ;
-2. vérifier les signers ;
-3. simuler ;
-4. confirmer l’envoi ;
-5. vérifier la confirmation réseau ;
-6. effectuer le backfill ;
-7. effectuer Core extraction ;
-8. effectuer Decode replay et matérialisation ;
-9. rejouer pour l’idempotence ;
-10. vérifier l’état final via CLI ou RPC lorsque pertinent.
+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
 

docs/validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md

@@ -0,0 +1,46 @@
+<!-- file: docs/validation/MAINNET_RESEARCH_BACKFILL_VALIDATION_SCENARIO.md -->
+<!-- version: 1 -->
+
+# Scénario de validation backfill `mainnet_research`
+
+## Objectif
+
+Valider un parcours borné `raw → Core → decode → materialize` sur Mainnet sans envoi de transaction.
+
+## Paramètres recommandés
+
+- profil : `mainnet_research` ;
+- rôle HTTP : endpoint standard Mainnet configuré ;
+- commitment : `finalized` ;
+- taille de page : `20` ;
+- pages maximales : `1` ;
+- concurrence : `2` ;
+- retries : `2` ;
+- mode : Programme Solana ;
+- Program ID : `MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr` ;
+- direction : `before` ;
+- signature d’ancrage : vide ;
+- nombre de signatures : `20`.
+
+Memo v4 est choisi pour limiter le volume et disposer d’un décodeur et d’un matérialisateur connus.
+
+## Étapes
+
+1. Relever les diagnostics PostgreSQL avant campagne.
+2. Lancer le backfill et conserver le résumé JSON.
+3. Vérifier les nouvelles lignes raw et observations.
+4. Exécuter Core extraction uniquement sur les lignes non traitées.
+5. Exécuter Decode replay avec Memo v4 et matérialisation activée.
+6. Vérifier les annotations matérialisées.
+7. Rejouer la même sélection et confirmer l’idempotence.
+8. Relever les diagnostics PostgreSQL après campagne.
+
+## Critères de réussite
+
+- campagne bornée terminée sans échec non expliqué ;
+- transactions hydratées et stockées ;
+- extraction Core sans doublon ;
+- décodage Memo cohérent ;
+- matérialisation attendue ;
+- second replay sans duplication ;
+- aucune écriture ou transaction envoyée sur Mainnet.

docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md

@@ -1,5 +1,5 @@
-<!-- file: docs/PRE_062_DEVNET_VALIDATION_REPORT.md -->
-<!-- version: 1 -->
+<!-- file: docs/validation/PRE_062_DEVNET_VALIDATION_REPORT.md -->
+<!-- version: 2 -->
 
 # Rapport de validation Devnet — `0.1.0-pre.062`
 

docs/validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md

@@ -0,0 +1,26 @@
+<!-- file: docs/validation/WEBSOCKET_MAINNET_RESEARCH_VALIDATION_REPORT.md -->
+<!-- version: 1 -->
+
+# Validation WebSocket `mainnet_research` — `0.1.0-pre.075`
+
+## Portée
+
+La campagne a utilisé le profil `mainnet_research` et une souscription `logsSubscribe`. Les secrets et URLs contenant une clé API ne sont pas reproduits dans ce rapport.
+
+## Preuves observées
+
+- ouverture de `demo_ws` à `11:14:17` ;
+- connexion de la session persistante à `11:15:02` ;
+- souscription `logsSubscribe` créée avec l’identifiant `16376948` ;
+- nouvelles ouvertures de `demo_ws` à `11:16:16` puis `11:16:51` sans déconnexion intermédiaire ;
+- notifications reçues avec le même identifiant de souscription après réouverture ;
+- désabonnement explicite à `11:16:56` ;
+- déconnexion explicite de la session à `11:17:04`.
+
+## Conclusion
+
+La campagne valide que la fermeture et la réouverture de la fenêtre ne détruisent pas la session WebSocket applicative, que l’état de souscription reste récupérable et que la fermeture réseau intervient sur action explicite.
+
+## Limite observée
+
+Le Program ID SPL Token classique produit un volume trop élevé pour un test opérateur confortable. Les logs montrent du throttling UI et des événements internes perdus. Les prochaines campagnes doivent utiliser un programme moins actif ou une fenêtre courte, sans interpréter ces pertes UI comme une perte de la session réseau.