Found 2026-09-03 while verifying the audioif/audiocomponents split; flagged by the usbif session as the pattern worth fixing rather than the instance.
The instance. cmods/bin/micropython was built 2026-09-02 01:16. audioif's afb6b71 (a C change to src/synthio/__init__.c) landed at 01:29 — thirteen minutes later — and every micropython-leg parity run since has certified a binary that does not contain the code the gate is about. The leg was green the whole time. Nothing in the workspace can tell: the binary reports only
3.4.0; MicroPython v1.28.0-dirty on 2026-09-02
— MicroPython's own version and a build date, nothing about which audioif, usbif, displayif or lvgl-bindings commits were compiled in. The same shape bit the usbif bench today (a function compiled out by a bad #if: built, linked, flashed, green, empty) and mpftp (a healthy-looking interop socket that accepted nothing). Presence is not liveness; a green gate on a stale binary is the most expensive kind of stale.
What would close it. Two halves:
build_interpreters.sh / build_mp.sh write a provenance stamp beside each binary — e.g. bin/micropython.buildinfo — recording, per usermod actually linked, the repo and git rev-parse HEAD (plus -dirty when the working tree had changes), the overlay patch set applied, and the build time. AUDIOIF_PATCHES_COMMIT and MICROPYTHON_PYDEVICES_COMMIT at the repo root already carry two of these for the CircuitPython side; the stamp generalises them to every binary and every module.- Gates that render through a binary (
run_instruments_parity.py in audiocomponents, verify_*.py in audioif, capture_render_reference.py in micropython-vst3) read the stamp and refuse to run — not warn — when the audioif commit in it is older than the sources they are certifying (audioif HEAD for audioif's own gates; AUDIOIF_PIN for audiocomponents'). Refusal text names the rebuild command.
Optionally the stamp is also exposed at runtime (sys.implementation._pydevices or a tiny pydevices_build module) so a board or a REPL can answer the same question.
Related: audiocomponents#24 (the finding this came out of), the standing rule that build_mp.sh runs are serialised by cross-session message because the overlay patches are applied into the shared cmods/micropython checkout and reverted — the collision is the tree, not the build directories.
Found 2026-09-03 while verifying the audioif/audiocomponents split; flagged by the usbif session as the pattern worth fixing rather than the instance.
The instance.
cmods/bin/micropythonwas built 2026-09-02 01:16. audioif'safb6b71(a C change tosrc/synthio/__init__.c) landed at 01:29 — thirteen minutes later — and every micropython-leg parity run since has certified a binary that does not contain the code the gate is about. The leg was green the whole time. Nothing in the workspace can tell: the binary reports only— MicroPython's own version and a build date, nothing about which audioif, usbif, displayif or lvgl-bindings commits were compiled in. The same shape bit the usbif bench today (a function compiled out by a bad
#if: built, linked, flashed, green, empty) and mpftp (a healthy-looking interop socket that accepted nothing). Presence is not liveness; a green gate on a stale binary is the most expensive kind of stale.What would close it. Two halves:
build_interpreters.sh/build_mp.shwrite a provenance stamp beside each binary — e.g.bin/micropython.buildinfo— recording, per usermod actually linked, the repo andgit rev-parse HEAD(plus-dirtywhen the working tree had changes), the overlay patch set applied, and the build time.AUDIOIF_PATCHES_COMMITandMICROPYTHON_PYDEVICES_COMMITat the repo root already carry two of these for the CircuitPython side; the stamp generalises them to every binary and every module.run_instruments_parity.pyin audiocomponents,verify_*.pyin audioif,capture_render_reference.pyin micropython-vst3) read the stamp and refuse to run — not warn — when the audioif commit in it is older than the sources they are certifying (audioif HEAD for audioif's own gates;AUDIOIF_PINfor audiocomponents'). Refusal text names the rebuild command.Optionally the stamp is also exposed at runtime (
sys.implementation._pydevicesor a tinypydevices_buildmodule) so a board or a REPL can answer the same question.Related: audiocomponents#24 (the finding this came out of), the standing rule that
build_mp.shruns are serialised by cross-session message because the overlay patches are applied into the sharedcmods/micropythoncheckout and reverted — the collision is the tree, not the build directories.