0.3.15-pre.014-fix.001

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: 28 -->
+<!-- version: 29 -->
 
 # Validation v0.3.15 — Raw Transaction Ingest Desk
 
@@ -960,3 +960,29 @@ incoming_prefix_of_stored=true ou stored_prefix_of_incoming=true
 ```
 
 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.
+
+### `pre.014-fix.001` — observation `logMessages` tronquée compatible non terminale
+
+Le live `pre.014` ferme le diagnostic du conflit Mainnet observé au slot `447781296`. HTTP Block Polling et Yellowstone Block Hydration ont produit la même identité de bloc (`parent_slot=447781295`, `block_height=425822496`, même fingerprint), la même transaction, le même index et les mêmes autres métadonnées. La seule divergence est `meta.logMessages`.
+
+Le canonique déjà stocké contient `176` lignes sans marqueur de troncature. L'acquisition entrante contient `118` lignes et un marqueur exact `Log truncated` au premier point divergent. Le diagnostic prouve que toutes les lignes antérieures à ce marqueur sont identiques. Le défaut n'est donc ni un fork ni un changement de transaction : c'est une représentation RPC explicitement tronquée du même résultat d'exécution.
+
+`fix.001` ajoute une compatibilité volontairement asymétrique et étroite dans le backend PostgreSQL :
+
+```text
+canonique déjà complet
++ entrant explicitement tronqué et moins complet au-delà du marqueur
++ mêmes network/signature/slot/block_time/format
++ mêmes transaction/version/transactionIndex
++ mêmes champs meta hors logMessages
++ un seul marqueur exact "Log truncated" côté entrant
++ préfixe avant marqueur identique
++ préfixe exact jusqu’au marqueur ; le matériel après le marqueur n’est pas utilisé pour prouver la complétude
+=> AlreadyPresent + observation persistée
+=> aucun content_conflict
+=> Worker continue
+```
+
+Le canonical RAW n'est jamais remplacé par la version tronquée. Les cas suivants restent des `content_conflict` en `0.3.15` : préfixe différent avant le marqueur, autre champ `meta` différent, marqueur non exact ou multiple, canonique déjà tronqué puis version plus complète entrante. Ce dernier cas nécessite une promotion canonique atomique et appartient explicitement à `0.3.16`, avec variantes durables et historique de résolution ; il n'est pas simulé par un overwrite opportuniste dans ce fix.
+
+Le correctif ne change aucune API publique Store/Worker, aucun schema SQL et aucun outcome public. `RawEntityWriteOutcome::AlreadyPresent` reste l'outcome canonique, l'observation entrante est conservée normalement et le Worker ne reçoit plus d'erreur pour le cas compatible démontré.