Three related fixes — a fresh-clone user hitting any of these would
conclude the project doesn't work; #557's "feels like mock" narrative
is fed in part by these breakages.
## #559 — `./verify` pointed at removed `v1/` paths
The wrapper hard-coded `v1/data/proof` / `v1/src`, but the proof scripts
moved to `archive/v1/` long ago. A fresh clone failed before the
pipeline could even run. User `Fewmanism` provided the exact diff in
the issue. Applied verbatim across four hits (PROOF_DIR, V1_SRC, the
Phase 3 scan-message, and the SKIP-state recovery hint).
./verify # now PASS end-to-end
## #561 — firmware README would misflash and point at the wrong provisioner
Two real bring-up bugs:
1. Manual flash command put the app at `0x10000`. The partition tables
(`partitions_display.csv`, `partitions_4mb.csv`) define `ota_0` at
`0x20000`. `0x10000` is the start of `phy_init` data — flashing
the app binary there would corrupt the PHY init data and the app
would never run. The QEMU section already had the right `0x20000`,
so this was an internal contradiction. Both occurrences fixed.
Also added `0xf000 ota_data_initial.bin` to the manual flash
command — the release bundle ships this binary and without it the
bootloader can refuse to boot after a factory wipe.
2. `python scripts/provision.py` referenced the wrong file. There are
actually TWO `provision.py` files in the repo (`scripts/` — 275
lines, stale; `firmware/esp32-csi-node/` — 348 lines, has the
issue #391 full-replace semantics fix). The canonical one is in
the firmware dir. Both README occurrences fixed to point at the
canonical path. (The stale `scripts/provision.py` is a separate
cleanup; the historical ADRs that reference it are intentionally
not touched.)
## #560 — proof hash mismatches on macOS arm64 / Accelerate
User `Fewmanism` reports that with the same pinned `numpy 1.26.4` /
`scipy 1.14.1` on macOS arm64, the proof's SHA-256 differs from the
published expected hash. The proof passes on linux-x86_64 and
windows-x86_64 (where wheels ship OpenBLAS); it mismatches on
darwin-arm64 (where numpy/scipy use Accelerate.framework). That is
not a code bug — Accelerate's FFT and BLAS produce bit-different
output on identical IEEE 754 inputs from the same backend, and the
proof's bit-exact contract therefore cannot hold across backends.
What this commit changes:
- `verify.py` now prints a RUNTIME ENVIRONMENT block before the
pipeline runs: platform, machine, Python version, numpy BLAS
backend. Users on a non-reference backend see the cause up front.
- The FAIL message reorders causes: platform BLAS/FFT backend is
now the *primary* suspect (not "unlikely"), with a pointer to
the printed RUNTIME ENVIRONMENT block.
- New `archive/v1/data/proof/REFERENCE_PLATFORMS.md` documents the
reference platforms (linux-x86_64 + windows-x86_64 with OpenBLAS),
the expected-MISMATCH platforms (darwin-arm64 with Accelerate,
any MKL install), and three workable responses for users hitting
a non-reference backend (run on a reference platform, generate a
local-reference hash, or use tolerance-based comparison — that
last one is the roadmap path).
This converts #560 from "the proof is broken on my Mac" to "the proof
has a documented single-backend contract".
## Verification
- `./verify` (Windows x86_64 / OpenBLAS): VERDICT PASS, hash
`8c0680d7…51c6` matches expected. RUNTIME ENVIRONMENT block prints
numpy BLAS = `scipy-openblas`.
- `grep -E '0x10000|scripts/provision\.py' firmware/esp32-csi-node/README.md`:
no matches.
Co-Authored-By: claude-flow <ruv@ruv.net>
86f38c4fc6