berkus
/
wifi-densepose
mirror of https://github.com/ruvnet/wifi-densepose.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
wifi-densepose/archive
History
ruv 86f38c4fc6 fix: first-run breakage (closes #559, #561) + #560 platform-aware diagnosis 
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>
 		2026-05-14 08:45:33 -04:00
..
v1 fix: first-run breakage (closes #559, #561) + #560 platform-aware diagnosis 2026-05-14 08:45:33 -04:00
README.md chore(repo): move v1/ → archive/v1/ + add archive/README.md (#430) 2026-04-25 23:07:52 -04:00

README.md

Archive

Frozen, no-longer-active components of RuView preserved for historical reference, reproducibility, and load-bearing legacy paths the active codebase still depends on.

What lives here

Path What it is Why it's archived Still load-bearing?
v1/ Original Python implementation of RuView (CSI processing, hardware adapters, services, FastAPI) Superseded by the Rust workspace at v2/; ~810× slower in benchmarks. Kept rather than deleted because the deterministic proof bundle (v1/data/proof/) is part of the pre-merge witness verification process per ADR-011 / ADR-028. Yes — for the proof bundle only. Active code lives in v2/.

What "archived" means

  • Do not add new features here. New work goes in v2/.
  • Do not refactor or modernize the archived code beyond what is strictly necessary to keep the load-bearing paths working. The Python proof bundle is intentionally frozen so that its SHA-256 reproducibility holds across releases (per ADR-028's witness verification requirement).
  • Bug fixes inside archived code are allowed when the bug affects a still-load-bearing path (currently: only the Python proof). All other "bugs" in archived code are out-of-scope — they are part of the historical record and any fix would unnecessarily churn the witness hashes.
  • CI continues to verify the load-bearing paths. .github/workflows/verify-pipeline.yml runs the Python proof on every push and PR; if you change anything inside archive/v1/src/ or archive/v1/data/proof/, expect the determinism check to flag it.

Quick reference for the load-bearing paths

# Run the deterministic Python proof (must print VERDICT: PASS)
python archive/v1/data/proof/verify.py

# Regenerate the expected hash (only if numpy/scipy version legitimately changed)
python archive/v1/data/proof/verify.py --generate-hash

# Run the full Python test suite (legacy, still maintained)
cd archive/v1&& python -m pytest tests/ -x -q

Why we keep v1/ rather than delete it

  1. Trust kill-switch. The proof at v1/data/proof/verify.py feeds a known reference signal through the full pipeline and hashes the output. If the active code's behavior drifts, the hash changes and CI fails. This is what stops accidental regression in the science layer of the codebase.

  2. Witness verification. ADR-028's witness-bundle process bundles the proof, the rust workspace test results, and firmware hashes into a tarball recipients can self-verify. Removing v1 would break that chain.

  3. Historical reference. ADR-011 documents the "no mocks in production code" decision; the original violations and their fixes live in this Python codebase. The ADRs reference these paths.

If the time comes to retire the proof bundle (e.g., a Rust port of the proof exists and the Python version is no longer canonical), the right move is a single follow-up that simultaneously: ports the witness-bundle process, updates verify-pipeline.yml, and either deletes archive/v1/ or moves it to a separate read-only repository. That decision belongs in its own ADR.

See also

  • docs/adr/ADR-011-python-proof-of-reality-mock-elimination.md
  • docs/adr/ADR-028-esp32-capability-audit.md
  • archive/v1/data/proof/README.md (if present)
  • docs/WITNESS-LOG-028.md