mirror of
https://github.com/ruvnet/RuView
synced 2026-07-11 15:33:19 +00:00
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>