I read this as a provenance verification - I’ll independently reproduce both wheels, validate the stated hashes and binding, inspect the hotfix payload, and compare installed module bytes without modifying production.


I found the candidate’s isolated hotfix evidence set and its A/B wheels. I’m now checking the claims directly from canonical JSON, ZIP payloads, source bytes, and fresh installs rather than trusting the recorded evidence.


The stored `repro-a`/`repro-b` wheels are byte-identical and contain source-identical hotfix bytes, but their ZIP timestamp is source-time (`2026-08-22 13:44:06`), not the build helper’s fixed `2000-01-01` epoch. I’m performing clean A/B builds from independent temporary source copies now; this determines whether the stated SHA is genuinely reproducible or only duplicated evidence.


I read this as a provenance verification - I independently checked the candidate, wheels, payload, and installations.

**FAIL**

Exact mismatch:

- Stored `repro-a` and `repro-b`: both `a0930308674fa533b0b74a01219d56894ff81f00fb7acc2f8736d4d3c07a4b78`.
- Fresh A/B builds using the repository’s `reproducible-wheel-build` helper: both `16bccd832c477e0c9ff5373bf63c24cc9a18d354a77da051ec5c8d208577b4a6`.
- Payloads and all 998 member names are identical; every ZIP member timestamp differs:
  - Stored wheels: `2026-08-22 13:44:06`
  - Helper output: `2000-01-01 00:00:00`
- Using inferred `SOURCE_DATE_EPOCH=1787406246` reproduces `a093...`, but that conflicts with the helper’s fixed epoch `946684800`.

Other checks pass:

- Candidate recomputes to `dbb79fe45e2c1dfccfb32aeac5b8911378a65049cbdc4aca0b0917f993e66e5c`.
- Canonical binding recomputes to `c02e4dc8ea9bacc83150747bb6703d53d96d647dac99e9121af57f6ac513205e`.
- Wheel `gateway/platforms/telegram_nutrition_onboarding_runtime.py` contains the tested hotfix and exactly matches source, SHA `d9db56af1b434d04fffce181c5dec03db0c7d0b3ce4691ce9d8edd30f0595227`.
- Fresh A/B installations and recorded A/B installations match source byte-for-byte.
- Both wheel `RECORD` manifests validate.

Production was not touched.


I read this as requesting the final provenance verdict - I’ll state it directly.

**FAIL** — runtime and binding checks pass, but the official reproducible-build helper produces wheel SHA `16bccd...`, not claimed `a093030...`, due to differing ZIP timestamps.


I read this as a final provenance re-review - I’ll verify the corrected canonical artifacts and return only the verdict.


**PASS**