ruv
86f38c4fc6
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>
2.4 KiB
Reference platforms for expected_features.sha256
The hash in expected_features.sha256 was generated on a specific BLAS / FFT
backend. Numpy + scipy delegate FFT/linear-algebra to platform-native
libraries, and those libraries produce bit-different output on identical
IEEE 754 inputs depending on the backend. This is not a bug in the proof
pipeline — it is a property of the underlying numerical libraries. (See
issue #560.)
Platforms where the hash is expected to MATCH
| Platform | BLAS backend | Status |
|---|---|---|
linux-x86_64-gnu (Python 3.11.x, numpy 1.26.4 from PyPI wheels, scipy 1.14.1) |
OpenBLAS | ✅ Reference |
windows-x86_64-msvc (Python 3.11.x / 3.13.x, numpy 1.26.4 from PyPI wheels, scipy 1.14.1) |
OpenBLAS | ✅ Reference |
Platforms where the hash is expected to MISMATCH
| Platform | BLAS backend | Why |
|---|---|---|
darwin-arm64 (macOS arm64, Apple Silicon) |
Accelerate.framework | FFT + matrix kernels differ in last-bit positions; the SHA-256 will differ even with pinned numpy 1.26.4 / scipy 1.14.1. |
| Any environment with MKL installed | Intel MKL | Same root cause as Accelerate: different vectorized FFT path. |
What to do if you get MISMATCH on a non-reference platform
The pipeline is still correct on your platform — the output is bit-different because the backend is bit-different, not because the proof code has a bug. Three workable responses:
-
Run the proof on a reference platform (Linux x86_64 or Windows x86_64 with the PyPI OpenBLAS wheels). This is what CI does.
-
Generate a new local-reference hash for your platform and check it against the same hash on a teammate's machine with the same backend:
# Regenerate from your platform python archive/v1/data/proof/verify.py --generate-hash # Commit the new hash to a side file (do NOT overwrite expected_features.sha256 # unless you are publishing a new cross-platform reference) -
Compare numerical output, not the hash. A relaxed-tolerance comparison on the feature vectors (e.g.
np.allclose(features, reference, atol=1e-10)) will pass across backends. This is on the roadmap (see issue #560).
The verify.py runtime environment block
Every run of verify.py now prints a RUNTIME ENVIRONMENT block before the
pipeline runs. Include that block in any issue report — it identifies the
platform + numpy version + BLAS backend in one place.