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 dbcbac1d43 feat(adr-110): Python SyncPacket API parity with Rust (apply_to_local + interpolation) 
Iter 26 — closes the ABI gap between the Python and Rust SyncPacket
decoders. Before this, Python could decode the wire but had no helpers
to apply offsets or recover per-frame mesh time; any Python-side tooling
(host scripts, replay analysers, notebooks) would have to re-implement
the math from scratch and could drift from Rust silently.

New methods on the Python SyncPacket dataclass:

  local_minus_epoch_us() -> int
    Signed local-vs-mesh offset. Matches Rust byte-for-byte.

  apply_to_local(local_at_frame_us: int) -> int
    offset = epoch_us - local_us
    return local_at_frame_us + offset
    Identity at local_at_frame_us == self.local_us returns epoch_us.

  mesh_aligned_us_for_sequence(frame_seq: int, fps_hz: float) -> int
    Sequence-based interpolation matching Rust's identical method.
    Includes u32 wraparound handling via masked-subtract — verified
    against Rust's iter 17 `mesh_aligned_for_sequence_handles_seq_wraparound`.

3 new Python tests (10 total in TestSyncPacketParser, all green in 0.24s):

  test_apply_to_local_recovers_epoch_at_sync_point
    Identity at the sync point. Also verifies local_minus_epoch_us()
    matches §A0.10's measured 1,163,565 µs bench number.

  test_apply_to_local_preserves_inter_frame_delta
    Frame arriving 5 s after the sync on the follower's local clock
    produces mesh time exactly 5 s after sync.epoch_us.

  test_mesh_aligned_us_for_sequence_matches_rust
    Cross-language parity with Rust's
    `end_to_end_sync_decode_then_frame_mesh_recovery` (iter 20):
    100 frames after sync.sequence at 20 fps = sync.epoch_us + 5 s.
    Cross-checks via apply_to_local — both paths must agree.

Test count after iter 26:
  Python TestSyncPacketParser: 10/10 (was 7/7)
  Rust sync_packet::tests: 15/15
  Combined: 25 unit tests defending the SyncPacket contract across
  the two host language stacks.

Co-Authored-By: claude-flow <ruv@ruv.net>
 		2026-05-23 14:15:28 -04:00
..
v1 feat(adr-110): Python SyncPacket API parity with Rust (apply_to_local + interpolation) 2026-05-23 14:15:28 -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