I read this as an evidence-only investigation of H3/H4 - I’ll identify the sealed candidate’s test surface, capture serial/concurrent runtime and configuration provenance, compare exact values, clean temporary artifacts, and report to the lead. I'll stop right away when both hypotheses are confirmed or refuted with reproducible evidence and a cleanup list sent via `task_send`.


The failing gate is the Todo11 disposable Telegram E2E: 12 isolated pytest processes all fail at the same post-send invariant, while the fake engine is instance-local. I’m moving from source tracing to process-level provenance capture across the worktree and sealed snapshot, with no repository writes.


The provenance comparison is decisive for the captured failing runs: the serial child and all four concurrent children loaded identical 108-module dictionaries, identical config/identifiers, and unique runtime roots. During comparison, the worktree’s owner fixture changed after those processes exited; I’m isolating that later shared-workspace mutation from the original sealed-candidate evidence rather than conflating it with H4.


The lead’s confirmed expiry root cause matches the provenance evidence: the failing sealed-code runs were resource-isolated and byte-identical; only the later capability-time fix changed loaded code and flipped serial plus four concurrent checks to PASS. I’m cleaning only my `/tmp/nutricoach-v140-debug-resource-*` artifacts and sending the exact H3/H4 disposition now.