0.3.15-pre.014

docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # Validation v0.3.15 — Raw Transaction Ingest Desk
 
@@ -885,3 +885,78 @@ Aucun type du coordinateur n'est exporté publiquement.
 
 Validation live requise : Yellowstone Mainnet seul pendant une durée supérieure aux ~80 s de reproduction, puis Yellowstone + HTTP Block Polling en parallèle. Le run doit rester `Healthy`, sans `grpc_backpressure_overflow`, et les Stop ciblés doivent finir `Stopped`. Le diagnostic `pre.012-fix.004` reste actif si un `content_conflict` réapparaît.
 
+### `pre.014` — diagnostic de convergence inter-provider au niveau bloc / `logMessages`
+
+Le gate opérateur de `pre.013` est propre : audits Rust/Markdown, `cargo check --workspace`, Clippy strict, Worker (`161/161` unitaires + suites externes), Desk (`50/50` unitaires + suites externes) et workspace passent. Le live Mainnet confirme également l'objectif de `pre.013` : aucune occurrence de `grpc_backpressure_overflow` ni de `Yellowstone subscribe update queue overflowed` n'est observée dans le run transmis.
+
+Le live reproduit en revanche un unique terminal Yellowstone `content_conflict`. Le diagnostic Store de `pre.012-fix.004` donne exactement :
+
+```text
+slot_mismatch=false
+block_time_mismatch=false
+format_id_mismatch=false
+format_version_mismatch=false
+transaction_mismatch=false
+meta_mismatch=true
+version_mismatch=false
+transaction_index_mismatch=false
+payload_other_mismatch=false
+meta_mismatch_fields="logMessages"
+```
+
+La provenance durable classe les deux acquisitions :
+
+```text
+stored   : solana-public / solana_http / block_polling_get_block / solana_mainnet_public / confirmed
+incoming : ys.publicnode:http.publicnode / yellowstone_http / block_subscribe_get_block /
+           ys.publicnode_solana_mainnet_yellowstone:http.publicnode_solana_mainnet_rpc / confirmed
+```
+
+La transaction canonique elle-même est donc identique ; seule la métadonnée d'exécution `meta.logMessages` diffère. Le diagnostic existant ne permet toutefois pas encore de savoir si les deux RPC décrivent le même bloc `confirmed` ou deux forks/vues de bloc différents au même slot.
+
+`pre.014` ajoute deux niveaux de diagnostic sans changer la politique de conflit :
+
+```text
+Worker / chaque getBlock réussi
+    source_kind
+    network
+    slot
+    provider
+    endpoint_id
+    commitment
+    parent_slot
+    block_height
+    block_identity_fingerprint = SHA-256(domain || blockhash || previousBlockhash || parentSlot || blockHeight)
+
+Store / seulement lors d'un content_conflict
+    stored_slot / incoming_slot
+    logMessages state : missing | null | array | other
+    count de chaque côté
+    premier index divergent
+    type statique de la première ligne divergente :
+        program_invoke | program_success | program_failed | program_log |
+        program_data | compute_units | log_truncated | other | non_string | missing
+    longueur de la première ligne divergente
+    stored_prefix_of_incoming / incoming_prefix_of_stored
+    has_truncation_marker de chaque côté
+```
+
+Le blockhash, le previousBlockhash, les signatures, les payloads et le texte réel de `logMessages` ne sont jamais journalisés. Le fingerprint de bloc est irréversible et sert uniquement à comparer deux acquisitions du même slot.
+
+Interprétation du prochain conflit :
+
+```text
+même slot + fingerprints différents
+    => vues/forks confirmed différents entre providers au moment des getBlock
+
+même slot + même fingerprint + logMessages différents
+    => divergence provider/node sur la représentation ou l'enregistrement des logs du même bloc
+
+incoming_prefix_of_stored=true ou stored_prefix_of_incoming=true
+    => divergence compatible avec une liste tronquée/incomplète
+
+*_has_truncation_marker=true
+    => marqueur explicite de troncature présent dans une des réponses
+```
+
+Non-claims : `pre.014` ne retire pas `logMessages` du contenu canonique, ne choisit aucun provider comme vérité, ne transforme pas `content_conflict` en succès, ne modifie pas le schema Store et n'expose aucun nouveau type public Worker/Store.