0.3.15-pre.014

docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md -->
-<!-- version: 21 -->
+<!-- version: 22 -->
 
 # Plan v0.3.15 — Raw Transaction Ingest Desk
 
@@ -855,11 +855,17 @@ Le mode Yellowstone Block reçoit désormais une partition déterministe des bud
 
 Budget cible : une tranche corrective acquisition/throughput, suivie d'un live Mainnet prolongé.
 
-### `pre.014` — completeness/security cross-layer
+### `pre.014` — convergence inter-provider + completeness/security cross-layer
 
-Fermer les canaris Config/Transport/Worker/Common RAW/Store/Desk, dependency firewalls, API publique, redaction et absence de seconde pipeline ou d'orchestration Backfill.
+**État : implémenté, gate/live opérateur requis.** Le gate de `pre.013` compile et teste proprement le workspace et le live ne reproduit plus `grpc_backpressure_overflow`. Un unique `content_conflict` Mainnet réapparaît toutefois entre HTTP Block Polling (`solana_mainnet_public`) et Yellowstone hydraté par HTTP (`publicnode_solana_mainnet_rpc`), tous deux en `confirmed`. Le diagnostic `pre.012-fix.004` prouve que `slot`, `block_time`, transaction wire, version et `transactionIndex` sont identiques ; seule la valeur `meta.logMessages` diverge.
 
-Budget cible : une tranche de clôture fonctionnelle.
+La tranche ne normalise ni n'ignore `logMessages`. Elle ajoute un diagnostic de convergence sûr permettant de distinguer un fork `confirmed` d'une divergence de représentation/provider : chaque `getBlock` réussi des deux routes journalise le slot et un fingerprint SHA-256 irréversible de l'identité de bloc (`blockhash`, `previousBlockhash`, `parentSlot`, `blockHeight`) sans exposer les blockhash. En cas de conflit RAW, Store journalise désormais les slots exacts et une forme bornée de la divergence `logMessages` : état absent/null/array, cardinalités, premier index divergent, type statique de la première ligne divergente, longueur, relation de préfixe et présence d'un marqueur de troncature. Aucun texte de log distant n'est copié.
+
+Le live doit comparer les fingerprints au slot du conflit. Fingerprints différents au même slot indiquent deux vues de bloc/fork différentes au commitment observé ; fingerprint identique avec `logMessages` divergents indique une divergence de réponse/recording RPC entre providers pour le même bloc. Ce diagnostic précède toute décision de canonicalisation durable.
+
+Les canaris de clôture continuent de vérifier dependency firewalls, API publique, redaction et absence de seconde pipeline ou d'orchestration Backfill.
+
+Budget cible : une tranche de convergence/completeness cross-layer, sans modification de la politique fail-closed.
 
 ### `pre.015` — gate technique/live final
 

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.