docs(adr): update bare wifi-densepose-rs refs to v2/ in ADR-012, ADR-052

Two leftover references missed by the sed pass in #427 (which only
matched the full `rust-port/wifi-densepose-rs` path). These are bare
references to the workspace directory name, which is now v2/.

Co-Authored-By: claude-flow <ruv@ruv.net>

.github/workflows/ci.yml

@@ -79,13 +79,13 @@ jobs:
         path: |
           ~/.cargo/registry
           ~/.cargo/git
-          rust-port/wifi-densepose-rs/target
-        key: ${{ runner.os }}-cargo-${{ hashFiles('rust-port/wifi-densepose-rs/Cargo.lock') }}
+          v2/target
+        key: ${{ runner.os }}-cargo-${{ hashFiles('v2/Cargo.lock') }}
         restore-keys: |
           ${{ runner.os }}-cargo-
 
     - name: Run Rust tests
-      working-directory: rust-port/wifi-densepose-rs
+      working-directory: v2
       run: cargo test --workspace --no-default-features
 
   # Unit and Integration Tests

.github/workflows/desktop-release.yml

@@ -40,18 +40,18 @@ jobs:
           targets: ${{ matrix.target }}
 
       - name: Install frontend dependencies
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui
+        working-directory: v2/crates/wifi-densepose-desktop/ui
         run: npm ci
 
       - name: Build frontend
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui
+        working-directory: v2/crates/wifi-densepose-desktop/ui
         run: npm run build
 
       - name: Install Tauri CLI
         run: cargo install tauri-cli --version "^2.0.0"
 
       - name: Build Tauri app
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop
+        working-directory: v2/crates/wifi-densepose-desktop
         run: cargo tauri build --target ${{ matrix.target }}
         env:
           TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
@@ -68,14 +68,14 @@ jobs:
 
       - name: Package macOS app
         run: |
-          cd rust-port/wifi-densepose-rs/target/${{ matrix.target }}/release/bundle/macos
+          cd v2/target/${{ matrix.target }}/release/bundle/macos
           zip -r "RuView-Desktop-${{ github.event.inputs.version || '0.4.0' }}-macos-${{ steps.arch.outputs.arch }}.zip" "RuView Desktop.app"
 
       - name: Upload macOS artifact
         uses: actions/upload-artifact@v4
         with:
           name: ruview-macos-${{ steps.arch.outputs.arch }}
-          path: rust-port/wifi-densepose-rs/target/${{ matrix.target }}/release/bundle/macos/*.zip
+          path: v2/target/${{ matrix.target }}/release/bundle/macos/*.zip
 
   build-windows:
     name: Build Windows
@@ -93,18 +93,18 @@ jobs:
         uses: dtolnay/rust-toolchain@stable
 
       - name: Install frontend dependencies
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui
+        working-directory: v2/crates/wifi-densepose-desktop/ui
         run: npm ci
 
       - name: Build frontend
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui
+        working-directory: v2/crates/wifi-densepose-desktop/ui
         run: npm run build
 
       - name: Install Tauri CLI
         run: cargo install tauri-cli --version "^2.0.0"
 
       - name: Build Tauri app
-        working-directory: rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop
+        working-directory: v2/crates/wifi-densepose-desktop
         run: cargo tauri build
         env:
           TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
@@ -114,13 +114,13 @@ jobs:
         uses: actions/upload-artifact@v4
         with:
           name: ruview-windows-msi
-          path: rust-port/wifi-densepose-rs/target/release/bundle/msi/*.msi
+          path: v2/target/release/bundle/msi/*.msi
 
       - name: Upload Windows NSIS artifact
         uses: actions/upload-artifact@v4
         with:
           name: ruview-windows-nsis
-          path: rust-port/wifi-densepose-rs/target/release/bundle/nsis/*.exe
+          path: v2/target/release/bundle/nsis/*.exe
 
   create-release:
     name: Create Release

CHANGELOG.md

@@ -7,6 +7,32 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+- **Ghost skeletons in live UI with multi-node ESP32 setups** (#420, ADR-082) —
+  `tracker_bridge::tracker_to_person_detections` documented itself as filtering
+  to `is_alive()` tracks but in fact passed every non-Terminated track to the
+  WebSocket stream. `Lost` tracks — kept inside `reid_window` for
+  re-identification but not currently observed — were rendering as phantom
+  skeletons, accumulating to 22-24 with 3 nodes × 10 Hz CSI while
+  `estimated_persons` correctly reported 1. Added
+  `PoseTracker::confirmed_tracks()` (Tentative + Active only) and rewired the
+  bridge to use it. Lost tracks remain in the tracker for re-ID; they just
+  no longer ship to the UI. Regression test:
+  `test_lost_tracks_excluded_from_bridge_output`.
+- **Rust workspace build with `--no-default-features` on Windows** (#366, #415) —
+  `wifi-densepose-mat`, `wifi-densepose-sensing-server`, and `wifi-densepose-train`
+  all depended on `wifi-densepose-signal` with default features enabled, which
+  pulled `ndarray-linalg` → `openblas-src` → vcpkg/system-BLAS through the entire
+  workspace. `--no-default-features` at the workspace root then could not opt out
+  of BLAS, breaking `cargo build` / `cargo test` on Windows without vcpkg. All
+  three consumers now declare `wifi-densepose-signal = { ..., default-features = false }`,
+  so `cargo test --workspace --no-default-features` builds cleanly without
+  vcpkg/openblas. Validated: 1,538 tests pass, 0 fail, 8 ignored.
+- **`signal` test `test_estimate_occupancy_noise_only` failed without `eigenvalue`** —
+  The test unwrapped the `NotCalibrated` stub returned when the BLAS-backed
+  `estimate_occupancy` is compiled out. Gated with `#[cfg(feature = "eigenvalue")]`
+  so it only runs when the real implementation is available.
+
 ## [v0.6.2-esp32] — 2026-04-20
 
 Firmware release cutting ADR-081 and the Timer Svc stack fix discovered during

CLAUDE.md

@@ -3,7 +3,7 @@
 ## Project: wifi-densepose
 
 WiFi-based human pose estimation using Channel State Information (CSI).
-Dual codebase: Python v1 (`v1/`) and Rust port (`rust-port/wifi-densepose-rs/`).
+Dual codebase: Python v1 (`v1/`) and Rust port (`v2/`).
 ### Key Rust Crates
 | Crate | Description |
 |-------|-------------|
@@ -84,7 +84,7 @@ All 5 ruvector crates integrated in workspace:
 ### Build & Test Commands (this repo)
 ```bash
 # Rust — full workspace tests (1,031+ tests, ~2 min)
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test --workspace --no-default-features
 
 # Rust — single crate check (no GPU needed)
@@ -151,11 +151,11 @@ Crates must be published in dependency order:
 
 ```bash
 # 1. Rust tests — must be 1,031+ passed, 0 failed
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test --workspace --no-default-features
 
 # 2. Python proof — must print VERDICT: PASS
-cd ../..
+cd ..
 python v1/data/proof/verify.py
 
 # 3. Generate witness bundle (includes both above + firmware hashes)
@@ -211,10 +211,10 @@ Active feature branch: `ruvsense-full-implementation` (PR #77)
 - NEVER save to root folder — use the directories below
 - `docs/adr/` — Architecture Decision Records (43 ADRs)
 - `docs/ddd/` — Domain-Driven Design models
-- `rust-port/wifi-densepose-rs/crates/` — Rust workspace crates (15 crates)
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/` — RuvSense multistatic modules (14 files)
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-ruvector/src/viewpoint/` — Cross-viewpoint fusion (5 files)
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/src/esp32/` — ESP32 TDM protocol
+- `v2/crates/` — Rust workspace crates (15 crates)
+- `v2/crates/wifi-densepose-signal/src/ruvsense/` — RuvSense multistatic modules (14 files)
+- `v2/crates/wifi-densepose-ruvector/src/viewpoint/` — Cross-viewpoint fusion (5 files)
+- `v2/crates/wifi-densepose-hardware/src/esp32/` — ESP32 TDM protocol
 - `firmware/esp32-csi-node/main/` — ESP32 C firmware (channel hopping, NVS config, TDM)
 - `v1/src/` — Python source (core, hardware, services, api)
 - `v1/data/proof/` — Deterministic CSI proof bundles

README.md

@@ -110,7 +110,7 @@ RuView now generates **real-time 3D point clouds** by fusing camera depth + WiFi
 
 **Quick start:**
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release -p wifi-densepose-pointcloud
 ./target/release/ruview-pointcloud serve --bind 127.0.0.1:9880
 # Open http://localhost:9880 for live 3D viewer
@@ -381,7 +381,7 @@ See [ADR-069](docs/adr/ADR-069-cognitum-seed-csi-pipeline.md), [ADR-071](docs/ad
 | [Build Guide](docs/build-guide.md) | Building from source (Rust and Python) |
 | [Architecture Decisions](docs/adr/README.md) | 79 ADRs — why each technical choice was made, organized by domain (hardware, signal processing, ML, platform, infrastructure) |
 | [Domain Models](docs/ddd/README.md) | 7 DDD models (RuvSense, Signal Processing, Training Pipeline, Hardware Platform, Sensing Server, WiFi-Mat, CHCI) — bounded contexts, aggregates, domain events, and ubiquitous language |
-| [Desktop App](rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/README.md) | **WIP** — Tauri v2 desktop app for node management, OTA updates, WASM deployment, and mesh visualization |
+| [Desktop App](v2/crates/wifi-densepose-desktop/README.md) | **WIP** — Tauri v2 desktop app for node management, OTA updates, WASM deployment, and mesh visualization |
 | [Medical Examples](examples/medical/README.md) | Contactless blood pressure, heart rate, breathing rate via 60 GHz mmWave radar — $15 hardware, no wearable |
 
 ---
@@ -581,24 +581,24 @@ Small programs that run directly on the ESP32 sensor — no internet needed, no
 | ⚛️ | [**Quantum-Inspired**](docs/edge-modules/autonomous.md) | Uses quantum-inspired math to map room-wide signal coherence and search for optimal sensor configurations |
 | 🤖 | [**Autonomous & Exotic**](docs/edge-modules/autonomous.md) | Self-managing sensor mesh — auto-heals dropped nodes, plans its own actions, and explores experimental signal representations |
 
-All implemented modules are `no_std` Rust, share a [common utility library](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/vendor_common.rs), and talk to the host through a 12-function API. Full documentation: [**Edge Modules Guide**](docs/edge-modules/README.md). See the [complete implemented module list](#edge-module-list) below.
+All implemented modules are `no_std` Rust, share a [common utility library](v2/crates/wifi-densepose-wasm-edge/src/vendor_common.rs), and talk to the host through a 12-function API. Full documentation: [**Edge Modules Guide**](docs/edge-modules/README.md). See the [complete implemented module list](#edge-module-list) below.
 
 <details id="edge-module-list">
 <summary><strong>🧩 Edge Intelligence — <a href="docs/edge-modules/README.md">All 65 Modules Implemented</a></strong> (ADR-041 complete)</summary>
 
-All 60 modules are implemented, tested (609 tests passing), and ready to deploy. They compile to `wasm32-unknown-unknown`, run on ESP32-S3 via WASM3, and share a [common utility library](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/vendor_common.rs). Source: [`crates/wifi-densepose-wasm-edge/src/`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/)
+All 60 modules are implemented, tested (609 tests passing), and ready to deploy. They compile to `wasm32-unknown-unknown`, run on ESP32-S3 via WASM3, and share a [common utility library](v2/crates/wifi-densepose-wasm-edge/src/vendor_common.rs). Source: [`crates/wifi-densepose-wasm-edge/src/`](v2/crates/wifi-densepose-wasm-edge/src/)
 
 **Core modules** (ADR-040 flagship + early implementations):
 
 | Module | File | What It Does |
 |--------|------|-------------|
-| Gesture Classifier | [`gesture.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/gesture.rs) | DTW template matching for hand gestures |
-| Coherence Filter | [`coherence.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/coherence.rs) | Phase coherence gating for signal quality |
-| Adversarial Detector | [`adversarial.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/adversarial.rs) | Detects physically impossible signal patterns |
-| Intrusion Detector | [`intrusion.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/intrusion.rs) | Human vs non-human motion classification |
-| Occupancy Counter | [`occupancy.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/occupancy.rs) | Zone-level person counting |
-| Vital Trend | [`vital_trend.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/vital_trend.rs) | Long-term breathing and heart rate trending |
-| RVF Parser | [`rvf.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/rvf.rs) | RVF container format parsing |
+| Gesture Classifier | [`gesture.rs`](v2/crates/wifi-densepose-wasm-edge/src/gesture.rs) | DTW template matching for hand gestures |
+| Coherence Filter | [`coherence.rs`](v2/crates/wifi-densepose-wasm-edge/src/coherence.rs) | Phase coherence gating for signal quality |
+| Adversarial Detector | [`adversarial.rs`](v2/crates/wifi-densepose-wasm-edge/src/adversarial.rs) | Detects physically impossible signal patterns |
+| Intrusion Detector | [`intrusion.rs`](v2/crates/wifi-densepose-wasm-edge/src/intrusion.rs) | Human vs non-human motion classification |
+| Occupancy Counter | [`occupancy.rs`](v2/crates/wifi-densepose-wasm-edge/src/occupancy.rs) | Zone-level person counting |
+| Vital Trend | [`vital_trend.rs`](v2/crates/wifi-densepose-wasm-edge/src/vital_trend.rs) | Long-term breathing and heart rate trending |
+| RVF Parser | [`rvf.rs`](v2/crates/wifi-densepose-wasm-edge/src/rvf.rs) | RVF container format parsing |
 
 **Vendor-integrated modules** (24 modules, ADR-041 Category 7):
 
@@ -606,128 +606,128 @@ All 60 modules are implemented, tested (609 tests passing), and ready to deploy.
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Flash Attention | [`sig_flash_attention.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_flash_attention.rs) | Tiled attention over 8 subcarrier groups — finds spatial focus regions and entropy | S (<5ms) |
-| Coherence Gate | [`sig_coherence_gate.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_coherence_gate.rs) | Z-score phasor gating with hysteresis: Accept / PredictOnly / Reject / Recalibrate | L (<2ms) |
-| Temporal Compress | [`sig_temporal_compress.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_temporal_compress.rs) | 3-tier adaptive quantization (8-bit hot / 5-bit warm / 3-bit cold) | L (<2ms) |
-| Sparse Recovery | [`sig_sparse_recovery.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_sparse_recovery.rs) | ISTA L1 reconstruction for dropped subcarriers | H (<10ms) |
-| Person Match | [`sig_mincut_person_match.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_mincut_person_match.rs) | Hungarian-lite bipartite assignment for multi-person tracking | S (<5ms) |
-| Optimal Transport | [`sig_optimal_transport.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sig_optimal_transport.rs) | Sliced Wasserstein-1 distance with 4 projections | L (<2ms) |
+| Flash Attention | [`sig_flash_attention.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_flash_attention.rs) | Tiled attention over 8 subcarrier groups — finds spatial focus regions and entropy | S (<5ms) |
+| Coherence Gate | [`sig_coherence_gate.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_coherence_gate.rs) | Z-score phasor gating with hysteresis: Accept / PredictOnly / Reject / Recalibrate | L (<2ms) |
+| Temporal Compress | [`sig_temporal_compress.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_temporal_compress.rs) | 3-tier adaptive quantization (8-bit hot / 5-bit warm / 3-bit cold) | L (<2ms) |
+| Sparse Recovery | [`sig_sparse_recovery.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_sparse_recovery.rs) | ISTA L1 reconstruction for dropped subcarriers | H (<10ms) |
+| Person Match | [`sig_mincut_person_match.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_mincut_person_match.rs) | Hungarian-lite bipartite assignment for multi-person tracking | S (<5ms) |
+| Optimal Transport | [`sig_optimal_transport.rs`](v2/crates/wifi-densepose-wasm-edge/src/sig_optimal_transport.rs) | Sliced Wasserstein-1 distance with 4 projections | L (<2ms) |
 
 **🧠 Adaptive Learning** — On-device learning without cloud connectivity
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| DTW Gesture Learn | [`lrn_dtw_gesture_learn.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/lrn_dtw_gesture_learn.rs) | User-teachable gesture recognition — 3-rehearsal protocol, 16 templates | S (<5ms) |
-| Anomaly Attractor | [`lrn_anomaly_attractor.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/lrn_anomaly_attractor.rs) | 4D dynamical system attractor classification with Lyapunov exponents | H (<10ms) |
-| Meta Adapt | [`lrn_meta_adapt.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/lrn_meta_adapt.rs) | Hill-climbing self-optimization with safety rollback | L (<2ms) |
-| EWC Lifelong | [`lrn_ewc_lifelong.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/lrn_ewc_lifelong.rs) | Elastic Weight Consolidation — remembers past tasks while learning new ones | S (<5ms) |
+| DTW Gesture Learn | [`lrn_dtw_gesture_learn.rs`](v2/crates/wifi-densepose-wasm-edge/src/lrn_dtw_gesture_learn.rs) | User-teachable gesture recognition — 3-rehearsal protocol, 16 templates | S (<5ms) |
+| Anomaly Attractor | [`lrn_anomaly_attractor.rs`](v2/crates/wifi-densepose-wasm-edge/src/lrn_anomaly_attractor.rs) | 4D dynamical system attractor classification with Lyapunov exponents | H (<10ms) |
+| Meta Adapt | [`lrn_meta_adapt.rs`](v2/crates/wifi-densepose-wasm-edge/src/lrn_meta_adapt.rs) | Hill-climbing self-optimization with safety rollback | L (<2ms) |
+| EWC Lifelong | [`lrn_ewc_lifelong.rs`](v2/crates/wifi-densepose-wasm-edge/src/lrn_ewc_lifelong.rs) | Elastic Weight Consolidation — remembers past tasks while learning new ones | S (<5ms) |
 
 **🗺️ Spatial Reasoning** — Location, proximity, and influence mapping
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| PageRank Influence | [`spt_pagerank_influence.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/spt_pagerank_influence.rs) | 4x4 cross-correlation graph with power iteration PageRank | L (<2ms) |
-| Micro HNSW | [`spt_micro_hnsw.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/spt_micro_hnsw.rs) | 64-vector navigable small-world graph for nearest-neighbor search | S (<5ms) |
-| Spiking Tracker | [`spt_spiking_tracker.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/spt_spiking_tracker.rs) | 32 LIF neurons + 4 output zone neurons with STDP learning | S (<5ms) |
+| PageRank Influence | [`spt_pagerank_influence.rs`](v2/crates/wifi-densepose-wasm-edge/src/spt_pagerank_influence.rs) | 4x4 cross-correlation graph with power iteration PageRank | L (<2ms) |
+| Micro HNSW | [`spt_micro_hnsw.rs`](v2/crates/wifi-densepose-wasm-edge/src/spt_micro_hnsw.rs) | 64-vector navigable small-world graph for nearest-neighbor search | S (<5ms) |
+| Spiking Tracker | [`spt_spiking_tracker.rs`](v2/crates/wifi-densepose-wasm-edge/src/spt_spiking_tracker.rs) | 32 LIF neurons + 4 output zone neurons with STDP learning | S (<5ms) |
 
 **⏱️ Temporal Analysis** — Activity patterns, logic verification, autonomous planning
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Pattern Sequence | [`tmp_pattern_sequence.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/tmp_pattern_sequence.rs) | Activity routine detection and deviation alerts | S (<5ms) |
-| Temporal Logic Guard | [`tmp_temporal_logic_guard.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/tmp_temporal_logic_guard.rs) | LTL formula verification on CSI event streams | S (<5ms) |
-| GOAP Autonomy | [`tmp_goap_autonomy.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/tmp_goap_autonomy.rs) | Goal-Oriented Action Planning for autonomous module management | S (<5ms) |
+| Pattern Sequence | [`tmp_pattern_sequence.rs`](v2/crates/wifi-densepose-wasm-edge/src/tmp_pattern_sequence.rs) | Activity routine detection and deviation alerts | S (<5ms) |
+| Temporal Logic Guard | [`tmp_temporal_logic_guard.rs`](v2/crates/wifi-densepose-wasm-edge/src/tmp_temporal_logic_guard.rs) | LTL formula verification on CSI event streams | S (<5ms) |
+| GOAP Autonomy | [`tmp_goap_autonomy.rs`](v2/crates/wifi-densepose-wasm-edge/src/tmp_goap_autonomy.rs) | Goal-Oriented Action Planning for autonomous module management | S (<5ms) |
 
 **🛡️ AI Security** — Tamper detection and behavioral anomaly profiling
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Prompt Shield | [`ais_prompt_shield.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ais_prompt_shield.rs) | FNV-1a replay detection, injection detection (10x amplitude), jamming (SNR) | L (<2ms) |
-| Behavioral Profiler | [`ais_behavioral_profiler.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ais_behavioral_profiler.rs) | 6D behavioral profile with Mahalanobis anomaly scoring | S (<5ms) |
+| Prompt Shield | [`ais_prompt_shield.rs`](v2/crates/wifi-densepose-wasm-edge/src/ais_prompt_shield.rs) | FNV-1a replay detection, injection detection (10x amplitude), jamming (SNR) | L (<2ms) |
+| Behavioral Profiler | [`ais_behavioral_profiler.rs`](v2/crates/wifi-densepose-wasm-edge/src/ais_behavioral_profiler.rs) | 6D behavioral profile with Mahalanobis anomaly scoring | S (<5ms) |
 
 **⚛️ Quantum-Inspired** — Quantum computing metaphors applied to CSI analysis
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Quantum Coherence | [`qnt_quantum_coherence.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/qnt_quantum_coherence.rs) | Bloch sphere mapping, Von Neumann entropy, decoherence detection | S (<5ms) |
-| Interference Search | [`qnt_interference_search.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/qnt_interference_search.rs) | 16 room-state hypotheses with Grover-inspired oracle + diffusion | S (<5ms) |
+| Quantum Coherence | [`qnt_quantum_coherence.rs`](v2/crates/wifi-densepose-wasm-edge/src/qnt_quantum_coherence.rs) | Bloch sphere mapping, Von Neumann entropy, decoherence detection | S (<5ms) |
+| Interference Search | [`qnt_interference_search.rs`](v2/crates/wifi-densepose-wasm-edge/src/qnt_interference_search.rs) | 16 room-state hypotheses with Grover-inspired oracle + diffusion | S (<5ms) |
 
 **🤖 Autonomous Systems** — Self-governing and self-healing behaviors
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Psycho-Symbolic | [`aut_psycho_symbolic.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/aut_psycho_symbolic.rs) | 16-rule forward-chaining knowledge base with contradiction detection | S (<5ms) |
-| Self-Healing Mesh | [`aut_self_healing_mesh.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/aut_self_healing_mesh.rs) | 8-node mesh with health tracking, degradation/recovery, coverage healing | S (<5ms) |
+| Psycho-Symbolic | [`aut_psycho_symbolic.rs`](v2/crates/wifi-densepose-wasm-edge/src/aut_psycho_symbolic.rs) | 16-rule forward-chaining knowledge base with contradiction detection | S (<5ms) |
+| Self-Healing Mesh | [`aut_self_healing_mesh.rs`](v2/crates/wifi-densepose-wasm-edge/src/aut_self_healing_mesh.rs) | 8-node mesh with health tracking, degradation/recovery, coverage healing | S (<5ms) |
 
 **🔮 Exotic (Vendor)** — Novel mathematical models for CSI interpretation
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Time Crystal | [`exo_time_crystal.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_time_crystal.rs) | Autocorrelation subharmonic detection in 256-frame history | S (<5ms) |
-| Hyperbolic Space | [`exo_hyperbolic_space.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_hyperbolic_space.rs) | Poincare ball embedding with 32 reference locations, hyperbolic distance | S (<5ms) |
+| Time Crystal | [`exo_time_crystal.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_time_crystal.rs) | Autocorrelation subharmonic detection in 256-frame history | S (<5ms) |
+| Hyperbolic Space | [`exo_hyperbolic_space.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_hyperbolic_space.rs) | Poincare ball embedding with 32 reference locations, hyperbolic distance | S (<5ms) |
 
 **🏥 Medical & Health** (Category 1) — Contactless health monitoring
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Sleep Apnea | [`med_sleep_apnea.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/med_sleep_apnea.rs) | Detects breathing pauses during sleep | S (<5ms) |
-| Cardiac Arrhythmia | [`med_cardiac_arrhythmia.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/med_cardiac_arrhythmia.rs) | Monitors heart rate for irregular rhythms | S (<5ms) |
-| Respiratory Distress | [`med_respiratory_distress.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/med_respiratory_distress.rs) | Alerts on abnormal breathing patterns | S (<5ms) |
-| Gait Analysis | [`med_gait_analysis.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/med_gait_analysis.rs) | Tracks walking patterns and detects changes | S (<5ms) |
-| Seizure Detection | [`med_seizure_detect.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/med_seizure_detect.rs) | 6-state machine for tonic-clonic seizure recognition | S (<5ms) |
+| Sleep Apnea | [`med_sleep_apnea.rs`](v2/crates/wifi-densepose-wasm-edge/src/med_sleep_apnea.rs) | Detects breathing pauses during sleep | S (<5ms) |
+| Cardiac Arrhythmia | [`med_cardiac_arrhythmia.rs`](v2/crates/wifi-densepose-wasm-edge/src/med_cardiac_arrhythmia.rs) | Monitors heart rate for irregular rhythms | S (<5ms) |
+| Respiratory Distress | [`med_respiratory_distress.rs`](v2/crates/wifi-densepose-wasm-edge/src/med_respiratory_distress.rs) | Alerts on abnormal breathing patterns | S (<5ms) |
+| Gait Analysis | [`med_gait_analysis.rs`](v2/crates/wifi-densepose-wasm-edge/src/med_gait_analysis.rs) | Tracks walking patterns and detects changes | S (<5ms) |
+| Seizure Detection | [`med_seizure_detect.rs`](v2/crates/wifi-densepose-wasm-edge/src/med_seizure_detect.rs) | 6-state machine for tonic-clonic seizure recognition | S (<5ms) |
 
 **🔐 Security & Safety** (Category 2) — Perimeter and threat detection
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Perimeter Breach | [`sec_perimeter_breach.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sec_perimeter_breach.rs) | Detects boundary crossings with approach/departure | S (<5ms) |
-| Weapon Detection | [`sec_weapon_detect.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sec_weapon_detect.rs) | Metal anomaly detection via CSI amplitude shifts | S (<5ms) |
-| Tailgating | [`sec_tailgating.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sec_tailgating.rs) | Detects unauthorized follow-through at access points | S (<5ms) |
-| Loitering | [`sec_loitering.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sec_loitering.rs) | Alerts when someone lingers too long in a zone | S (<5ms) |
-| Panic Motion | [`sec_panic_motion.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/sec_panic_motion.rs) | Detects fleeing, struggling, or panic movement | S (<5ms) |
+| Perimeter Breach | [`sec_perimeter_breach.rs`](v2/crates/wifi-densepose-wasm-edge/src/sec_perimeter_breach.rs) | Detects boundary crossings with approach/departure | S (<5ms) |
+| Weapon Detection | [`sec_weapon_detect.rs`](v2/crates/wifi-densepose-wasm-edge/src/sec_weapon_detect.rs) | Metal anomaly detection via CSI amplitude shifts | S (<5ms) |
+| Tailgating | [`sec_tailgating.rs`](v2/crates/wifi-densepose-wasm-edge/src/sec_tailgating.rs) | Detects unauthorized follow-through at access points | S (<5ms) |
+| Loitering | [`sec_loitering.rs`](v2/crates/wifi-densepose-wasm-edge/src/sec_loitering.rs) | Alerts when someone lingers too long in a zone | S (<5ms) |
+| Panic Motion | [`sec_panic_motion.rs`](v2/crates/wifi-densepose-wasm-edge/src/sec_panic_motion.rs) | Detects fleeing, struggling, or panic movement | S (<5ms) |
 
 **🏢 Smart Building** (Category 3) — Automation and energy efficiency
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| HVAC Presence | [`bld_hvac_presence.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/bld_hvac_presence.rs) | Occupancy-driven HVAC control with departure countdown | S (<5ms) |
-| Lighting Zones | [`bld_lighting_zones.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/bld_lighting_zones.rs) | Auto-dim/off lighting based on zone activity | S (<5ms) |
-| Elevator Count | [`bld_elevator_count.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/bld_elevator_count.rs) | Counts people entering/leaving with overload warning | S (<5ms) |
-| Meeting Room | [`bld_meeting_room.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/bld_meeting_room.rs) | Tracks meeting lifecycle: start, headcount, end, availability | S (<5ms) |
-| Energy Audit | [`bld_energy_audit.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/bld_energy_audit.rs) | Tracks after-hours usage and room utilization rates | S (<5ms) |
+| HVAC Presence | [`bld_hvac_presence.rs`](v2/crates/wifi-densepose-wasm-edge/src/bld_hvac_presence.rs) | Occupancy-driven HVAC control with departure countdown | S (<5ms) |
+| Lighting Zones | [`bld_lighting_zones.rs`](v2/crates/wifi-densepose-wasm-edge/src/bld_lighting_zones.rs) | Auto-dim/off lighting based on zone activity | S (<5ms) |
+| Elevator Count | [`bld_elevator_count.rs`](v2/crates/wifi-densepose-wasm-edge/src/bld_elevator_count.rs) | Counts people entering/leaving with overload warning | S (<5ms) |
+| Meeting Room | [`bld_meeting_room.rs`](v2/crates/wifi-densepose-wasm-edge/src/bld_meeting_room.rs) | Tracks meeting lifecycle: start, headcount, end, availability | S (<5ms) |
+| Energy Audit | [`bld_energy_audit.rs`](v2/crates/wifi-densepose-wasm-edge/src/bld_energy_audit.rs) | Tracks after-hours usage and room utilization rates | S (<5ms) |
 
 **🛒 Retail & Hospitality** (Category 4) — Customer insights without cameras
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Queue Length | [`ret_queue_length.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ret_queue_length.rs) | Estimates queue size and wait times | S (<5ms) |
-| Dwell Heatmap | [`ret_dwell_heatmap.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ret_dwell_heatmap.rs) | Shows where people spend time (hot/cold zones) | S (<5ms) |
-| Customer Flow | [`ret_customer_flow.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ret_customer_flow.rs) | Counts ins/outs and tracks net occupancy | S (<5ms) |
-| Table Turnover | [`ret_table_turnover.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ret_table_turnover.rs) | Restaurant table lifecycle: seated, dining, vacated | S (<5ms) |
-| Shelf Engagement | [`ret_shelf_engagement.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ret_shelf_engagement.rs) | Detects browsing, considering, and reaching for products | S (<5ms) |
+| Queue Length | [`ret_queue_length.rs`](v2/crates/wifi-densepose-wasm-edge/src/ret_queue_length.rs) | Estimates queue size and wait times | S (<5ms) |
+| Dwell Heatmap | [`ret_dwell_heatmap.rs`](v2/crates/wifi-densepose-wasm-edge/src/ret_dwell_heatmap.rs) | Shows where people spend time (hot/cold zones) | S (<5ms) |
+| Customer Flow | [`ret_customer_flow.rs`](v2/crates/wifi-densepose-wasm-edge/src/ret_customer_flow.rs) | Counts ins/outs and tracks net occupancy | S (<5ms) |
+| Table Turnover | [`ret_table_turnover.rs`](v2/crates/wifi-densepose-wasm-edge/src/ret_table_turnover.rs) | Restaurant table lifecycle: seated, dining, vacated | S (<5ms) |
+| Shelf Engagement | [`ret_shelf_engagement.rs`](v2/crates/wifi-densepose-wasm-edge/src/ret_shelf_engagement.rs) | Detects browsing, considering, and reaching for products | S (<5ms) |
 
 **🏭 Industrial & Specialized** (Category 5) — Safety and compliance
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Forklift Proximity | [`ind_forklift_proximity.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ind_forklift_proximity.rs) | Warns when people get too close to vehicles | S (<5ms) |
-| Confined Space | [`ind_confined_space.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ind_confined_space.rs) | OSHA-compliant worker monitoring with extraction alerts | S (<5ms) |
-| Clean Room | [`ind_clean_room.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ind_clean_room.rs) | Occupancy limits and turbulent motion detection | S (<5ms) |
-| Livestock Monitor | [`ind_livestock_monitor.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ind_livestock_monitor.rs) | Animal presence, stillness, and escape alerts | S (<5ms) |
-| Structural Vibration | [`ind_structural_vibration.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/ind_structural_vibration.rs) | Seismic events, mechanical resonance, structural drift | S (<5ms) |
+| Forklift Proximity | [`ind_forklift_proximity.rs`](v2/crates/wifi-densepose-wasm-edge/src/ind_forklift_proximity.rs) | Warns when people get too close to vehicles | S (<5ms) |
+| Confined Space | [`ind_confined_space.rs`](v2/crates/wifi-densepose-wasm-edge/src/ind_confined_space.rs) | OSHA-compliant worker monitoring with extraction alerts | S (<5ms) |
+| Clean Room | [`ind_clean_room.rs`](v2/crates/wifi-densepose-wasm-edge/src/ind_clean_room.rs) | Occupancy limits and turbulent motion detection | S (<5ms) |
+| Livestock Monitor | [`ind_livestock_monitor.rs`](v2/crates/wifi-densepose-wasm-edge/src/ind_livestock_monitor.rs) | Animal presence, stillness, and escape alerts | S (<5ms) |
+| Structural Vibration | [`ind_structural_vibration.rs`](v2/crates/wifi-densepose-wasm-edge/src/ind_structural_vibration.rs) | Seismic events, mechanical resonance, structural drift | S (<5ms) |
 
 **🔮 Exotic & Research** (Category 6) — Experimental sensing applications
 
 | Module | File | What It Does | Budget |
 |--------|------|-------------|--------|
-| Dream Stage | [`exo_dream_stage.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_dream_stage.rs) | Contactless sleep stage classification (wake/light/deep/REM) | S (<5ms) |
-| Emotion Detection | [`exo_emotion_detect.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_emotion_detect.rs) | Arousal, stress, and calm detection from micro-movements | S (<5ms) |
-| Gesture Language | [`exo_gesture_language.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_gesture_language.rs) | Sign language letter recognition via WiFi | S (<5ms) |
-| Music Conductor | [`exo_music_conductor.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_music_conductor.rs) | Tempo and dynamic tracking from conducting gestures | S (<5ms) |
-| Plant Growth | [`exo_plant_growth.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_plant_growth.rs) | Monitors plant growth, circadian rhythms, wilt detection | S (<5ms) |
-| Ghost Hunter | [`exo_ghost_hunter.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_ghost_hunter.rs) | Environmental anomaly classification (draft/insect/wind/unknown) | S (<5ms) |
-| Rain Detection | [`exo_rain_detect.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_rain_detect.rs) | Detects rain onset, intensity, and cessation via signal scatter | S (<5ms) |
-| Breathing Sync | [`exo_breathing_sync.rs`](rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_breathing_sync.rs) | Detects synchronized breathing between multiple people | S (<5ms) |
+| Dream Stage | [`exo_dream_stage.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_dream_stage.rs) | Contactless sleep stage classification (wake/light/deep/REM) | S (<5ms) |
+| Emotion Detection | [`exo_emotion_detect.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_emotion_detect.rs) | Arousal, stress, and calm detection from micro-movements | S (<5ms) |
+| Gesture Language | [`exo_gesture_language.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_gesture_language.rs) | Sign language letter recognition via WiFi | S (<5ms) |
+| Music Conductor | [`exo_music_conductor.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_music_conductor.rs) | Tempo and dynamic tracking from conducting gestures | S (<5ms) |
+| Plant Growth | [`exo_plant_growth.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_plant_growth.rs) | Monitors plant growth, circadian rhythms, wilt detection | S (<5ms) |
+| Ghost Hunter | [`exo_ghost_hunter.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_ghost_hunter.rs) | Environmental anomaly classification (draft/insect/wind/unknown) | S (<5ms) |
+| Rain Detection | [`exo_rain_detect.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_rain_detect.rs) | Detects rain onset, intensity, and cessation via signal scatter | S (<5ms) |
+| Breathing Sync | [`exo_breathing_sync.rs`](v2/crates/wifi-densepose-wasm-edge/src/exo_breathing_sync.rs) | Detects synchronized breathing between multiple people | S (<5ms) |
 
 </details>
 
@@ -855,7 +855,7 @@ git clone https://github.com/ruvnet/RuView.git
 cd RuView
 
 # Rust (primary — 810x faster)
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release
 cargo test --workspace
 
@@ -950,7 +950,7 @@ cargo add wifi-densepose-ruvector   # RuVector v2.0.4 integration layer (ADR-017
 
 All crates integrate with [RuVector v2.0.4](https://github.com/ruvnet/ruvector) — see [AI Backbone](#ai-backbone-ruvector) below.
 
-**[rUv Neural](rust-port/wifi-densepose-rs/crates/ruv-neural/)** — A separate 12-crate workspace for brain network topology analysis, neural decoding, and medical sensing. See [rUv Neural](#ruv-neural) in Models & Training.
+**[rUv Neural](v2/crates/ruv-neural/)** — A separate 12-crate workspace for brain network topology analysis, neural decoding, and medical sensing. See [rUv Neural](#ruv-neural) in Models & Training.
 
 </details>
 
@@ -1050,7 +1050,7 @@ The neural pipeline uses a graph transformer with cross-attention to map CSI fea
 | [RVF Model Container](#rvf-model-container) | Binary packaging with Ed25519 signing, progressive 3-layer loading, SIMD quantization | [ADR-023](docs/adr/ADR-023-trained-densepose-model-ruvector-pipeline.md) |
 | [Training & Fine-Tuning](#training--fine-tuning) | 8-phase pure Rust pipeline (7,832 lines), MM-Fi/Wi-Pose pre-training, 6-term composite loss, SONA LoRA | [ADR-023](docs/adr/ADR-023-trained-densepose-model-ruvector-pipeline.md) |
 | [RuVector Crates](#ruvector-crates) | 11 vendored Rust crates from [ruvector](https://github.com/ruvnet/ruvector): attention, min-cut, solver, GNN, HNSW, temporal compression, sparse inference | [GitHub](https://github.com/ruvnet/ruvector) · [Source](vendor/ruvector/) |
-| [rUv Neural](#ruv-neural) | 12-crate brain topology analysis ecosystem: neural decoding, quantum sensor integration, cognitive state classification, BCI output | [README](rust-port/wifi-densepose-rs/crates/ruv-neural/README.md) |
+| [rUv Neural](#ruv-neural) | 12-crate brain topology analysis ecosystem: neural decoding, quantum sensor integration, cognitive state classification, BCI output | [README](v2/crates/ruv-neural/README.md) |
 | [AI Backbone (RuVector)](#ai-backbone-ruvector) | 5 AI capabilities replacing hand-tuned thresholds: attention, graph min-cut, sparse solvers, tiered compression | [crates.io](https://crates.io/crates/wifi-densepose-ruvector) |
 | [Self-Learning WiFi AI (ADR-024)](#self-learning-wifi-ai-adr-024) | Contrastive self-supervised learning, room fingerprinting, anomaly detection, 55 KB model | [ADR-024](docs/adr/ADR-024-contrastive-csi-embedding-model.md) |
 | [Cross-Environment Generalization (ADR-027)](docs/adr/ADR-027-cross-environment-domain-generalization.md) | Domain-adversarial training, geometry-conditioned inference, hardware normalization, zero-shot deployment | [ADR-027](docs/adr/ADR-027-cross-environment-domain-generalization.md) |
@@ -1168,7 +1168,7 @@ Bundle verify:  7/7 checks PASS
 **Verify it yourself** (no hardware needed):
 ```bash
 # Run all tests
-cd rust-port/wifi-densepose-rs && cargo test --workspace --no-default-features
+cd v2 && cargo test --workspace --no-default-features
 
 # Run the deterministic proof
 python v1/data/proof/verify.py
@@ -1484,7 +1484,7 @@ See [firmware/esp32-csi-node/README.md](firmware/esp32-csi-node/README.md), [ADR
 | WASM Support | No | Yes |
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release
 cargo test --workspace
 cargo bench --package wifi-densepose-signal
@@ -1781,7 +1781,7 @@ The full RuVector ecosystem includes 90+ crates. See [github.com/ruvnet/ruvector
 <details>
 <summary><a id="ruv-neural"></a><strong>🧠 rUv Neural</strong> — Brain topology analysis ecosystem for neural decoding and medical sensing</summary>
 
-[**rUv Neural**](rust-port/wifi-densepose-rs/crates/ruv-neural/README.md) is a 12-crate Rust ecosystem that extends RuView's signal processing into brain network topology analysis. It transforms neural magnetic field measurements from quantum sensors (NV diamond magnetometers, optically pumped magnetometers) into dynamic connectivity graphs, using minimum cut algorithms to detect cognitive state transitions in real time. The ecosystem includes crates for signal processing (`ruv-neural-signal`), graph construction (`ruv-neural-graph`), HNSW-indexed pattern memory (`ruv-neural-memory`), graph embeddings (`ruv-neural-embed`), cognitive state decoding (`ruv-neural-decoder`), and ESP32/WASM edge targets. Medical and research applications include early neurological disease detection via topology signatures, brain-computer interfaces, clinical neurofeedback, and non-invasive biomedical sensing -- bridging RuView's RF sensing architecture with the emerging field of quantum biomedical diagnostics.
+[**rUv Neural**](v2/crates/ruv-neural/README.md) is a 12-crate Rust ecosystem that extends RuView's signal processing into brain network topology analysis. It transforms neural magnetic field measurements from quantum sensors (NV diamond magnetometers, optically pumped magnetometers) into dynamic connectivity graphs, using minimum cut algorithms to detect cognitive state transitions in real time. The ecosystem includes crates for signal processing (`ruv-neural-signal`), graph construction (`ruv-neural-graph`), HNSW-indexed pattern memory (`ruv-neural-memory`), graph embeddings (`ruv-neural-embed`), cognitive state decoding (`ruv-neural-decoder`), and ESP32/WASM edge targets. Medical and research applications include early neurological disease detection via topology signatures, brain-computer interfaces, clinical neurofeedback, and non-invasive biomedical sensing -- bridging RuView's RF sensing architecture with the emerging field of quantum biomedical diagnostics.
 
 </details>
 
@@ -2154,7 +2154,7 @@ wifi-densepose tasks list               # List background tasks
 
 ```bash
 # Rust tests (primary — 542+ tests)
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test --workspace
 
 # Sensing server tests (229 tests)
@@ -2258,7 +2258,7 @@ git clone https://github.com/ruvnet/RuView.git
 cd RuView
 
 # Rust development
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release
 cargo test --workspace
 

docker/Dockerfile.rust

@@ -8,8 +8,8 @@ FROM rust:1.85-bookworm AS builder
 WORKDIR /build
 
 # Copy workspace files
-COPY rust-port/wifi-densepose-rs/Cargo.toml rust-port/wifi-densepose-rs/Cargo.lock ./
-COPY rust-port/wifi-densepose-rs/crates/ ./crates/
+COPY v2/Cargo.toml v2/Cargo.lock ./
+COPY v2/crates/ ./crates/
 
 # Copy vendored RuVector crates
 COPY vendor/ruvector/ /build/vendor/ruvector/

docs/WITNESS-LOG-028.md

@@ -35,7 +35,7 @@ git checkout 96b01008
 ### Step 2: Rust Workspace — Full Test Suite
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test --workspace --no-default-features
 ```
 
@@ -89,7 +89,7 @@ ls firmware/esp32-csi-node/build/*.bin 2>/dev/null || echo "App binary in build/
 ### Step 6: Verify ADR-018 Binary Frame Parser
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test -p wifi-densepose-hardware --no-default-features
 ```
 

docs/adr/ADR-002-ruvector-rvf-integration-strategy.md

@@ -216,4 +216,4 @@ full = ["mincut-matching", "attn-mincut", "temporal-compress", "solver-interpola
 - [Elastic Weight Consolidation](https://arxiv.org/abs/1612.00796)
 - [Raft Consensus](https://raft.github.io/raft.pdf)
 - [ML-DSA (FIPS 204)](https://csrc.nist.gov/pubs/fips/204/final)
-- [WiFi-DensePose Rust ADR-001: Workspace Structure](../rust-port/wifi-densepose-rs/docs/adr/ADR-001-workspace-structure.md)
+- [WiFi-DensePose Rust ADR-001: Workspace Structure](../v2/docs/adr/ADR-001-workspace-structure.md)

docs/adr/ADR-012-esp32-csi-sensor-mesh.md

@@ -166,7 +166,7 @@ typedef struct {
 The aggregator runs on any machine with WiFi/Ethernet to the nodes:
 
 ```rust
-// In wifi-densepose-rs, new module: crates/wifi-densepose-hardware/src/esp32/
+// In v2/, new module: crates/wifi-densepose-hardware/src/esp32/
 pub struct Esp32Aggregator {
     /// UDP socket listening for node streams
     socket: UdpSocket,

docs/adr/ADR-017-ruvector-signal-mat-integration.md

@@ -510,7 +510,7 @@ impl CompressedHeartbeatSpectrogram {
 
 ## Dependency Changes Required
 
-Add to `rust-port/wifi-densepose-rs/Cargo.toml` workspace (already present from ADR-016):
+Add to `v2/Cargo.toml` workspace (already present from ADR-016):
 ```toml
 ruvector-mincut = "2.0.4"          # already present
 ruvector-attn-mincut = "2.0.4"    # already present

docs/adr/ADR-019-sensing-only-ui-mode.md

@@ -11,7 +11,7 @@
 
 The WiFi-DensePose UI was originally built to require the full FastAPI DensePose backend (`localhost:8000`) for all functionality. This backend depends on heavy Python packages (PyTorch ~2GB, torchvision, OpenCV, SQLAlchemy, Redis) making it impractical for lightweight sensing-only deployments where the user simply wants to visualize live WiFi signal data from ESP32 CSI or Windows RSSI collectors.
 
-A Rust port exists (`rust-port/wifi-densepose-rs`) using Axum with lighter runtime footprint (~10MB binary, ~5MB RAM), but it still requires libtorch C++ bindings and OpenBLAS for compilation—a non-trivial build.
+A Rust port exists (`v2`) using Axum with lighter runtime footprint (~10MB binary, ~5MB RAM), but it still requires libtorch C++ bindings and OpenBLAS for compilation—a non-trivial build.
 
 Users need a way to run the UI with **only the sensing pipeline** active, without installing the full DensePose backend stack.
 

docs/adr/ADR-020-rust-ruvector-ai-model-migration.md

@@ -22,7 +22,7 @@ The current Python DensePose backend requires ~2GB+ of dependencies:
 
 This makes the DensePose backend impractical for edge deployments, CI pipelines, and developer laptops where users only need WiFi sensing + pose estimation.
 
-Meanwhile, the Rust port at `rust-port/wifi-densepose-rs/` already has:
+Meanwhile, the Rust port at `v2/` already has:
 
 - **12 workspace crates** covering core, signal, nn, api, db, config, hardware, wasm, cli, mat, train
 - **5 RuVector crates** (v2.0.4, published on crates.io) integrated into signal, mat, and train crates
@@ -143,7 +143,7 @@ The `wifi-densepose-nn::onnx` module loads `.onnx` files directly.
 
 ```bash
 # Build the Rust workspace (ONNX-only, no libtorch)
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo check --workspace 2>&1
 
 # Build release binary

docs/adr/ADR-021-vital-sign-detection-rvdna-pipeline.md

@@ -34,7 +34,7 @@ The `vendor/ruvector` codebase provides a rich set of signal processing primitiv
 
 ### Current Project State
 
-The Rust port (`rust-port/wifi-densepose-rs/`) already contains:
+The Rust port (`v2/`) already contains:
 
 - **`wifi-densepose-signal`**: CSI processing, BVP extraction, phase sanitization, Hampel filter, spectrogram generation, Fresnel geometry, motion detection, subcarrier selection
 - **`wifi-densepose-sensing-server`**: Axum server receiving ESP32 CSI frames (UDP 5005), WebSocket broadcasting sensing updates, signal field generation, with three data source modes:
@@ -108,7 +108,7 @@ ESP32 CSI (UDP:5005) ──▶│  ┌──────────────
 ### Module Structure
 
 ```
-rust-port/wifi-densepose-rs/crates/wifi-densepose-vitals/
+v2/crates/wifi-densepose-vitals/
 ├── Cargo.toml
 └── src/
     ├── lib.rs                 # Public API and re-exports

docs/adr/ADR-022-windows-wifi-enhanced-fidelity-ruvector.md

@@ -592,7 +592,7 @@ impl FrameBuilder {
 ### 3.3 Module Structure
 
 ```
-rust-port/wifi-densepose-rs/crates/wifi-densepose-wifiscan/
+v2/crates/wifi-densepose-wifiscan/
 ├── Cargo.toml
 └── src/
     ├── lib.rs                    # Public API, re-exports

docs/adr/ADR-023-trained-densepose-model-ruvector-pipeline.md

@@ -699,28 +699,28 @@ let dashboard = container.load_dashboard()?;
 
 | File | Purpose |
 |------|---------|
-| `rust-port/.../wifi-densepose-train/src/dataset_mmfi.rs` | MM-Fi dataset loader with subcarrier resampling |
-| `rust-port/.../wifi-densepose-train/src/dataset_wipose.rs` | Wi-Pose dataset loader |
-| `rust-port/.../wifi-densepose-train/src/graph_transformer.rs` | Graph transformer integration |
-| `rust-port/.../wifi-densepose-train/src/body_gnn.rs` | GNN body graph reasoning |
-| `rust-port/.../wifi-densepose-train/src/adaptation.rs` | SONA LoRA + EWC++ adaptation |
-| `rust-port/.../wifi-densepose-train/src/trainer.rs` | Training loop with multi-term loss |
+| `v2/.../wifi-densepose-train/src/dataset_mmfi.rs` | MM-Fi dataset loader with subcarrier resampling |
+| `v2/.../wifi-densepose-train/src/dataset_wipose.rs` | Wi-Pose dataset loader |
+| `v2/.../wifi-densepose-train/src/graph_transformer.rs` | Graph transformer integration |
+| `v2/.../wifi-densepose-train/src/body_gnn.rs` | GNN body graph reasoning |
+| `v2/.../wifi-densepose-train/src/adaptation.rs` | SONA LoRA + EWC++ adaptation |
+| `v2/.../wifi-densepose-train/src/trainer.rs` | Training loop with multi-term loss |
 | `scripts/generate_densepose_labels.py` | Teacher-student UV label generation |
 | `scripts/benchmark_inference.py` | Inference latency benchmarking |
-| `rust-port/.../wifi-densepose-train/src/rvf_builder.rs` | RVF container build pipeline |
-| `rust-port/.../wifi-densepose-train/src/bin/build_rvf.rs` | CLI binary for building `.rvf` containers |
-| `rust-port/.../wifi-densepose-train/src/bin/verify_rvf.rs` | CLI binary for verifying `.rvf` containers |
+| `v2/.../wifi-densepose-train/src/rvf_builder.rs` | RVF container build pipeline |
+| `v2/.../wifi-densepose-train/src/bin/build_rvf.rs` | CLI binary for building `.rvf` containers |
+| `v2/.../wifi-densepose-train/src/bin/verify_rvf.rs` | CLI binary for verifying `.rvf` containers |
 
 ### Modified Files
 
 | File | Change |
 |------|--------|
-| `rust-port/.../wifi-densepose-train/Cargo.toml` | Add ruvector-gnn, graph-transformer, sona, sparse-inference, math, rvf-types, rvf-wire, rvf-manifest, rvf-index, rvf-quant, rvf-crypto, rvf-runtime deps |
-| `rust-port/.../wifi-densepose-train/src/model.rs` | Integrate graph transformer + GNN layers |
-| `rust-port/.../wifi-densepose-train/src/losses.rs` | Add optimal transport + GNN edge consistency loss terms |
-| `rust-port/.../wifi-densepose-train/src/config.rs` | Add training hyperparameters for new components |
-| `rust-port/.../sensing-server/Cargo.toml` | Add rvf-runtime, rvf-types, rvf-index, rvf-quant deps |
-| `rust-port/.../sensing-server/src/main.rs` | Add `--model` flag, load `.rvf` container, progressive startup, serve embedded dashboard |
+| `v2/.../wifi-densepose-train/Cargo.toml` | Add ruvector-gnn, graph-transformer, sona, sparse-inference, math, rvf-types, rvf-wire, rvf-manifest, rvf-index, rvf-quant, rvf-crypto, rvf-runtime deps |
+| `v2/.../wifi-densepose-train/src/model.rs` | Integrate graph transformer + GNN layers |
+| `v2/.../wifi-densepose-train/src/losses.rs` | Add optimal transport + GNN edge consistency loss terms |
+| `v2/.../wifi-densepose-train/src/config.rs` | Add training hyperparameters for new components |
+| `v2/.../sensing-server/Cargo.toml` | Add rvf-runtime, rvf-types, rvf-index, rvf-quant deps |
+| `v2/.../sensing-server/src/main.rs` | Add `--model` flag, load `.rvf` container, progressive startup, serve embedded dashboard |
 
 ## Consequences
 

docs/adr/ADR-024-contrastive-csi-embedding-model.md

@@ -371,7 +371,7 @@ ESP32 SRAM budget: 520 KB. Model at INT8: 53-60 KB = 10-12% of SRAM. Ample margi
 
 ### 2.6 Concrete Module Additions
 
-All new/modified files in `rust-port/wifi-densepose-rs/crates/wifi-densepose-sensing-server/src/`:
+All new/modified files in `v2/crates/wifi-densepose-sensing-server/src/`:
 
 #### 2.6.1 `embedding.rs` (NEW, ~450 lines)
 

docs/adr/ADR-025-macos-corewlan-wifi-sensing.md

@@ -107,7 +107,7 @@ Implement a **macOS CoreWLAN sensing adapter** as a Swift helper binary + Rust a
 
 ### 3.2 Swift Helper Binary
 
-**File:** `rust-port/wifi-densepose-rs/tools/macos-wifi-scan/main.swift`
+**File:** `v2/tools/macos-wifi-scan/main.swift`
 
 ```swift
 // Modes:

docs/adr/ADR-036-rvf-training-pipeline-ui.md

@@ -198,16 +198,16 @@ When a `.rvf` model is loaded:
 ### New Files
 - `ui/components/ModelPanel.js` — Model library, inspector, load/unload controls
 - `ui/components/TrainingPanel.js` — Recording controls, training progress, metric charts
-- `rust-port/.../sensing-server/src/recording.rs` — CSI recording API handlers
-- `rust-port/.../sensing-server/src/training_api.rs` — Training API handlers + WS progress stream
-- `rust-port/.../sensing-server/src/model_manager.rs` — Model loading, hot-swap, 32LoRA activation
+- `v2/.../sensing-server/src/recording.rs` — CSI recording API handlers
+- `v2/.../sensing-server/src/training_api.rs` — Training API handlers + WS progress stream
+- `v2/.../sensing-server/src/model_manager.rs` — Model loading, hot-swap, 32LoRA activation
 - `data/models/` — Default model storage directory
 
 ### Modified Files
-- `rust-port/.../sensing-server/src/main.rs` — Wire recording, training, and model APIs
-- `rust-port/.../train/src/trainer.rs` — Add WebSocket progress callback, LoRA training mode
-- `rust-port/.../train/src/dataset.rs` — MM-Fi and Wi-Pose dataset loaders
-- `rust-port/.../nn/src/onnx.rs` — LoRA weight injection, INT8 quantization support
+- `v2/.../sensing-server/src/main.rs` — Wire recording, training, and model APIs
+- `v2/.../train/src/trainer.rs` — Add WebSocket progress callback, LoRA training mode
+- `v2/.../train/src/dataset.rs` — MM-Fi and Wi-Pose dataset loaders
+- `v2/.../nn/src/onnx.rs` — LoRA weight injection, INT8 quantization support
 - `ui/components/LiveDemoTab.js` — Model selector, LoRA dropdown, A/B spsplit view
 - `ui/components/SettingsPanel.js` — Model and training configuration sections
 - `ui/components/PoseDetectionCanvas.js` — Pose trail rendering, confidence heatmap overlay

docs/adr/ADR-039-esp32-edge-intelligence.md

@@ -128,7 +128,7 @@ All configurable via `provision.py --edge-tier 2 --pres-thresh 0.05 ...`
 - `firmware/esp32-csi-node/main/edge_processing.h` — Types and API
 - `firmware/esp32-csi-node/main/ota_update.c/h` — HTTP OTA endpoint
 - `firmware/esp32-csi-node/main/power_mgmt.c/h` — Power management
-- `rust-port/.../wifi-densepose-sensing-server/src/main.rs` — Vitals parser + REST endpoint
+- `v2/.../wifi-densepose-sensing-server/src/main.rs` — Vitals parser + REST endpoint
 - `scripts/provision.py` — Edge config CLI arguments
 - `.github/workflows/firmware-ci.yml` — CI build + size gate (updated to 950 KB for Tier 3)
 

docs/adr/ADR-040-wasm-programmable-sensing.md

@@ -164,8 +164,8 @@ Core 1 (DSP Task)
 - `firmware/esp32-csi-node/main/wasm_runtime.c/h` — Runtime host with 12 API bindings + manifest
 - `firmware/esp32-csi-node/main/wasm_upload.c/h` — HTTP REST endpoints (RVF-aware)
 - `firmware/esp32-csi-node/main/rvf_parser.c/h` — RVF container parser and verifier
-- `rust-port/.../wifi-densepose-wasm-edge/` — Rust WASM crate (gesture, coherence, adversarial, rvf, occupancy, vital_trend, intrusion)
-- `rust-port/.../wifi-densepose-sensing-server/src/main.rs` — `0xC5110004` parser
+- `v2/.../wifi-densepose-wasm-edge/` — Rust WASM crate (gesture, coherence, adversarial, rvf, occupancy, vital_trend, intrusion)
+- `v2/.../wifi-densepose-sensing-server/src/main.rs` — `0xC5110004` parser
 - `docs/adr/ADR-039-esp32-edge-intelligence.md` — Updated with Tier 3 reference
 
 ---

docs/adr/ADR-043-sensing-server-ui-api-completion.md

@@ -289,7 +289,7 @@ Startup creates `data/models/` and `data/recordings/` directories and populates
 
 ```bash
 # 1. Start sensing server with auto source (simulated fallback)
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo run -p wifi-densepose-sensing-server -- --http-port 3000 --source auto
 
 # 2. Verify model endpoints return 200
@@ -312,11 +312,11 @@ curl -s http://localhost:3000/api/v1/models/lora/profiles | jq '.'
 # Navigate to http://localhost:3000/ui/
 
 # 7. Run mobile tests
-cd ../../ui/mobile
+cd ../ui/mobile
 npx jest --no-coverage
 
 # 8. Run Rust workspace tests (must pass, 1031+ tests)
-cd ../../rust-port/wifi-densepose-rs
+cd ../../v2
 cargo test --workspace --no-default-features
 ```
 

docs/adr/ADR-052-tauri-desktop-frontend.md

@@ -29,7 +29,7 @@ There is no single tool that provides a unified view of the entire deployment
 
 A browser-based UI cannot access serial ports (for flashing), raw UDP sockets (for node discovery), or the local filesystem (for firmware binaries). A desktop application is required for hardware management. Tauri v2 is the natural choice because:
 
-1. **Rust backend** — integrates directly with the existing Rust workspace (`wifi-densepose-rs`). Crates like `wifi-densepose-hardware` (serial port parsing), `wifi-densepose-config`, and `wifi-densepose-sensing-server` can be linked as library dependencies.
+1. **Rust backend** — integrates directly with the existing Rust workspace (`v2/`). Crates like `wifi-densepose-hardware` (serial port parsing), `wifi-densepose-config`, and `wifi-densepose-sensing-server` can be linked as library dependencies.
 2. **Small binary** — Tauri bundles the system webview rather than shipping Chromium (~150 MB savings vs Electron).
 3. **Cross-platform** — Windows, macOS, Linux from the same codebase.
 4. **Security model** — Tauri's capability-based permissions system restricts frontend access to explicitly allowed Rust commands.
@@ -52,7 +52,7 @@ Build a Tauri v2 desktop application as a new crate in the Rust workspace. The f
 Add a new crate to the workspace:
 
 ```
-rust-port/wifi-densepose-rs/
+v2/
   Cargo.toml                          # Add "crates/wifi-densepose-desktop" to members
   crates/
     wifi-densepose-desktop/           # NEW — Tauri app crate
@@ -621,11 +621,11 @@ chrono = { version = "0.4", features = ["serde"] }
 ```bash
 # Prerequisites
 cargo install tauri-cli@^2
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/frontend
+cd v2/crates/wifi-densepose-desktop/frontend
 npm install
 
 # Development (hot-reload frontend + Rust rebuild)
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop
+cd v2/crates/wifi-densepose-desktop
 cargo tauri dev
 
 # Production build
@@ -805,6 +805,6 @@ Total estimated effort: ~11 weeks for a single developer.
 - ADR-051: Sensing Server Decomposition
 - `firmware/esp32-csi-node/` — ESP32 firmware source
 - `firmware/esp32-csi-node/provision.py` — Current provisioning script
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-sensing-server/` — Sensing server
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-hardware/` — Hardware crate
+- `v2/crates/wifi-densepose-sensing-server/` — Sensing server
+- `v2/crates/wifi-densepose-hardware/` — Hardware crate
 - `ui/` — Existing web UI

docs/adr/ADR-058-ruvector-wasm-browser-pose-example.md

@@ -214,7 +214,7 @@ examples/wasm-browser-pose/
 set -e
 
 # Build wifi-densepose-wasm (CSI processing)
-wasm-pack build ../../rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm \
+wasm-pack build ../../v2/crates/wifi-densepose-wasm \
   --target web --out-dir "$(pwd)/pkg/wifi_densepose_wasm" --no-typescript
 
 # Build ruvector-cnn-wasm (CNN inference for both video and CSI)

docs/adr/ADR-075-mincut-person-separation.md

@@ -191,5 +191,5 @@ Also does not give per-person subcarrier assignments.
 
 - Stoer, M. & Wagner, F. (1997). "A Simple Min-Cut Algorithm." JACM 44(4).
 - `vendor/ruvector/crates/ruvector-mincut/src/algorithm/mod.rs` — DynamicMinCut API
-- `rust-port/.../sig_mincut_person_match.rs` — current (broken) WASM edge matcher
+- `v2/.../sig_mincut_person_match.rs` — current (broken) WASM edge matcher
 - `scripts/rf-scan.js` — CSI packet parsing and subcarrier classification

docs/adr/ADR-081-adaptive-csi-mesh-firmware-kernel.md

@@ -481,7 +481,7 @@ make check
 # → test_rv_mesh:             27/27 pass, HEALTH roundtrip = 1.0 µs
 
 # Rust-side radio_ops trait + mesh decoder tests
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test -p wifi-densepose-hardware --no-default-features --lib radio_ops
 # → 8 passed; verifies MockRadio, CRC32 parity with firmware vectors,
 #   HEALTH encode/decode roundtrip, bad-magic/short/CRC rejection,

docs/adr/ADR-082-pose-tracker-confirmed-output-filter.md

@@ -0,0 +1,185 @@
+# ADR-082: Pose Tracker Confirmed-Track Output Filter
+
+| Field       | Value                                                                 |
+|-------------|-----------------------------------------------------------------------|
+| **Status**  | Accepted — implemented in commit landing this ADR                     |
+| **Date**    | 2026-04-25                                                            |
+| **Authors** | ruv                                                                   |
+| **Issue**   | [#420 — "24 ghost people in the UI with 3× ESP32-S3 nodes"](https://github.com/ruvnet/RuView/issues/420) |
+| **Depends** | ADR-026 (track lifecycle), ADR-024 (AETHER re-ID embeddings)          |
+
+## Context
+
+Multiple users running the Rust sensing server with 3 ESP32-S3 nodes have
+reported the same symptom: the live UI renders 22–24 phantom skeletons that
+flicker at high rate, while `GET /api/v1/sensing/latest` correctly reports
+`estimated_persons: 1`. The problem is reproducible across both Docker and
+native deployments and is independent of the firmware MGMT-only mitigation
+shipped for #396.
+
+The two-number contradiction (1 in the snapshot, ~24 in the WebSocket stream)
+narrows the bug to the path that produces `update.persons`. That path is
+`tracker_bridge::tracker_update` → `tracker_bridge::tracker_to_person_detections`
+→ WebSocket frame.
+
+### Pose tracker lifecycle (per ADR-026)
+
+`signal::ruvsense::pose_tracker::TrackLifecycleState` has four states:
+
+```
+Tentative -> Active -> Lost -> Terminated
+```
+
+The state machine and its predicates:
+
+| State        | `is_alive()` | `accepts_updates()` | Meaning |
+|--------------|--------------|---------------------|---------|
+| `Tentative`  | true         | true                | New detection, < 2 confirmed hits |
+| `Active`     | true         | true                | Confirmed track, currently observed |
+| `Lost`       | **true**     | false               | Confirmed track, missed `loss_misses` updates, still inside `reid_window` |
+| `Terminated` | false        | false               | Removed on next `prune_terminated()` |
+
+`PoseTracker::active_tracks()` filters by `is_alive()`, which means it returns
+`Tentative ∪ Active ∪ Lost` — every track that has not yet been Terminated.
+
+### Root cause
+
+`crates/wifi-densepose-sensing-server/src/tracker_bridge.rs` exposes the
+tracker output to the WebSocket stream via:
+
+```rust
+/// Convert active PoseTracker tracks back into server-side PersonDetection values.
+///
+/// Only tracks whose lifecycle `is_alive()` are included.
+pub fn tracker_to_person_detections(tracker: &PoseTracker) -> Vec<PersonDetection> {
+    tracker
+        .active_tracks()
+        .into_iter()
+        .map(|track| { /* ... */ })
+        .collect()
+}
+```
+
+The doc comment is correct as a description of `is_alive()`, but `is_alive()`
+is the wrong gate for *rendering*. `Lost` tracks have not received a
+measurement in `loss_misses` ticks; they are kept around only so the
+re-identification machinery can attempt to match them when a similar
+detection reappears within `reid_window`. They are not currently observed and
+must not appear as live skeletons in the UI.
+
+With 3 ESP32-S3 nodes streaming CSI at ~10 Hz each, `derive_pose_from_sensing`
+emits a per-node detection every tick. Detections that fall outside the
+Mahalanobis gate (cost ≥ 9.0) cannot match an existing track, so a new
+`Tentative` track is created and the previous one ages into `Lost`. With
+`reid_window ≈ 30` ticks (~3 s at 10 Hz), up to 30 ticks × 3 nodes ≈ 90
+phantom Lost tracks can co-exist before any of them reach `Terminated`.
+The actually-observed-now person is one of them; the other ~22–89 are ghosts.
+
+The snapshot endpoint `/api/v1/sensing/latest` reads `estimated_persons` from
+the multistatic eigenvalue counter (`signal::ruvsense::field_model`), which
+operates on the CSI data directly and reports 1. The WebSocket stream reads
+`update.persons`, which is the unfiltered `is_alive()` set — hence the
+22-vs-1 mismatch.
+
+This is a documentation/implementation discrepancy in `tracker_bridge`, not a
+flaw in the lifecycle state machine itself.
+
+## Decision
+
+Introduce a **confirmed-track filter** at the bridge boundary that returns
+only tracks the UI is meant to render:
+
+* `Active` — confirmed and currently observed; always render.
+* `Tentative` — confirmed for the *current* tick (created or matched this
+  cycle); render so first-frame visibility latency stays at one tick.
+* `Lost` — **never** render. They exist only to support re-ID over the
+  `reid_window` and have, by definition, not been observed for at least
+  `loss_misses` ticks.
+* `Terminated` — never render (already excluded by `is_alive()`).
+
+### Naming
+
+Add `PoseTracker::confirmed_tracks()` — the name reflects "tracks the system
+is currently confirming a person is present at this position." Keep
+`active_tracks()` unchanged so callers that legitimately need the re-ID set
+(re-identification, soft-confidence overlays, debug UIs) still have it.
+
+The bridge’s public surface stays the same; only the internal accessor
+swaps. WebSocket consumers see the corrected `update.persons` automatically.
+
+### Why include `Tentative`
+
+A walking person’s first detection lands in `Tentative` until two consecutive
+hits arrive (~0.1 s at 10 Hz). Excluding `Tentative` makes the UI
+under-render by one tick on every entry; the gain (filtering out spurious
+single-detection ghosts) is real but small relative to the much larger Lost
+problem and isn’t worth the visible latency. If single-tick ghosts become
+the dominant complaint after this ADR ships, escalate to `Active`-only and
+revisit `birth_hits` calibration.
+
+## Consequences
+
+### Positive
+
+* `update.persons.length` matches `estimated_persons` within ±1 (Tentative
+  vs. Active hand-off frame) under steady state. #420 closed.
+* No change to the lifecycle state machine, no change to `reid_window` or
+  `loss_misses`, no change to the WebSocket schema. Pure filter at egress.
+* `PoseTracker::active_tracks()` keeps its semantics for re-ID consumers;
+  this avoids breaking ADR-024 (AETHER) call sites.
+
+### Negative / risks
+
+* Existing test `test_tracker_update_stable_ids` exercises three sequential
+  identical-person updates and asserts the ID is stable across all three.
+  Filtering Lost out doesn’t affect it (the track stays in `Tentative` →
+  `Active`, never Lost during the test). Confirmed by reading the test;
+  no regression expected.
+* Single-tick `Tentative` exposure means very-spurious one-frame detections
+  *can* still flicker briefly. Acceptable trade-off as discussed above.
+
+### Neutral
+
+* `prune_terminated()` and the existing transition logic
+  (`predict_all` → `mark_lost` → `terminate`) are unchanged.
+
+## Implementation
+
+1. **`signal::ruvsense::pose_tracker`** — add:
+   ```rust
+   /// Tracks the UI is meant to render: Tentative + Active.
+   /// Excludes Lost (re-ID candidates) and Terminated.
+   pub fn confirmed_tracks(&self) -> Vec<&PoseTrack> {
+       self.tracks
+           .iter()
+           .filter(|t| matches!(
+               t.lifecycle,
+               TrackLifecycleState::Tentative | TrackLifecycleState::Active
+           ))
+           .collect()
+   }
+   ```
+2. **`sensing-server::tracker_bridge`** — change
+   `tracker_to_person_detections` to call `tracker.confirmed_tracks()` and
+   update the doc comment to describe the new contract.
+3. **Regression test** in `tracker_bridge.rs::tests`:
+   * Drive a track to `Active` over two updates.
+   * Submit empty detections for `loss_misses + 1` predict cycles to push
+     the track to `Lost`.
+   * Assert `tracker_update(... empty ...)` returns an empty `Vec`.
+4. **Validation**: workspace tests + ESP32-S3 on COM7 streaming round-trip.
+
+## Validation
+
+* `cargo test --workspace --no-default-features` — must stay green
+  (≥ 1,538 passed, 0 failed; new regression test adds one).
+* Live verification on ESP32 setup: WebSocket `update.persons.length`
+  must equal `estimated_persons` ± 1 in steady state.
+
+## Related
+
+* ADR-026 — Track lifecycle state machine (this ADR doesn’t change it)
+* ADR-024 — AETHER re-ID embeddings (uses `active_tracks()`, unchanged)
+* PR #425 — Workspace `--no-default-features` build fix (unrelated, just
+  the prior PR on this branch line)
+* Issue #420 — original report

docs/build-guide.md

@@ -191,7 +191,7 @@ A high-performance Rust port with ~810x speedup over the Python pipeline for the
 ### Build
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release
 ```
 
@@ -200,7 +200,7 @@ Release profile is configured with LTO, single codegen unit, and `-O3` for maxim
 ### Test
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo test --workspace
 ```
 
@@ -209,7 +209,7 @@ Runs 107 tests across all workspace crates.
 ### Benchmark
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo bench --package wifi-densepose-signal
 ```
 
@@ -468,7 +468,7 @@ The aggregator collects UDP streams from all ESP32 nodes, performs feature-level
 docker compose -f docker-compose.esp32.yml up
 
 # Or run the Rust aggregator directly
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo run --release --package wifi-densepose-hardware -- --mode esp32-aggregator --port 5000
 ```
 
@@ -516,7 +516,7 @@ rustup target add wasm32-unknown-unknown
 Build:
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 
 # Build WASM package (outputs to pkg/)
 wasm-pack build crates/wifi-densepose-wasm --target web --release
@@ -601,7 +601,7 @@ uvicorn v1.src.api.main:app \
   --workers 4
 
 # Or run the Rust API server
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo run --release --package wifi-densepose-api
 ```
 
@@ -631,7 +631,7 @@ pytest --cov=wifi_densepose --cov-report=html
 Rust:
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 
 # Build in debug mode (faster compilation)
 cargo build
@@ -674,7 +674,7 @@ python3 -m http.server 3000 --directory ui
 | `v1/data/proof/expected_features.sha256` | Published expected hash |
 | `v1/src/api/main.py` | FastAPI application entry point |
 | `v1/src/sensing/` | Commodity WiFi sensing module (RSSI) |
-| `rust-port/wifi-densepose-rs/Cargo.toml` | Rust workspace root |
+| `v2/Cargo.toml` | Rust workspace root |
 | `ui/viz.html` | Three.js 3D visualization |
 | `Dockerfile` | Multi-stage Docker build (dev/prod/test/security) |
 | `docker-compose.yml` | Development stack (Postgres, Redis, Prometheus, Grafana) |

docs/ddd/hardware-platform-domain-model.md

@@ -14,7 +14,7 @@ This document defines the system using [Domain-Driven Design](https://martinfowl
 | 4 | [Aggregation](#4-aggregation-context) | Server-side CSI frame reception, timestamp alignment, multi-node feature fusion | [ADR-012](../adr/ADR-012-esp32-csi-sensor-mesh.md) | `crates/wifi-densepose-hardware/src/esp32/` |
 | 5 | [Provisioning](#5-provisioning-context) | NVS configuration, firmware lifecycle, fleet management, deployment presets | [ADR-044](../adr/ADR-044-provisioning-tool-enhancements.md) | `firmware/esp32-csi-node/provision.py` |
 
-All firmware paths are relative to the repository root. Rust crate paths are relative to `rust-port/wifi-densepose-rs/`.
+All firmware paths are relative to the repository root. Rust crate paths are relative to `v2/`.
 
 ---
 

docs/ddd/ruvsense-domain-model.md

@@ -16,7 +16,7 @@ This document defines the system using [Domain-Driven Design](https://martinfowl
 | 6 | [Spatial Identity](#6-spatial-identity-context) | Cross-room tracking via environment fingerprints | [ADR-030](../adr/ADR-030-ruvsense-persistent-field-model.md) | `signal/src/ruvsense/cross_room.rs` |
 | 7 | [Edge Intelligence](#7-edge-intelligence-context) | On-device sensing (no server needed) | [ADR-039](../adr/ADR-039-esp32-edge-intelligence.md), [ADR-040](../adr/ADR-040-wasm-programmable-sensing.md) | `firmware/esp32-csi-node/main/edge_processing.c` |
 
-All code paths shown are relative to `rust-port/wifi-densepose-rs/crates/wifi-densepose-` unless otherwise noted.
+All code paths shown are relative to `v2/crates/wifi-densepose-` unless otherwise noted.
 
 ---
 

docs/ddd/sensing-server-domain-model.md

@@ -14,7 +14,7 @@ This document defines the system using [Domain-Driven Design](https://martinfowl
 | 4 | [Training Pipeline](#4-training-pipeline-context) | Background training runs, progress streaming, contrastive pretraining | [ADR-043](../adr/ADR-043-sensing-server-ui-api-completion.md) | `sensing-server/src/training_api.rs` |
 | 5 | [Visualization](#5-visualization-context) | WebSocket streaming to web UI, Gaussian splat rendering, data transparency | [ADR-019](../adr/ADR-019-sensing-only-ui-mode.md), [ADR-035](../adr/ADR-035-live-sensing-ui-accuracy.md) | `ui/` |
 
-All code paths shown are relative to `rust-port/wifi-densepose-rs/crates/wifi-densepose-` unless otherwise noted.
+All code paths shown are relative to `v2/crates/wifi-densepose-` unless otherwise noted.
 
 ---
 

docs/ddd/training-pipeline-domain-model.md

@@ -13,7 +13,7 @@ This document defines the system using [Domain-Driven Design](https://martinfowl
 | 3 | [Training Orchestration](#3-training-orchestration-context) | Run the training loop, compute composite loss, checkpoint, and verify deterministic proofs | [ADR-015](../adr/ADR-015-public-dataset-training-strategy.md), [ADR-016](../adr/ADR-016-ruvector-integration.md) | `train/src/trainer.rs`, `train/src/losses.rs`, `train/src/metrics.rs`, `train/src/proof.rs` |
 | 4 | [Embedding & Transfer](#4-embedding--transfer-context) | Produce AETHER contrastive embeddings, MERIDIAN domain-generalized features, and LoRA adapters | [ADR-024](../adr/ADR-024-contrastive-csi-embedding-model.md), [ADR-027](../adr/ADR-027-cross-environment-domain-generalization.md) | `train/src/embedding.rs`, `train/src/domain.rs`, `train/src/sona.rs` |
 
-All code paths shown are relative to `rust-port/wifi-densepose-rs/crates/wifi-densepose-` unless otherwise noted.
+All code paths shown are relative to `v2/crates/wifi-densepose-` unless otherwise noted.
 
 ---
 

docs/edge-modules/README.md

@@ -6,7 +6,7 @@
 
 ```bash
 # Build all modules for ESP32
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge
+cd v2/crates/wifi-densepose-wasm-edge
 cargo build --target wasm32-unknown-unknown --release
 
 # Run all 632 tests
@@ -144,4 +144,4 @@ Every module talks to the ESP32 through 12 functions:
 - [ADR-039](../adr/ADR-039-esp32-edge-intelligence.md) — Edge processing tiers
 - [ADR-040](../adr/ADR-040-wasm-programmable-sensing.md) — WASM runtime design
 - [ADR-041](../adr/ADR-041-wasm-module-collection.md) — Full module specification
-- [Source code](../../rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/)
+- [Source code](../../v2/crates/wifi-densepose-wasm-edge/src/)

docs/edge-modules/core.md

@@ -481,7 +481,7 @@ std::fs::write("my-gesture-v2.rvf", &rvf_mut)?;
 From the crate directory:
 
 ```bash
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge
+cd v2/crates/wifi-densepose-wasm-edge
 cargo test --features std -- gesture coherence adversarial intrusion occupancy vital_trend rvf
 ```
 

docs/edge-modules/medical.md

@@ -618,7 +618,7 @@ for _ in 0..100 {
 All medical modules include comprehensive unit tests covering initialization, normal operation, clinical scenario detection, edge cases, and cooldown behavior.
 
 ```bash
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge
+cd v2/crates/wifi-densepose-wasm-edge
 cargo test --features std -- med_
 ```
 

docs/edge-modules/security.md

@@ -556,7 +556,7 @@ for &(event_id, value) in events {
 
 ```bash
 # Run all security module tests (requires std feature)
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge
+cd v2/crates/wifi-densepose-wasm-edge
 cargo test --features std -- sec_ intrusion
 ```
 

docs/qe-reports/02-security-review.md

@@ -413,9 +413,9 @@ The `create_user()` method accepts any password without minimum length, complexi
 ### INFORMATIONAL-001: Rust API, DB, and Config Crates Are Stubs
 
 **Files:**
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-api/src/lib.rs` -- `//! WiFi-DensePose REST API (stub)`
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-db/src/lib.rs` -- `//! WiFi-DensePose database layer (stub)`
-- `rust-port/wifi-densepose-rs/crates/wifi-densepose-config/src/lib.rs` -- `//! WiFi-DensePose configuration (stub)`
+- `v2/crates/wifi-densepose-api/src/lib.rs` -- `//! WiFi-DensePose REST API (stub)`
+- `v2/crates/wifi-densepose-db/src/lib.rs` -- `//! WiFi-DensePose database layer (stub)`
+- `v2/crates/wifi-densepose-config/src/lib.rs` -- `//! WiFi-DensePose configuration (stub)`
 
 **Description:**
 The Rust API, database, and configuration crates contain only single-line stub comments. No security review of Rust API endpoints, database queries, or configuration handling was possible because no implementation exists. The `wifi-densepose-sensing-server` crate contains the actual Rust server implementation.
@@ -426,7 +426,7 @@ The Rust API, database, and configuration crates contain only single-line stub c
 
 ### INFORMATIONAL-002: Rust `unsafe` Blocks in WASM Edge Crate
 
-**Files:** `rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/*.rs` (multiple files)
+**Files:** `v2/crates/wifi-densepose-wasm-edge/src/*.rs` (multiple files)
 
 **Description:**
 The `wifi-densepose-wasm-edge` crate contains approximately 40 `unsafe` blocks, primarily for:
@@ -518,7 +518,7 @@ The following areas demonstrate security-conscious design:
 - `v1/src/tasks/backup.py` (partial) -- Subprocess command construction
 - `v1/test_auth_rate_limit.py` (partial) -- Test credentials review
 
-### Rust (rust-port/wifi-densepose-rs/)
+### Rust (v2/)
 - `crates/wifi-densepose-api/src/lib.rs` (1 line -- stub)
 - `crates/wifi-densepose-db/src/lib.rs` (1 line -- stub)
 - `crates/wifi-densepose-config/src/lib.rs` (1 line -- stub)

docs/qe-reports/03-performance-analysis.md

@@ -40,7 +40,7 @@ The WiFi-DensePose codebase is a real-time sensing system targeting 20 Hz output
 
 ### FINDING PERF-R01: Tomography Weight Matrix -- O(L * nx * ny * nz) per Link [CRITICAL]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`  
 **Lines**: 345-383 (`compute_link_weights`)
 
 The `compute_link_weights` function iterates over every voxel in the grid for every link to compute Fresnel-zone intersection weights:
@@ -76,7 +76,7 @@ for iz in 0..config.nz {
 
 ### FINDING PERF-R02: Multistatic Fusion -- sin()/cos() per Subcarrier per Node [HIGH]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`  
 **Lines**: 287-298 (`attention_weighted_fusion`)
 
 ```rust
@@ -105,7 +105,7 @@ for (n, (&amp, &ph)) in amplitudes.iter().zip(phases.iter()).enumerate() {
 
 ### FINDING PERF-R03: Pose Tracker find_track -- Linear Search [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`  
 **Lines**: 546-553
 
 ```rust
@@ -124,7 +124,7 @@ pub fn find_track(&self, id: TrackId) -> Option<&PoseTrack> {
 
 ### FINDING PERF-R04: Multistatic FusedSensingFrame -- Deep Clone of node_frames [HIGH]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`  
 **Line**: 222
 
 ```rust
@@ -150,7 +150,7 @@ Ok(FusedSensingFrame {
 
 ### FINDING PERF-R05: Coherence Score -- Efficient but exp() in Hot Loop [LOW]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`  
 **Lines**: 224-252 (`coherence_score`)
 
 ```rust
@@ -174,7 +174,7 @@ for i in 0..n {
 
 ### FINDING PERF-R06: Gesture DTW -- O(N * M) per Template [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`  
 **Lines**: 288-328 (`dtw_distance`)
 
 The DTW implementation uses the Sakoe-Chiba band constraint (good), but allocates two full Vec<f64> per call:
@@ -199,7 +199,7 @@ With T templates and band_width=5, complexity is O(T * N * band_width * feature_
 
 ### FINDING PERF-R07: Field Model Covariance -- O(S^2) Memory [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`  
 **Line**: 330 (`covariance_sum: Option<Array2<f64>>`)
 
 The full covariance matrix for SVD is S x S where S = number of subcarriers. With S=56, this is 56 * 56 * 8 = 25 KB -- reasonable. But the diagonal_fallback (lines 338-383) creates unnecessary intermediate allocations.
@@ -212,7 +212,7 @@ The full covariance matrix for SVD is S x S where S = number of subcarriers. Wit
 
 ### FINDING PERF-R08: Multiband Duplicate Frequency Check -- O(N^2) [LOW]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`  
 **Lines**: 126-135
 
 ```rust
@@ -235,7 +235,7 @@ for i in 0..self.frequencies.len() {
 
 ### FINDING PERF-R09: Adversarial Detector -- Potential O(L^2) Consistency Check [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`  
 **Lines**: 147+
 
 The multi-link consistency check compares energy ratios across all links. With L=12 links, the pairwise comparison (if implemented) would be O(L^2) = 144. Combined with the four independent checks (consistency, field model, temporal, energy), this runs on every frame.
@@ -259,7 +259,7 @@ The multi-link consistency check compares energy ratios across all links. With L
 
 ### FINDING PERF-NN01: Serial Batch Inference [CRITICAL]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`  
+**File**: `v2/crates/wifi-densepose-nn/src/inference.rs`  
 **Lines**: 334-336
 
 ```rust
@@ -283,7 +283,7 @@ pub fn infer_batch(&self, inputs: &[Tensor]) -> NnResult<Vec<Tensor>> {
 
 ### FINDING PERF-NN02: Async Stats Update Spawns Tokio Task per Inference [HIGH]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`  
+**File**: `v2/crates/wifi-densepose-nn/src/inference.rs`  
 **Lines**: 311-315
 
 ```rust
@@ -307,7 +307,7 @@ tokio::spawn(async move {
 
 ### FINDING PERF-NN03: Tensor Clone in run_single [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`  
+**File**: `v2/crates/wifi-densepose-nn/src/inference.rs`  
 **Lines**: 122
 
 ```rust
@@ -326,7 +326,7 @@ fn run_single(&self, input: &Tensor) -> NnResult<Tensor> {
 
 ### FINDING PERF-NN04: WiFiDensePosePipeline -- Two Sequential Inferences [MEDIUM]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`  
+**File**: `v2/crates/wifi-densepose-nn/src/inference.rs`  
 **Lines**: 389-413
 
 ```rust
@@ -634,7 +634,7 @@ uint32_t next = (s_ring.head + 1) & (EDGE_RING_SLOTS - 1);
 
 ### FINDING PERF-XC01: Missing Parallelism in Multistatic Pipeline [HIGH]
 
-**File**: `rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/mod.rs`  
+**File**: `v2/crates/wifi-densepose-signal/src/ruvsense/mod.rs`  
 **Lines**: 183-232
 
 The `RuvSensePipeline` orchestrator processes stages sequentially. The multiband fusion and phase alignment stages for each node are independent and could run in parallel using Rayon:
@@ -756,26 +756,26 @@ The following patterns were checked and found to be well-implemented:
 ## Appendix A: File Paths Analyzed
 
 ### Rust Signal Processing
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/mod.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/coherence_gate.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/phase_align.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/intention.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/longitudinal.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/cross_room.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/temporal_gesture.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/attractor_drift.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/mod.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/tomography.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/multistatic.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/pose_tracker.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/field_model.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/gesture.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/coherence.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/coherence_gate.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/multiband.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/phase_align.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/adversarial.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/intention.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/longitudinal.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/cross_room.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/temporal_gesture.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-signal/src/ruvsense/attractor_drift.rs`
 
 ### Rust Neural Network
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/inference.rs`
-- `/workspaces/ruview/rust-port/wifi-densepose-rs/crates/wifi-densepose-nn/src/tensor.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-nn/src/inference.rs`
+- `/workspaces/ruview/v2/crates/wifi-densepose-nn/src/tensor.rs`
 
 ### Python Pipeline
 - `/workspaces/ruview/v1/src/core/csi_processor.py`

docs/qe-reports/04-test-analysis.md

@@ -3,7 +3,7 @@
 **Project:** wifi-densepose (ruview)
 **Date:** 2026-04-05
 **Analyst:** QE Test Architect (V3)
-**Scope:** All test suites across Python (v1), Rust (rust-port), and Mobile (ui/mobile)
+**Scope:** All test suites across Python (v1), Rust (v2), and Mobile (ui/mobile)
 
 ---
 
@@ -470,8 +470,8 @@ This is the best-tested service in the mobile suite.
 |------|---------------|
 | `v1/tests/unit/test_sensing.py` | 45 tests with mathematical rigor, known-signal validation, domain-specific edge cases, cross-receiver agreement, band isolation. No mocks for core logic. |
 | `v1/tests/unit/test_esp32_binary_parser.py` | Real UDP socket testing, struct-level binary validation, ADR-018 compliance. Tests actual I/Q to amplitude/phase math. |
-| `rust-port/.../tests/validation_test.rs` | Physics-based validation (Doppler, phase unwrapping, spectral analysis). Tests prove algorithm correctness, not just non-failure. |
-| `rust-port/.../tests/test_losses.rs` | Deterministic data, feature-gated, tests mathematical properties (zero loss for identical inputs, non-zero for mismatched). |
+| `v2/.../tests/validation_test.rs` | Physics-based validation (Doppler, phase unwrapping, spectral analysis). Tests prove algorithm correctness, not just non-failure. |
+| `v2/.../tests/test_losses.rs` | Deterministic data, feature-gated, tests mathematical properties (zero loss for identical inputs, non-zero for mismatched). |
 | `ui/mobile/.../utils/ringBuffer.test.ts` | Comprehensive boundary testing (NaN, Infinity, 0, negative, overflow). Tests copy semantics. |
 
 ### 5.2 Worst Test Files (Needs Improvement)

docs/research/architecture/decision-tree.md

@@ -0,0 +1,205 @@
+# Three-Tier Node — Decision Tree
+
+| Field        | Value                                                                  |
+|--------------|------------------------------------------------------------------------|
+| **Status**   | Reference — informs whether/how to adopt the three-tier proposal       |
+| **Date**     | 2026-04-25                                                             |
+| **Companion**| `architecture/three-tier-rust-node.md`, `sota/2026-Q2-rf-sensing-and-edge-rust.md` |
+
+This document maps each load-bearing decision in the three-tier proposal
+to (a) what it depends on, (b) what evidence would justify yes/no, and
+(c) which ADR slot would house the decision once made. It is intentionally
+short — the prose lives in the SOTA survey and the seed exploration.
+
+---
+
+## 1. Load-bearing vs independent decisions
+
+Six decisions are **load-bearing** — they unblock or block other
+decisions:
+
+| #  | Decision                         | Blocks                                   |
+|----|----------------------------------|------------------------------------------|
+| L1 | Per-node BOM ceiling             | Hardware split, Pi shape, all ADRs below |
+| L2 | Single-MCU vs dual-MCU node      | Sensor-MCU runtime, ISR strategy         |
+| L3 | One-Pi-per-node vs one-per-cluster | OTA shape, secure-boot story, BOM       |
+| L4 | CSI no_std maturity gate         | Sensor-MCU language choice               |
+| L5 | Mesh control-plane technology    | Comms MCU choice (S3 vs C6)              |
+| L6 | Heavy-compute SoC choice         | Secure-boot path, ML model class         |
+
+Five decisions are **independent** of the three-tier shape and can be
+made in parallel:
+
+| #  | Decision                         |
+|----|----------------------------------|
+| I1 | LoRa fallback chip (SX1262 vs LR1121) |
+| I2 | Charger / PMIC (BQ24074 vs BQ25798)   |
+| I3 | QUIC vs MQTT-over-TLS for backhaul    |
+| I4 | OTA mechanism per die                 |
+| I5 | Provisioning protocol (BLE vs USB)    |
+
+---
+
+## 2. Decision tree (Mermaid)
+
+```mermaid
+flowchart TD
+    L1{"L1: BOM ceiling per node?"}
+    L1 -->|"<= $15"| KEEP_TODAY["Keep ADR-028 single-S3 node.<br/>Three-tier proposal is out of budget."]
+    L1 -->|"$15-$30"| L3
+    L1 -->|"> $30"| L3
+
+    L3{"L3: Heavy compute per node<br/>or per cluster?"}
+    L3 -->|"per cluster (1 Pi / 3-6 nodes)"| HYBRID["Hybrid path:<br/>single-S3 sensor + cluster Pi.<br/>Cheapest viable upgrade."]
+    L3 -->|"per node"| L2
+
+    L2{"L2: Single-MCU or dual-MCU<br/>per node?"}
+    L2 -->|"single MCU"| L4_SINGLE["ADR-081 already covers this.<br/>Investigate WHY a dual-MCU is needed."]
+    L2 -->|"dual MCU (sensor + comms)"| L4
+
+    L4{"L4: Is no_std CSI capture<br/>production-quality?"}
+    L4 -->|"no / unknown"| L4_NO["Hold dual-MCU shape until<br/>esp-csi-rs / esp-radio matches<br/>esp_wifi_set_csi_rx_cb in jitter & quality."]
+    L4 -->|"yes (benchmarked)"| L5
+
+    L5{"L5: Mesh control plane:<br/>WiFi or 802.15.4?"}
+    L5 -->|"WiFi (ESP-WIFI-MESH)"| L5_WIFI["Comms MCU = ESP32-S3.<br/>Stays on existing ADR-029 shape."]
+    L5 -->|"802.15.4 (Thread)"| L5_THREAD["Comms MCU = ESP32-C6.<br/>Hybrid: WiFi data + Thread control."]
+
+    L6{"L6: Heavy compute SoC?"}
+    L6 -->|"Pi Zero 2W"| L6_ZERO["dm-verity + signed FIT.<br/>NOT immutable-ROM secure boot."]
+    L6 -->|"CM4 / Pi 5"| L6_CM4["RPi-foundation secure boot path.<br/>+~$30-50 BOM."]
+
+    HYBRID --> L6
+    L5_WIFI --> L6
+    L5_THREAD --> L6
+
+    L4_NO -.->|"if gated long-term"| HYBRID
+
+    style KEEP_TODAY fill:#cfe
+    style HYBRID fill:#cfe
+    style L4_NO fill:#fec
+    style L4_SINGLE fill:#cfe
+```
+
+The tree's recommended cheapest-first path is:
+**L1 → L3 (per-cluster) → HYBRID**, which keeps today's ESP32-S3 sensor
+nodes and adds one Pi per 3–6 nodes. This captures most of the QUIC /
+ML / secure-boot value without re-spinning the per-node PCB.
+
+---
+
+## 3. Decision detail — what evidence justifies each branch
+
+### L1 — Per-node BOM ceiling
+
+| Branch                | Evidence required                                                  | ADR slot                             |
+|-----------------------|--------------------------------------------------------------------|--------------------------------------|
+| ≤ $15                 | Today's $9 BOM, ADR-028 witness; deployment-cost analysis          | No new ADR — keep ADR-028 baseline   |
+| $15–$30               | Cost analysis showing single-MCU + cluster-Pi path < $30           | New ADR (e.g., ADR-083)              |
+| > $30                 | Deployment-cost analysis showing per-node Pi pays for itself       | Two ADRs (per-node Pi, BOM revision) |
+
+### L2 — Single vs dual MCU per node
+
+| Branch       | Evidence required                                                                          | ADR slot                       |
+|--------------|--------------------------------------------------------------------------------------------|--------------------------------|
+| Single MCU   | ADR-081 5-layer kernel measurements (already 60 byte feature packets, 0.003% CPU at 5 Hz) | No new ADR — keep ADR-081      |
+| Dual MCU     | Measured ISR-jitter problem on single-MCU node; or no_std-CSI maturity demonstrated        | New ADR (firmware split)       |
+
+### L3 — Per-node vs per-cluster heavy compute
+
+| Branch        | Evidence required                                                                             | ADR slot                       |
+|---------------|-----------------------------------------------------------------------------------------------|--------------------------------|
+| Per cluster   | Throughput math: 6 nodes × 5 Hz × 60 B = 1.8 KB/s per cluster; well within USB/Ethernet to Pi | New ADR (cluster-Pi shape)     |
+| Per node      | Need: per-node ML, per-node QUIC, per-node secure boot, deployment without LAN gateway        | New ADR (per-node Pi shape)    |
+
+### L4 — CSI no_std maturity gate
+
+| Branch     | Evidence required                                                                                                              | ADR slot                                  |
+|------------|--------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------|
+| Mature     | esp-csi-rs (or replacement) on real S3 board: matches esp_wifi_set_csi_rx_cb capture rate, frame-loss, ISR-jitter              | Phase-4 of ADR-081 + a `no_std` migration ADR |
+| Not mature | Side-by-side benchmark shows ≥10% drop in capture quality, or ISR-jitter > 100 µs                                              | Defer — remain on ESP-IDF C path          |
+
+### L5 — Mesh control-plane technology
+
+| Branch          | Evidence required                                                                                            | ADR slot                                    |
+|-----------------|--------------------------------------------------------------------------------------------------------------|---------------------------------------------|
+| ESP-WIFI-MESH   | ≤ 25-node target; existing ADR-029 + ADR-073 hold                                                            | No new ADR — keep ADR-029                   |
+| Thread          | ≥ 50-node target; field test showing ESP-WIFI-MESH degradation; comms-MCU change to ESP32-C6 acceptable      | New ADR (Thread control plane)              |
+| `esp-mesh-lite` | Wanting IP-layer routing for QUIC + WiFi homogeneity, but staying on S3                                       | New ADR (mesh-lite migration)               |
+
+### L6 — Heavy-compute SoC choice
+
+| Branch     | Evidence required                                                                                            | ADR slot                                |
+|------------|--------------------------------------------------------------------------------------------------------------|-----------------------------------------|
+| Pi Zero 2W | Buildroot + dm-verity + signed FIT meets the threat model; cost / power matters more than ROM-rooted boot    | New ADR (Pi Zero 2W image / OTA)        |
+| CM4 / Pi 5 | True ROM-rooted secure boot is deployment-required (e.g., regulated environment)                              | New ADR (CM4 image / OTA)               |
+
+---
+
+## 4. Independent decisions — make in parallel
+
+Each of these can be evaluated in isolation; none depend on the L-decisions.
+
+| #  | Decision                              | Default recommendation                                                                                                                                                                      | ADR slot            |
+|----|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------|
+| I1 | LoRa fallback chip                    | **SX1262.** LR1121 only if global / 2.4 GHz / satellite roaming is a deployment requirement. (SOTA §6)                                                                                       | ADR (LoRa fallback) |
+| I2 | PMIC choice                           | **BQ24074 if panel ≤ 2 W**, **BQ25798 if panel ≥ 5 W or solar-only**. SPV1050 only for sub-watt energy harvesting. (SOTA §7)                                                                | ADR (power path)    |
+| I3 | Backhaul protocol                     | **QUIC (`quinn` + `rustls`)** if bidirectional / large payload / mobile-network handoff matters. **MQTT-over-TLS** for low-rate publish-only. (SOTA §5)                                      | ADR (backhaul)      |
+| I4 | OTA per die                           | **`embassy-boot` two-slot** on no_std MCUs. **ESP-IDF native OTA** on ESP-IDF MCUs. **A/B + signed FIT** on Pi. (SOTA §3, §9)                                                                | ADR (OTA)           |
+| I5 | Provisioning protocol                 | **BLE provisioning via `esp-idf-svc`** for any in-field reprovisioning; **USB / serial** for factory provisioning only. (No SOTA section — well-trodden ground.)                            | ADR (provisioning)  |
+
+---
+
+## 5. Recommended ADR sequence
+
+If the three-tier proposal is partially adopted, the recommended ADR
+sequence is **outside-in** — address the cheapest, most independent
+decisions first, gate the load-bearing ones on real evidence:
+
+1. **Independent ADRs first** (any order):
+   - I1 LoRa fallback chip choice.
+   - I2 Power-path / PMIC choice (probably BQ24074 if panel stays ≤ 2 W,
+     BQ25798 otherwise).
+   - I3 QUIC vs MQTT-over-TLS (likely MQTT for the heartbeat-only case,
+     QUIC if model updates and fleet sync are real).
+2. **Per-cluster-Pi ADR** (L3, hybrid branch) — the high-value, low-cost
+   first step. One Pi per 3–6 nodes. Captures most of the ML/QUIC/
+   secure-boot value at minimal per-sensor BOM impact.
+3. **Mesh control-plane ADR** (L5) — only if deployments target > 25
+   nodes. Otherwise stays on ESP-WIFI-MESH per ADR-029.
+4. **CSI no_std maturity benchmark ADR** (L4 evidence) — investigate,
+   but do not commit to dual-MCU until benchmarked.
+5. **Dual-MCU node ADR** (L2) — only after L4 evidence + a clear ML or
+   ISR-jitter problem on the single-MCU node.
+6. **Three-tier-PCB ADR** (full proposal) — last, only if BOM / threat-
+   model / scale all justify it.
+
+This ordering deliberately keeps the bulk of the deployable surface on
+today's ADR-028 / ADR-081 baseline while letting each separable
+upgrade be evaluated on its own evidence.
+
+---
+
+## 6. Out-of-scope for this document
+
+- **Re-evaluating ADR-029 mesh choices** beyond mentioning Thread as
+  alternative — that belongs in a Mesh-control-plane ADR.
+- **Specific PCB layout** of any of the candidate boards.
+- **Cloud-side architecture** (gateway, fleet-sync target, time-series
+  storage). Out of scope of the node architecture proposal.
+- **Cross-environment domain generalization (ADR-027)** — orthogonal to
+  the hardware shape.
+- **Multistatic fusion algorithms** (`wifi-densepose-ruvector::viewpoint`)
+  — orthogonal to the hardware shape.
+
+---
+
+## 7. References to other documents in this set
+
+- `architecture/three-tier-rust-node.md` — the seed proposal.
+- `sota/2026-Q2-rf-sensing-and-edge-rust.md` — SOTA evidence per topic.
+- `architecture/implementation-plan.md` — earlier (2026-04-02) GOAP plan
+  for ESP32-S3 + Pi Zero 2 W; the three-tier proposal is most usefully
+  read as an extension of this plan.
+- `architecture/ruvsense-multistatic-fidelity-architecture.md` —
+  multistatic fusion architecture, orthogonal to node hardware shape.

docs/research/architecture/three-tier-rust-node.md

@@ -0,0 +1,434 @@
+# Three-Tier Rust Node — Exploratory Architecture
+
+| Field        | Value                                                                  |
+|--------------|------------------------------------------------------------------------|
+| **Status**   | Exploratory / not yet decided                                          |
+| **Date**     | 2026-04-25                                                             |
+| **Authors**  | ruv (proposal), filed by goal-planner research agent                   |
+| **Classifies as** | Speculative architectural alternative to ADR-028 / ADR-081 baseline |
+| **Companion**| `docs/research/sota/2026-Q2-rf-sensing-and-edge-rust.md` (SOTA), `docs/research/architecture/decision-tree.md` (decisions) |
+
+> **Reading note.** This document files a long architectural exploration the
+> author wrote before any commitment. It is intentionally optimistic in places
+> and will be tempered by the SOTA survey filed alongside it. The decision
+> tree document maps each load-bearing claim to the evidence that would
+> justify acting on it. Nothing in this document supersedes ADR-028 (the
+> capability audit) or ADR-081 (the 5-layer adaptive kernel). Both already
+> describe a working, single-MCU node; this document describes a
+> hypothetical *three-tier* node that would replace it on PCBs that ship
+> Pi-class compute next to two ESP32-class radios on a solar-powered HAT.
+
+---
+
+## 1. ADRs this proposal would touch
+
+If pursued, this proposal evolves the following decisions. None are
+overturned outright; all need re-read in this light.
+
+- **ADR-028 — ESP32 Capability Audit.** Today's witnessed node is a single
+  ESP32-S3 streaming raw ADR-018 frames over UDP. A three-tier node changes
+  the audit subject from "one MCU" to "two MCUs + a Pi", with implications
+  for the witness bundle, firmware-manifest hashes, and per-node BOM.
+- **ADR-081 — Adaptive CSI Mesh Firmware Kernel.** The 5-layer kernel
+  already separates radio abstraction (L1), adaptive control (L2), mesh
+  plane (L3), feature extraction (L4), and Rust handoff (L5). A three-tier
+  node would split L1–L2 onto a no_std sensor MCU, L3 onto an ESP-IDF
+  comms MCU, and Layer-5+ Rust workload onto the Pi. The split is
+  compatible with the kernel; it is a deployment shape rather than a
+  redesign.
+- **ADR-018 — ESP32 Dev Implementation.** ADR-018 binary CSI frames remain
+  the wire format between the sensor MCU and whoever consumes them. The
+  three-tier proposal tightens the contract: ADR-018 frames flow from
+  sensor MCU into the comms MCU only, never directly off the node.
+- **ADR-029 / ADR-031 — Multistatic and sensing-first RF mode.** A
+  hardware-gated Pi Zero 2W enables the sensing-first mode to actually
+  hibernate the heavy compute, which ADR-031's power model assumes but the
+  current node cannot deliver because heavy compute lives off-node.
+- **ADR-032 — Multistatic mesh security hardening.** HMAC-SHA256 beacon
+  auth + SipHash-2-4 frame integrity in ADR-032 already cover the
+  inter-node bus. The proposal adds Secure Boot V2 + flash encryption
+  at-rest on each MCU, and a signed Pi A/B image, which are *complements*
+  to ADR-032, not substitutes.
+
+---
+
+## 2. Motivating thesis
+
+A WiFi/RF sensing node has three jobs that prefer three different
+runtimes:
+
+1. **Strict-real-time radio capture and DSP** — sub-millisecond ISR
+   discipline, no allocator surprises, predictable interrupt latency.
+2. **Networking, OTA, mesh, time sync** — TCP/IP, TLS, BLE provisioning,
+   ESP-WIFI-MESH, OTA bootloaders, NVS. The full battery of WiFi-stack
+   features that come with ESP-IDF and FreeRTOS.
+3. **Heavy compute, ML inference, storage, fleet sync** — gigabytes of
+   model weights, vision inference, persistent storage, QUIC-based fleet
+   sync, optional cloud APIs.
+
+Today's RuView node tries to fit jobs 1 and 2 onto one ESP32-S3, and job 3
+either runs on a separate machine (the "sensing-server" host) or is
+absent. The thesis of this proposal is that **collapsing all three onto
+a single PCB but onto three separate dies** captures most of the
+"single node" simplicity without sacrificing the runtime properties of
+each layer. Concretely:
+
+- **Sensor MCU** — ESP32-S3, no_std, `esp-hal` + Embassy + `heapless` +
+  `postcard`. ISR-driven CSI capture, channel hopping, short-window DSP.
+  No WiFi stack of its own (the radio is in the comms MCU); a private
+  UART or SPI link to the comms MCU carries serialized frames. *(See SOTA
+  survey, §3, for the ISR-safety caveat that tempers this.)*
+- **Comms MCU** — second ESP32-S3, ESP-IDF, `esp-idf-svc` + `esp-idf-sys`,
+  TLS/HTTPS/OTA/ESP-WIFI-MESH, NVS provisioning, BLE provisioning, LoRa
+  fallback. Owns the "outside world."
+- **Pi Zero 2W** — *normally power-gated*. Wakes on event from the comms
+  MCU, runs heavy ML or fleet-sync work, optionally streams QUIC to a
+  gateway, then power-gates again. `tokio` + `quinn` + `rustls` + `axum`.
+
+A single PCB, a single 1S Li-ion + 2 W solar + linear charger, a single
+enclosure. Three separate cores each running the runtime they are
+actually good at.
+
+---
+
+## 3. Hardware shape (proposed)
+
+### 3.1 Bill of materials (per node, target)
+
+| Slot                | Part                                             | Notes                                             |
+|---------------------|--------------------------------------------------|---------------------------------------------------|
+| Sensor MCU          | ESP32-S3-WROOM-1 (8 MB flash, 8 MB PSRAM)        | no_std, Embassy, esp-radio. Always-on.            |
+| Comms MCU           | ESP32-S3-MINI-1 or -WROOM-1 (4 MB flash)         | ESP-IDF, ESP-WIFI-MESH, OTA, TLS. Mostly-on.      |
+| Heavy compute       | Pi Zero 2W (1 GB RAM)                            | Power-gated by default. Wake on event.            |
+| LoRa fallback       | Semtech SX1262 module                            | Heartbeat + recovery only. Sub-GHz.               |
+| Charger / PMIC      | TI BQ24074 (linear) or BQ25798 (buck-boost MPPT) | See SOTA §7 for trade-off.                         |
+| Battery             | 1S Li-ion 18650 (3.0 Ah class)                   | Standard cell, easy to source.                     |
+| Solar panel         | ~2 W, 6 V, IP-rated                              | Roof-mount or window-mount.                        |
+| Pi power gate       | Logic-level P-FET high-side switch + ESP GPIO    | Hard-cut when idle (350 mA → ~0 mA).               |
+| Inter-MCU bus       | UART or SPI between sensor MCU and comms MCU     | Postcard-framed binary on a 4-wire link.           |
+| Comms-to-Pi bus     | UART (115200–921600 bps) or SPI                  | Pi-side `tokio-serial`/`spidev`.                   |
+| Enclosure           | IP54 or IP65 with antenna pass-through           | -                                                  |
+| Estimated BOM       | $40–55                                           | At small build qty; falls with volume.             |
+
+This is roughly 4–6× the ~$9 single-S3 node, which is the largest
+single mark against the proposal. See §7.4 for whether the cost makes
+sense.
+
+### 3.2 Power-state hierarchy (proposed)
+
+| State          | Sensor MCU       | Comms MCU       | Pi Zero 2W       | Approx draw     |
+|----------------|------------------|-----------------|------------------|-----------------|
+| Deep idle      | light sleep      | DTIM-modulated  | hard-off         | < 5 mA          |
+| Sample window  | active CSI       | passive listen  | hard-off         | ~80 mA          |
+| Event publish  | active CSI       | TX burst        | hard-off         | ~150 mA peak    |
+| Escalation     | active CSI       | TX + bring-up   | booting          | ~350 mA peak    |
+| ML in progress | active CSI       | passive         | inferencing      | ~450 mA         |
+| Recovery       | sleep            | LoRa heartbeat  | hard-off         | ~30 mA          |
+
+The Pi is treated as the heavyweight worker that **must** be hard-power-
+gated — not soft-suspended — when not in use. ARM SoCs leak in
+suspend; a 350 mA "off" leakage destroys solar viability.
+
+### 3.3 Energy budget sketch
+
+- **Daily load** (sketch, *not measured*): ~1.4 Wh/day assuming Pi wakes
+  ≤ 2 minutes/day on average, sensor MCU light-sleeps when idle, comms
+  MCU DTIM-3 most of the time.
+- **Daily harvest**: 2 W panel × 4 PSH × 0.7 system efficiency ≈ 5.6
+  Wh/day in the seasonal worst case for mid-latitudes.
+
+Headroom is roughly 4×. If a deployment skews colder/cloudier, or the
+inter-MCU bus runs hotter, headroom is 2–3×. SOTA §7 covers whether
+the linear-charger + supercap-buffered topology actually delivers this
+math, or whether MPPT is needed on a panel this small.
+
+---
+
+## 4. Software shape (proposed)
+
+### 4.1 Sensor MCU — no_std embedded Rust
+
+| Concern              | Crate(s)                                                     |
+|----------------------|--------------------------------------------------------------|
+| HAL / async runtime  | `esp-hal` 1.x + Embassy executor                             |
+| Time / timers        | `embassy-time`                                               |
+| Static allocations   | `heapless` (`Vec`, `String`, `Deque`, MPMC channels)         |
+| Wire format          | `postcard` over `serde` for compact, schema-stable bytes     |
+| CRC                  | `crc` crate (already used host-side for the L4 packet check) |
+| RF capture           | `esp-radio` (the rename of `esp-wifi`) — CSI hooks via PR    |
+| Inter-MCU bus        | `embassy-uart` or `embedded-hal-async` SPI                   |
+| Power management     | `esp-hal::system::sleep::*` + light-sleep wake on GPIO/timer |
+
+Boundary: the sensor MCU does **not** initialize a WiFi stack. It owns
+the PHY for CSI capture only. All actual WiFi connectivity is on the
+comms MCU. This is the load-bearing simplification of the proposal: it
+sidesteps the embassy-on-ESP-IDF ISR-safety question by not running
+ESP-IDF on this die at all.
+
+### 4.2 Comms MCU — std + ESP-IDF Rust
+
+| Concern              | Crate(s)                                                                 |
+|----------------------|--------------------------------------------------------------------------|
+| FreeRTOS bindings    | `esp-idf-sys`                                                            |
+| Service abstractions | `esp-idf-svc` (HTTPS, OTA, NVS, mDNS, BLE, MQTT, ESP-NOW)                |
+| Async runtime        | `esp-idf-svc::timer::EspTaskTimerService` (NOT Embassy directly — see §6)|
+| TLS                  | mbedTLS via `esp-idf-svc`                                                |
+| Mesh                 | ESP-WIFI-MESH (or ESP-MESH-LITE — see SOTA §8)                           |
+| OTA                  | ESP-IDF native OTA (signed images, A/B partitions)                       |
+| LoRa fallback        | `lora-phy` or vendor C driver via `esp-idf-sys`                          |
+| Inter-MCU bus        | UART driver (`esp-idf-svc::uart`) framed with postcard                   |
+| BLE provisioning     | NimBLE via `esp-idf-svc`                                                 |
+
+The comms MCU is the *only* die that needs the full WiFi-stack security
+surface. That makes it the obvious place to enforce Secure Boot V2 +
+flash encryption + signed OTA.
+
+### 4.3 Pi Zero 2W — std Rust on Linux
+
+| Concern              | Crate(s)                                                              |
+|----------------------|-----------------------------------------------------------------------|
+| Async runtime        | `tokio`                                                               |
+| QUIC                 | `quinn` + `rustls`                                                    |
+| HTTP server (local)  | `axum`                                                                |
+| RPC to comms MCU     | `tokio-serial` (UART) or `spidev` (SPI), framed with postcard         |
+| ML inference         | `tract` (ONNX), `candle` (Pytorch-flavored), or `ort` (ONNX Runtime)  |
+| Persistent storage   | `sled` or `redb`                                                      |
+| OS                   | Buildroot-based custom image, A/B partitions, dm-verity, signed       |
+
+Crucial constraint: the Pi runs **buildroot**, not Raspberry Pi OS. The
+Raspberry Pi Foundation does not officially support secure boot on the
+Pi Zero 2W; the secure-boot path is Pi 4/5-only. The cleanest path on a
+Pi Zero 2W is buildroot + signed FIT image + dm-verity on the rootfs +
+A/B partitions for OTA. See SOTA §9 for the realistic version of this.
+
+### 4.4 OTA on three dies
+
+| Die          | OTA mechanism                                                         |
+|--------------|-----------------------------------------------------------------------|
+| Sensor MCU   | `embassy-boot`-style two-slot OTA, signed images, ed25519 verification|
+| Comms MCU    | ESP-IDF native OTA, signed by project key, dual app partitions        |
+| Pi Zero 2W   | A/B rootfs, signed FIT, fwupd or homemade `update-agent` binary       |
+
+OTA is the area where the three-tier shape is most defensible. Each die's
+update is a separate, independently rollback-able artifact. The comms
+MCU acts as the *broker* — it pulls signed images for all three dies,
+verifies them, and pushes them onto the sensor MCU and Pi over their
+respective buses.
+
+---
+
+## 5. Networking shape (proposed)
+
+Three concentric rings:
+
+1. **Inner ring — node-local IPC.** Postcard over UART/SPI between the
+   three dies. Length-prefixed, CRC-checked, no encryption (it's on a
+   trace, not a wire).
+2. **Middle ring — RuView mesh.** ESP-WIFI-MESH (or ESP-MESH-LITE)
+   between comms MCUs across nodes, carrying L3 mesh-plane messages
+   from ADR-081 (TIME_SYNC, ROLE_ASSIGN, CHANNEL_PLAN, FEATURE_DELTA,
+   HEALTH, ANOMALY_ALERT). Authenticated with HMAC-SHA256 per ADR-032.
+3. **Outer ring — backhaul.** QUIC from the Pi to a gateway/cloud
+   target (`quinn` + `rustls`), with the gateway optionally being
+   another node's Pi acting as a fusion-relay. LoRa is the *fallback*
+   ring for heartbeats and recovery commands when the WiFi mesh is
+   degraded.
+
+LoRa duty-cycle math (EU868 1% in the relevant sub-band, US915 dwell-
+time-only) is friendly to "20 bytes every minute" heartbeats; at SF7,
+125 kHz, the airtime is ~40 ms per packet — far under the 36 s/hour
+EU868 limit. See SOTA §6 for the citation.
+
+---
+
+## 6. Security posture (proposed)
+
+The proposal layers four mechanisms on each MCU:
+
+- **Secure Boot V2** — RSA-3072 or ECDSA signed bootloader, immutable
+  primary key digest in eFuse.
+- **Flash encryption** — AES-XTS-256 with per-device key burned in eFuse,
+  hardware-isolated.
+- **Disabled ROM download** — `DIS_DOWNLOAD_MODE` fuse blown after
+  provisioning so the device cannot be coerced back into a UART-ROM
+  state.
+- **Signed OTA images** — separate signing key from the secure-boot key,
+  per-image rollback counter, anti-rollback eFuse counter.
+
+On the Pi: dm-verity over a read-only rootfs, signed FIT image with the
+RPi-foundation-blessed (where possible) bootcode, A/B partitions, and a
+signed manifest of the three dies' image hashes shipped together. The
+comms MCU validates the manifest before consuming any image.
+
+This is **complementary** to ADR-032's HMAC-SHA256 + SipHash-2-4 mesh
+hardening — those protect frames in flight; Secure Boot + flash
+encryption protect images at rest.
+
+---
+
+## 7. Honest critique of this proposal
+
+This section is required by the project conventions. The companion SOTA
+survey expands each of these.
+
+### 7.1 The cost story is bad before volume
+
+A single ESP32-S3 node is ~$9 today. A three-tier node is closer to
+$40–55. RuView's design point of "many cheap nodes" rewards low BOM. The
+three-tier shape is justified only if each node *also* replaces a
+sensing-server host (i.e., a Pi or laptop running the sensing pipeline)
+that would have cost more than the marginal Pi-on-each-node. In a
+deployment with 3 nodes feeding one $80 host, the host already amortizes
+across the nodes. In a 50-node deployment, the math changes.
+
+### 7.2 The embassy-on-ESP-IDF ISR-safety question is real
+
+The proposal *avoids* this question by giving the sensor MCU a no_std
+runtime instead of putting embassy on top of esp-idf-svc. The reason
+this matters: per esp-idf-svc maintainers, **embassy-executor is not
+ISR-safe** in the esp-idf-svc setup (it relies on `critical-section`,
+which on esp-idf-hal is implemented over FreeRTOS task suspension). On
+no_std with `esp-hal`, embassy is fine; on top of ESP-IDF, it is not.
+The two-MCU split is the cleanest engineering answer to the question;
+the alternative is keeping ESP-IDF on the single MCU (today's design)
+and not introducing embassy at all. SOTA §3 documents the citation.
+
+### 7.3 esp-radio replaces esp-wifi, and CSI no_std support is partial
+
+The crate that the sensor MCU would use to capture CSI (in the
+`esp-rs/esp-hal` 1.x ecosystem) was renamed to `esp-radio`. Third-party
+`esp-csi-rs` exists and targets no_std but is described as
+"early development." The 5-layer kernel today runs on top of ESP-IDF
+v5.4 in C — a bird in the hand. Migrating CSI capture to no_std is a
+distinct project, not a side effect of the three-tier shape. SOTA §2
+covers the maturity matrix.
+
+### 7.4 The Pi Zero 2W secure-boot story is weaker than the proposal implies
+
+The Raspberry Pi Foundation's official secure-boot path is **Pi 4 / Pi 5
+only**, with a USB-rooted RSA chain. There is no official secure-boot
+bring-up document for the Pi Zero 2W. Buildroot + signed FIT + dm-verity
+gets you most of the threat surface — but the proposal's "Pi 4 + buildroot
+is the strongest path" line is not a Pi Zero 2W story. If true secure
+boot matters for the deployment, the heavy-compute die should arguably
+be a Pi 4 Compute Module (CM4) and not a Pi Zero 2W. SOTA §9 covers it.
+
+### 7.5 ESP-WIFI-MESH at 50–500 nodes is an open question
+
+Espressif documents up to 1,000 nodes and 25 layers as theoretical limits
+for ESP-WIFI-MESH, with a recommended fan-out of 6 per node. There is
+limited public evidence of stable 100+ node deployments in adversarial
+RF environments. Comms-MCU mesh handling at scale is *not free*: the
+mesh stack runs in the comms MCU's main loop, sharing CPU with TLS, OTA,
+and BLE. SOTA §8 covers BLE Mesh / Thread / Zigbee comparison. None of
+those replace WiFi-stack-sharing for CSI capture, but they could replace
+ESP-WIFI-MESH for control-plane traffic if scale becomes a problem.
+
+### 7.6 MPPT vs linear charger at 2 W panel
+
+The proposal's BQ24074-based linear-charger topology is fine for a 2 W
+panel; the efficiency loss vs MPPT is real but small at this scale.
+At 2 W, the MPPT die (BQ25798) silicon, inductor, and code complexity
+costs partly cancel its efficiency gain. SOTA §7 has the math.
+
+### 7.7 The QUIC outer ring is overkill for the heartbeat case
+
+QUIC is a strong choice when the Pi has lots of bursty data and is
+behind a NAT or on flaky cellular. For a node that wakes 2 minutes/day
+and emits a few KB of summarized features, MQTT-over-TLS or even
+plain HTTPS is simpler and adequate. QUIC's value goes up if the Pi
+also runs bidirectional model updates or large-batch fleet sync.
+SOTA §5.
+
+---
+
+## 8. What evidence would justify acting on this proposal
+
+This section maps to the decision tree in
+`docs/research/architecture/decision-tree.md`. The short version:
+
+1. **Per-node cost ceiling.** Decide the BOM ceiling per node. The
+   three-tier shape only makes sense above ~$30/node and at deployments
+   where the host computer is *not* a separate cost.
+2. **CSI no_std maturity gate.** `esp-csi-rs` (or the replacement under
+   `esp-radio`) must demonstrate equivalent capture quality to today's
+   `esp-wifi-set-csi-rx-cb`-based path on a real ESP32-S3 board, with
+   ISR-jitter measured. Until this is verified, the sensor-MCU Rust
+   story is risk.
+3. **Inter-MCU bus saturation.** Postcard-framed UART/SPI between the
+   sensor MCU and comms MCU must carry ADR-018 frames at the target
+   capture rate without backpressure-induced drops at the sensor MCU.
+4. **Pi power-gate budget.** Measured leakage of the gated Pi Zero 2W,
+   with proven cold-boot wake-up under 5 s, is required before the
+   energy budget closes.
+5. **Mesh scale evidence.** A 12+ node ESP-WIFI-MESH (or alternative)
+   field test at sustained 1–10 Hz `rv_feature_state_t` upload is
+   required to validate the middle ring at >>3 nodes.
+6. **Secure-boot path on Pi Zero 2W.** Either accept that the Pi cannot
+   be fully secure-booted, or upgrade the heavy-compute die to a CM4 /
+   CM5 / Pi 5 if true secure boot is a deployment requirement.
+
+---
+
+## 9. Open questions
+
+The proposal as written elides answers to these:
+
+- **Why two ESP32-S3 dies and not one ESP32-S3 plus one ESP32-C6?** The
+  C6 is RISC-V, has 802.15.4 + WiFi 6, and would let the comms MCU
+  handle BLE Mesh / Thread / Zigbee natively. The two-S3 split chose
+  homogeneity and Xtensa toolchain; the C6 split chooses richer
+  protocol coverage on the comms die.
+- **Is the sensor MCU strictly necessary?** Today, the single-MCU node
+  (ADR-028 / ADR-081) handles CSI capture and ESP-IDF networking on one
+  S3, in C, and works. The two-MCU-on-board case is justified mainly by
+  *ISR purity* and *Rust no_std*, not by a missing capability today.
+- **Why a Pi Zero 2W rather than the Pi being the gateway?** The
+  proposal puts a Pi *on every node*. A more conservative shape is one
+  Pi per *site* (or per cluster of 3–6 nodes), with the nodes staying
+  single-MCU. That keeps the BOM near today's $9/node for sensors,
+  isolates heavy compute, and concentrates secure boot on a smaller
+  number of more capable dies. This is the deployment shape implicit in
+  ADR-031's sensing-first mode and is worth comparing head-to-head.
+- **What does a single 50-node deployment cost** under each of: today's
+  shape (one S3 + one host), one-Pi-per-site (one S3 + one Pi per ~6
+  nodes), and the proposal (3-die-per-node)? The cost crossover point
+  determines which architecture is correct.
+
+---
+
+## 10. Recommendation
+
+This document records the proposal accurately. It does not recommend
+adopting it. The recommendation, if a decision is forced, is:
+
+1. **Do not build a three-tier-per-node PCB now.** The current shape
+   (single ESP32-S3 + ADR-081 5-layer kernel) is the witnessed system.
+2. **Investigate one-Pi-per-site as the cheaper variant** (proposal §9
+   bullet 3). It captures most of the heavy-compute and QUIC-backhaul
+   benefits at a fraction of the BOM.
+3. **Spend the first chunk of effort on the three "evidence" gates from
+   §8** — CSI no_std maturity, ESP-WIFI-MESH at scale, and Pi
+   secure-boot reality — *before* committing to a hardware re-spin.
+4. **Reserve the three-tier shape** for a future "RuView Pro" SKU
+   targeting deployments where per-node BOM is not the dominant cost
+   and full secure-boot + dm-verity at the edge is mandatory.
+
+The decision tree document codifies these gates as branch points so
+they can be checked off independently rather than as one large
+all-or-nothing ADR.
+
+---
+
+## 11. Companion documents
+
+- **SOTA survey.** `docs/research/sota/2026-Q2-rf-sensing-and-edge-rust.md`
+  — citations, primary sources, what's true in 2026 for each load-bearing
+  claim above.
+- **Decision tree.** `docs/research/architecture/decision-tree.md` — the
+  Mermaid map from each load-bearing decision to its dependencies and
+  ADR slot.
+- **Existing implementation plan.** `docs/research/architecture/implementation-plan.md`
+  — the ESP32-S3 + Pi Zero 2W goal-state plan from 2026-04-02. The
+  three-tier proposal is most usefully read as an evolution of *that*
+  plan rather than a replacement of ADR-028.

docs/research/rf-topological-sensing/10-system-architecture-prototype.md

@@ -337,7 +337,7 @@ Usage in rf_topology:
 ### 3.1 Module Location
 
 ```
-rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/
+v2/crates/wifi-densepose-signal/src/ruvsense/
   rf_topology.rs          <-- New module (primary)
   rf_topology/
     graph.rs              <-- RfGraph aggregate root
@@ -351,7 +351,7 @@ rust-port/wifi-densepose-rs/crates/wifi-densepose-signal/src/ruvsense/
 Alternatively, rf_topology could be a standalone crate:
 
 ```
-rust-port/wifi-densepose-rs/crates/wifi-densepose-topology/
+v2/crates/wifi-densepose-topology/
   src/
     lib.rs
     graph.rs

docs/research/sota/2026-Q2-rf-sensing-and-edge-rust.md

@@ -0,0 +1,601 @@
+# SOTA Survey — RF Sensing and Edge Rust (2026 Q2)
+
+| Field        | Value                                                                  |
+|--------------|------------------------------------------------------------------------|
+| **Status**   | Reference / informs `architecture/three-tier-rust-node.md`             |
+| **Date**     | 2026-04-25                                                             |
+| **Author**   | goal-planner research agent                                            |
+| **Scope**    | What's true in 2026, what holds up in the three-tier proposal, what to reconsider |
+| **Word target** | ~3,500 words                                                        |
+
+> **Conventions.** Each section answers (a) what's true in 2026, (b) what
+> claims in the three-tier proposal hold up, (c) what to reconsider, and
+> (d) primary references. Where no primary source could be located, the
+> claim is explicitly marked **"no primary source found, mark as
+> conjecture."**
+
+---
+
+## 1. WiFi CSI through-wall pose / occupancy estimation
+
+### 1.1 What's true in 2026
+
+The CSI-to-pose literature has matured along three orthogonal axes since
+DensePose-from-WiFi (2022) lit the fuse:
+
+- **Lightweight architectures.** WiFlow (Feb 2026) demonstrated a
+  spatio-temporal-decoupled network with 4.82 M parameters, 0.47 GFLOPs,
+  PCK@20 = 97.0% and MPJPE ≈ 8 mm on the random-split MM-Fi benchmark,
+  3–4× smaller than WPformer and ~25× smaller than WiSPPN.
+- **Domain generalization.** PerceptAlign (DT-Pose) and the
+  cross-environment evaluation in MM-Fi made the cross-subject and
+  cross-layout numbers honest. PerceptAlign reports MPJPE 222 mm on Scene
+  4 and 317 mm on Scene 5 in cross-layout test, beating prior SOTA by
+  >50% — but those are still order-of-magnitude worse than in-domain.
+- **Topological priors.** GraphPose-Fi (2025) and topology-constrained
+  decoders (DT-Pose) explicitly use the human skeleton as a graph,
+  improving plausibility under occlusion.
+- **Multistatic geometry.** RuView's own ADR-029/ADR-031 line is the
+  practical multistatic story; ISAC-Fi (Aug 2024) and the multistatic
+  ISAC-MIMO papers (2024–2025) describe similar geometry as a 6G research
+  topic. IEEE 802.11bf-2025 (published 26 September 2025) is the
+  standardization vector.
+
+### 1.2 What holds up
+
+The proposal's claim that "3–6 ESP32-S3 nodes can do meaningful pose
+work" is consistent with WiFlow's network sizes (4.82 M params, INT8
+~5 MB) and with the MM-Fi multi-link benchmark. The CSI pipeline does
+not need a Pi *per node* to run inference; one Pi per cluster is
+sufficient. RuView's existing ESP32-mesh + sensing-server already
+demonstrates the shape.
+
+### 1.3 What to reconsider
+
+- **Through-wall claims are still aggressive.** Published WiFi sensing
+  papers focus on line-of-sight or single-wall cases; published
+  through-multiple-walls numbers in 2025–2026 are scarce. The
+  three-tier proposal's "through-wall" framing should be tempered to
+  "through-thin-wall" without primary evidence. *No primary source
+  found for through-multiple-walls, mark as conjecture.*
+- **Nexmon-on-Pi is not obviously a win.** Nexmon CSI on a Pi 4 captures
+  up to 80 MHz BW on Broadcom chips and gives more subcarriers per frame
+  than ESP32, but the Pi platform has no equivalent of ESP32 Secure Boot
+  V2, and the Broadcom firmware-patch path is fragile across kernel
+  releases. RuView's existing ESP32-S3 mesh already beats Nexmon-on-Pi
+  on cost, security posture, and provisioning.
+- **USRP/SDR is overkill for occupancy and pose**, and is far over the
+  proposal's BOM ceiling. It would only become attractive for
+  research-grade beamforming or sub-cm ranging.
+
+### 1.4 Primary references
+
+- WiFlow: [arXiv:2602.08661](https://arxiv.org/html/2602.08661) — Feb 2026.
+- DT-Pose: [arXiv:2501.09411](https://arxiv.org/abs/2501.09411) — Jan 2025.
+- GraphPose-Fi: [arXiv:2511.19105](https://arxiv.org/abs/2511.19105) — Nov 2025.
+- Geometry-aware cross-layout HPE: [arXiv:2601.12252](https://arxiv.org/html/2601.12252).
+- Nexmon CSI: [seemoo-lab/nexmon_csi](https://github.com/seemoo-lab/nexmon_csi).
+
+---
+
+## 2. IEEE 802.11bf and multistatic ISAC
+
+### 2.1 What's true in 2026
+
+**IEEE Std 802.11bf-2025 was published 26 September 2025** and is the
+ratified amendment for WLAN sensing in license-exempt bands 1–7.125 GHz
+and >45 GHz. The 3rd SA Ballot Recirculation closed 16 January 2025
+with 98% approval. P802.11bf/D8.0 (March 2025) was the last public
+draft. The standard defines sensing operation on top of HE/EHT PHYs and
+on the DMG/EDMG (60 GHz) PHYs.
+
+3GPP RAN #108 (June 2025) admitted ISAC into the 6G study scope as a
+"Day 1" 6G feature. ISAC-Fi (Aug 2024) demonstrated *monostatic* sensing
+over commodity WiFi by repurposing the communication waveform.
+Multistatic ISAC over cell-free MIMO (2024–2025) is the analytical
+direction.
+
+### 2.2 What holds up
+
+The three-tier proposal's framing of "WiFi mesh + multistatic sensing"
+is well-aligned with where the standard is moving. ADR-029's existing
+multistatic mode and ADR-073's multifrequency mesh scan are the kind of
+pre-standard implementations that 802.11bf is now codifying.
+
+### 2.3 What to reconsider
+
+- **802.11bf does not turn an ESP32 into an 802.11bf sensor.** It
+  defines a *protocol* for sensing-aware exchanges between APs and
+  STAs. Off-the-shelf ESP32-S3 silicon was designed before the standard;
+  CSI extraction on ESP32 will keep being a side channel, not a
+  standards-blessed feature, until Espressif ships a chip with the
+  802.11bf MAC primitives. *No primary source found for an Espressif
+  802.11bf-aware product, mark as conjecture.*
+- **ISAC-Fi's monostatic-on-commodity-WiFi result** is interesting but
+  requires PHY changes; not a path to ESP32 today.
+- **The proposal should claim "802.11bf-compatible feature set" rather
+  than "802.11bf-compliant"** until silicon exists.
+
+### 2.4 Primary references
+
+- IEEE 802.11bf-2025: [standards.ieee.org](https://standards.ieee.org/ieee/802.11bf/11574/).
+- ISAC-Fi: [arXiv:2408.09851](https://arxiv.org/abs/2408.09851).
+- IEEE 802.11bf overview paper: [arXiv:2207.04859](https://arxiv.org/pdf/2207.04859).
+- NIST overview: [nist.gov/publications/ieee-80211bf](https://www.nist.gov/publications/ieee-80211bf-enabling-widespread-adoption-wi-fi-sensing).
+
+---
+
+## 3. Embedded Rust ecosystem for ESP32-S3 (2026)
+
+### 3.1 What's true in 2026
+
+The esp-rs ecosystem has matured but rebranded:
+
+- **`esp-hal` is at 1.x.** `esp-hal 1.0.0` shipped October 2023; `1.1.0`
+  was released April 2024. Stabilized HAL APIs, async drivers, but with
+  the constraint that "async drivers can no longer be sent between
+  cores and executors."
+- **`esp-wifi` was renamed to `esp-radio`** in the 1.x line. The
+  scheduler functionality moved to a new crate `esp-rtos`. Existing
+  `esp-wifi` references in tutorials are pre-1.x.
+- **Embassy on ESP** is split: on no_std ESP-HAL it's a first-class
+  citizen, but the Embassy team and Espressif explicitly steer Embassy
+  use *toward* `esp-rtos` over time.
+- **Embassy on top of `esp-idf-svc` (std)** has a documented gotcha:
+  **embassy-executor is not ISR-safe** because it depends on
+  `critical-section`, which `esp-idf-hal` implements over FreeRTOS task
+  suspension. The recommended std executor is `edge-executor` or the
+  built-in `esp-idf-hal` executor.
+- **CSI capture on no_std** via `esp-csi-rs` (third-party crate) exists
+  but is documented as "still in early development." The
+  production-blessed CSI path remains `esp_wifi_set_csi_rx_cb()` in
+  ESP-IDF C — exactly what `firmware/esp32-csi-node/main/csi_collector.c`
+  uses today.
+
+### 3.2 What holds up
+
+The three-tier proposal's choice to put the **sensor MCU on no_std**
+(`esp-hal` + Embassy) avoids the ESP-IDF ISR-safety question entirely,
+which is the right architectural answer to a real problem. The proposal
+is correct that `heapless` + `postcard` + `embassy-time` is the modern
+no_std default.
+
+### 3.3 What to reconsider
+
+- **Update the toolchain names.** The proposal lists `esp-wifi`; in 1.x
+  this is `esp-radio`. It lists `embassy-executor` on the comms MCU
+  by implication; on the comms MCU the executor must be
+  `edge-executor` or `esp-idf-hal`'s built-in executor, not Embassy.
+- **CSI maturity is the gating risk.** `esp-csi-rs` is early
+  development and the production CSI path is still C. Migrating CSI to
+  no_std Rust is a project unto itself, not a free side effect of
+  splitting the dies.
+- **`esp-idf-svc` parity with C ESP-IDF is good but not 100%.** OTA,
+  HTTPS, NVS, BLE provisioning, ESP-WIFI-MESH all have wrappers. Some
+  niche ESP-IDF C APIs still need `esp-idf-sys` raw FFI. This is fine
+  but means the comms MCU is not "all-Rust" — there's a layer of unsafe
+  wrapping at the bottom.
+
+### 3.4 Primary references
+
+- esp-hal releases: [github.com/esp-rs/esp-hal/releases](https://github.com/esp-rs/esp-hal/releases).
+- esp-idf-svc CHANGELOG: [github.com/esp-rs/esp-idf-svc/blob/master/CHANGELOG.md](https://github.com/esp-rs/esp-idf-svc/blob/master/CHANGELOG.md).
+- Embassy ISR-safety gotcha: [esp-idf-svc#342](https://github.com/esp-rs/esp-idf-svc/issues/342) and esp-idf-svc CHANGELOG.
+- esp-csi-rs crate: [crates.io/crates/esp-csi-rs](https://crates.io/crates/esp-csi-rs).
+- Embassy Book: [embassy.dev/book](https://embassy.dev/book/).
+
+---
+
+## 4. Edge ML for CSI on ESP32-class hardware
+
+### 4.1 What's true in 2026
+
+- **TFLite Micro on ESP32-S3** is the most-cited path. Reported
+  numbers: wake-word inference at 50–60 ms latency, model size ~240 KB
+  flash, ~350 KB RAM. INT8 quantization reportedly delivers >6× speedup
+  over float on S3. Espressif's `esp-tflite-micro` is the reference
+  port.
+- **`tract`** (Sonos's pure-Rust ONNX/NNEF runtime) targets std Linux
+  primarily; there is no widely-adopted no_std no-alloc port.
+- **`candle`** (Hugging Face's Pytorch-flavored Rust ML library) is std
+  Linux/macOS/Windows; not designed for MCU class.
+- **ONNX Runtime (`ort` Rust binding)** is a wrapper over the C++
+  runtime; on ARMv8 (Pi Zero 2W) it works, on Xtensa it does not.
+- **ESP-DL** is Espressif's own DL framework for ESP32-S2/S3, optimized
+  for the AI extensions of the Xtensa LX7 (which ESP32-S3 has). It is C,
+  not Rust.
+
+For a 4.82 M-param INT8 WiFlow at 0.47 GFLOPs:
+
+- On a Pi Zero 2W (Cortex-A53 quad, NEON), inference is plausibly in
+  the 50–100 ms range. *No primary measurement found for WiFlow on Pi
+  Zero 2W; mark as conjecture.*
+- On an ESP32-S3 (Xtensa LX7, 240 MHz, AI extensions), even INT8 4.82M
+  is outside the 8 MB flash + 8 MB PSRAM envelope when intermediate
+  tensors are counted. WiFlow on S3 would require additional pruning or
+  a smaller model class.
+
+### 4.2 What holds up
+
+The proposal's split between "sensor MCU does ISR-clean DSP" and "Pi
+runs the model" is the right shape. ML inference at the WiFlow scale is
+*not* an ESP32 workload in 2026.
+
+### 4.3 What to reconsider
+
+- **The sensor MCU's ML role should be tiny-feature inference, not
+  pose.** Motion classification, presence binary, anomaly thresholding —
+  the ADR-039 Tier-0/Tier-1 outputs — fit on ESP32-S3 with TFLite Micro
+  or hand-written DSP. They do not fit `tract` or `candle` no_std.
+- **For Rust-on-MCU-ML**, the realistic path is hand-rolled INT8
+  inference (RuView's `wifi-densepose-nn` already has FFI hooks) or a
+  Rust port of a tiny TFLM-style runtime. **No mainstream Rust
+  no_std-no_alloc ONNX runtime exists in production at 2026 Q2.**
+- **The Pi Zero 2W's 1 GB RAM is fine for WiFlow but tight for larger
+  pose models.** A CM4/CM5 with 4 GB unlocks Hugging-Face-class models;
+  whether the deployment needs that is a use-case question.
+
+### 4.4 Primary references
+
+- esp-tflite-micro: [github.com/espressif/esp-tflite-micro](https://github.com/espressif/esp-tflite-micro).
+- ESP32-S3 TFLite Micro practical guide: [zediot.com](https://zediot.com/blog/esp32-s3-tensorflow-lite-micro/).
+- WiFlow architecture (parameters/FLOPs): [arXiv:2602.08661](https://arxiv.org/html/2602.08661).
+- ESP32-S3 TinyML INT8 speedup: [zediot.com TinyML optimization](https://zediot.com/blog/esp32-s3-tinyml-optimization/).
+
+---
+
+## 5. QUIC for IoT backhaul
+
+### 5.1 What's true in 2026
+
+- **`quinn` + `rustls` is the production Rust QUIC stack.** Both target
+  std Linux, both work fine on ARMv8 (Pi Zero 2W). `rustls` is
+  FIPS-validatable via the AWS-LC backend.
+- **MQTT-over-QUIC is the emerging IoT pattern.** EMQX 5.x and NanoMQ
+  both ship MQTT-over-QUIC; published benchmarks show comparable or
+  better tail-latency than MQTT-over-TLS-over-TCP, especially under
+  packet loss and mobile-network handoff conditions.
+- **For low-rate telemetry** (a few KB at minute granularity), the
+  difference between QUIC and TLS-over-TCP is small in steady-state. The
+  win is in connection-establishment cost (~1 RTT vs ~3 RTT) and in
+  graceful behavior across IP changes.
+
+### 5.2 What holds up
+
+The proposal's choice of `quinn` for the Pi-to-cloud ring is sound and
+matches what EMQX, NanoMQ, and Microsoft (MsQuic) are converging on.
+`rustls` is a strong default.
+
+### 5.3 What to reconsider
+
+- **Heartbeat-only deployments don't need QUIC.** If the Pi wakes 2
+  minutes/day to push aggregated features, an MQTT-over-TLS publish on
+  port 8883 is one library, well-supported, and cheaper to operate.
+- **QUIC pays off when bidirectional or large-payload traffic is real.**
+  Model updates, fleet sync, on-demand video — these are the cases
+  where the 1-RTT handshake and connection-migration matter.
+- **Don't terminate QUIC inside the comms MCU.** ESP-IDF has no
+  production QUIC stack; QUIC belongs on the Pi or gateway, not on the
+  MCU.
+
+### 5.4 Primary references
+
+- quinn: [docs.rs/quinn](https://docs.rs/quinn).
+- MQTT-over-QUIC IIoT evaluation: [MDPI Sensors 21:5737](https://www.mdpi.com/1424-8220/21/17/5737).
+- EMQX MQTT trends: [emqx.com 2025 trends](https://www.emqx.com/en/blog/mqtt-trends-for-2025-and-beyond).
+
+---
+
+## 6. LoRa for sensor mesh fallback
+
+### 6.1 What's true in 2026
+
+- **SX1262** — Semtech's mainstream Gen-2 sub-GHz LoRa transceiver,
+  +22 dBm TX, 4.2 mA RX. The default for low-rate, long-range battery
+  applications. Mature ecosystem, low BOM cost, supported by `lora-phy`
+  and most Meshtastic boards.
+- **LR1110** — adds GNSS scan + WiFi scan. Designed for asset-tracking
+  workflows where the device opportunistically reports GNSS+WiFi
+  fingerprints to a cloud-side resolver.
+- **LR1121** — Gen-3, sub-GHz + 2.4 GHz + S/L-band satellite. ~4.5 dB
+  better Sub-GHz sensitivity vs SX1262. Cost premium and more system
+  complexity.
+- **Duty cycles**: EU868 imposes 1% in most sub-bands and 0.1% in the
+  863–865 MHz sub-band. US915 uses dwell-time (400 ms) instead of
+  duty-cycle limits. Raw-LoRa peer-to-peer must still respect the
+  regional regulatory constraint, even though LoRaWAN is not on the
+  wire.
+
+For a 20-byte heartbeat at SF7, BW 125 kHz, the airtime is ~40 ms. At
+the EU868 1% duty cycle, that's 36 s/hour available — more than 900
+heartbeats per hour theoretical max.
+
+### 6.2 What holds up
+
+SX1262 for fallback heartbeats is the correct, well-priced choice. The
+proposal's "bytes per minute" framing is well within EU868 1% and US915
+dwell-time budgets.
+
+### 6.3 What to reconsider
+
+- **LR1121 is not justified for fallback heartbeats.** The
+  satellite/2.4 GHz capabilities are deployment-shape choices, not
+  fallback-radio choices.
+- **Raw LoRa P2P, not LoRaWAN.** The proposal already implies P2P; this
+  should be explicit. LoRaWAN gateways add infrastructure cost without
+  improving fallback reliability, and they don't help direct
+  node-to-node fallback recovery.
+- **LoRa cannot carry CSI features at any meaningful rate.** SF7 BW125
+  raw rate is ~5.5 kbps; ADR-081 `rv_feature_state_t` at 5 Hz is 2.4
+  kbps gross, 480 B/s, well within budget if compressed and gated.
+  Raw ADR-018 frames at 100 KB/s/node are not LoRa-shaped.
+
+### 6.4 Primary references
+
+- Semtech SX1262 datasheet via DigiKey: [forum.digikey.com LoRa breakdown](https://forum.digikey.com/t/lora-hardware-breakdown-key-chips-and-modules-for-iot-applications/52243).
+- LR1121 / SX1262 / LR2021 comparison: [nicerf.com](https://www.nicerf.com/news/lr2021-vs-sx1262-vs-lr1121.html).
+- TTN duty cycle reference: [thethingsnetwork.org](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/).
+- TTN regional EU863-870: [thethingsnetwork.org regional](https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/eu868/).
+
+---
+
+## 7. Solar + Li-ion power-path for 350 mA bursty IoT loads
+
+### 7.1 What's true in 2026
+
+- **TI BQ24074** — small, simple, linear charger; dual input
+  (DC + USB); has the input-voltage-limit feature that crudely
+  approximates MPPT for small panels. Adafruit's "Universal" charger
+  product is built on it. Low silicon cost, no inductors.
+- **TI BQ25798** — newer (2025-class) buck-boost charger with **true
+  Voc-sampling MPPT**, dual-input, supports 1–4S Li-ion, 5 A capability,
+  3.6–24 V input range. Adafruit launched a development module in May
+  2025.
+- **Analog Devices LTC4015** — multi-chemistry, two-phase MPPT (15-min
+  global sweep + 1-second local dither). High-cost, high-capability;
+  overkill for sub-5 W panels.
+- **Silergy SPV1050** — purpose-built for sub-watt IoT solar (e.g.
+  energy-harvesting sensors). Constant-voltage-ratio MPPT, 70 mA solar
+  / 100 mA USB charge limit. Best for *very small* (<1 W) panels and
+  micro-energy budgets.
+
+### 7.2 What holds up
+
+For a 2 W panel and a node-average load that bursts to 350 mA, the
+BQ24074 (linear) is sufficient. The proposal's choice is fine.
+
+### 7.3 What to reconsider
+
+- **MPPT becomes attractive when panel power × variability is high.**
+  At 2 W, the efficiency delta between linear-with-input-voltage-limit
+  and true MPPT is on the order of 10–20% in cloudy conditions. For a
+  4× harvest-to-load headroom, this is not the binding constraint.
+- **If the deployment ever scales to a 5–10 W panel** (e.g., to support
+  a Pi that wakes more often than 2 minutes/day), BQ25798's MPPT pays
+  off.
+- **A super-cap on the input rail** is cheap insurance against the Pi's
+  ~350 mA boot inrush; the proposal should consider one.
+
+### 7.4 Primary references
+
+- BQ25798 launch coverage (Adafruit, May 2025): [blog.adafruit.com](https://blog.adafruit.com/2025/05/15/eye-on-npi-ti-bq25798-i2c-controlled-1-to-4-cell-5-a-buck-boost-battery-charger-mppt-for-solar-panels-eyeonnpi-digikey-digikey-adafruit/).
+- BQ25798 datasheet: [ti.com](https://www.ti.com/lit/ds/symlink/bq25798.pdf).
+- BQ24074 product (Adafruit): [adafruit.com/product/4755](https://www.adafruit.com/product/4755).
+- SPV1050 application reference: [DFRobot wiki](https://wiki.dfrobot.com/dfr0579/).
+
+---
+
+## 8. Mesh routing alternatives to ESP-WIFI-MESH
+
+### 8.1 What's true in 2026
+
+- **ESP-WIFI-MESH** documents support up to ~1,000 nodes in 25 layers,
+  with a recommended fan-out of 6/node (hardware AP-mode limit is 10).
+  Espressif's own newer `esp-mesh-lite` is the lighter, IP-layer-routable
+  alternative.
+- **Thread / OpenThread** — IPv6-native 802.15.4 mesh, self-healing,
+  designed for 250+ node networks per partition. Strong scalability and
+  security story. Hardware: ESP32-C6, ESP32-H2, Nordic nRF52840, Silicon
+  Labs EFR32.
+- **Zigbee** — 802.15.4 like Thread, but with a much older application
+  layer. Scales reasonably to ~100 nodes in practice, with congestion
+  challenges in dense deployments.
+- **BLE Mesh** — managed flooding, optimized for sporadic traffic. Good
+  for ~50 nodes; not the right shape for always-on infrastructure.
+
+### 8.2 What holds up
+
+For < 25-node deployments, ESP-WIFI-MESH (or `esp-mesh-lite`) is the
+direct continuation of today's RuView mesh and the proposal's choice is
+defensible.
+
+### 8.3 What to reconsider
+
+- **For 50–500 node deployments, Thread is the better fit.** It was
+  designed for that scale; ESP-WIFI-MESH was not. Using Thread *for the
+  control plane* (TIME_SYNC, ROLE_ASSIGN, CHANNEL_PLAN, HEALTH) while
+  keeping ADR-018 CSI frames on WiFi is a viable hybrid.
+- **The comms MCU choice changes.** ESP-WIFI-MESH stays on ESP32-S3.
+  Thread/Zigbee/BLE Mesh prefer ESP32-C6 (which has 802.15.4 + WiFi 6)
+  or a separate radio. The proposal's two-S3 die choice forecloses on
+  this hybrid; a one-S3 + one-C6 split is worth evaluating.
+- **Thread's IPv6-native routing pairs nicely with QUIC.** Both speak
+  IP; ESP-WIFI-MESH does not (it uses its own L2-style routing and
+  bridges IP).
+
+### 8.4 Primary references
+
+- ESP-WIFI-MESH overview: [docs.espressif.com](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/esp-wifi-mesh.html).
+- esp-mesh-lite: [github.com/espressif/esp-mesh-lite](https://github.com/espressif/esp-mesh-lite).
+- Silicon Labs benchmarking: [silabs.com mesh-performance](https://www.silabs.com/wireless/multiprotocol/mesh-performance).
+- Bluetooth/Thread/Zigbee comparison: [eetimes.com](https://www.eetimes.com/bluetooth-thread-zigbee-mesh-compared/).
+- Zigbee vs Matter-over-Thread (2026): [arXiv:2603.04221](https://arxiv.org/html/2603.04221v1).
+
+---
+
+## 9. Pi Zero 2W secure-boot reality
+
+### 9.1 What's true in 2026
+
+- **Raspberry Pi Foundation's official secure-boot path is Pi 4 / Pi 5
+  / CM4.** It uses the RPi-bootloader ROM, USB-rooted RSA chain, and
+  the `usbboot` tooling. There is no equivalent on the Pi Zero 2W
+  (BCM2710A1).
+- **Buildroot does support Pi Zero 2W** (April 2025 defconfig update
+  uses the same ARM64 `bcm2711_defconfig` as the Pi 4).
+- **dm-verity + signed FIT image** is the realistic Pi-Zero-2W path:
+  buildroot produces a read-only rootfs, dm-verity covers it with a
+  signed Merkle tree, the boot partition has signed kernel/initramfs.
+  This delivers integrity but not "secure boot" in the immutable-ROM
+  sense.
+- **A/B partitions for OTA** is straightforward in buildroot.
+  `swupdate` and `RAUC` are the well-known frameworks; both work on Pi
+  Zero 2W.
+
+### 9.2 What holds up
+
+The proposal's "buildroot, not Raspberry Pi OS" instinct is correct.
+RPi OS does not support secure boot on any Pi.
+
+### 9.3 What to reconsider
+
+- **The "Pi 4 + buildroot is the strongest path" line is true but not a
+  Pi Zero 2W story.** If true secure boot with an immutable ROM-rooted
+  chain is required, the heavy-compute die should be a CM4 or Pi 5, not
+  a Pi Zero 2W.
+- **For the proposal's deployment shape** (mostly-off Pi, infrequent
+  wake-ups), dm-verity + signed FIT + A/B is probably enough threat
+  cover and avoids the cost of a CM4. Document this as an explicit
+  tradeoff, not as "the strongest path."
+- **`fwupd` is the package-manager-style update agent**; or a
+  self-rolled "update-agent" binary signed by the project key. Either
+  works; project-style fits with the homogeneous Rust toolchain better.
+
+### 9.4 Primary references
+
+- Raspberry Pi USB-boot secure-boot example: [github.com/raspberrypi/usbboot](https://github.com/raspberrypi/usbboot/blob/master/secure-boot-example/README.md).
+- Raspberry Pi forum on secure boot: [forums.raspberrypi.com 352061](https://forums.raspberrypi.com/viewtopic.php?t=352061).
+- Buildroot Pi Zero 2W defconfig (April 2025): [lists.buildroot.org](https://lists.buildroot.org/pipermail/buildroot/2025-April/776753.html).
+
+---
+
+## 10. Cross-cutting takeaways
+
+A short list of items that affect more than one section:
+
+1. **The biggest single risk in the proposal is the no_std CSI maturity
+   gate.** If `esp-csi-rs` (or whatever replaces it under `esp-radio`)
+   does not match `esp_wifi_set_csi_rx_cb` in capture quality and
+   ISR-jitter, the sensor-MCU shape collapses back to "C ESP-IDF on the
+   sensor MCU too" and the value of the split shrinks.
+2. **The cost story improves dramatically if the heavy-compute die is
+   shared across nodes.** "One Pi per cluster of 6" is closer to today's
+   $9-per-sensor BOM at the per-sensor edge while still adding the
+   QUIC/ML/secure-boot story at the cluster level.
+3. **IEEE 802.11bf-2025's ratification** changes the regulatory and
+   ecosystem landscape but does not change what off-the-shelf ESP32
+   silicon can do today. RuView's pre-standard work (ADR-029, ADR-073,
+   ADR-081) is well-aligned with the standard's direction; nothing in
+   the proposal makes it more or less compatible.
+4. **The right "comms MCU" might be ESP32-C6 instead of a second S3.**
+   C6 has 802.15.4 (Thread/Zigbee), WiFi 6, and BLE 5.4. For a
+   deployment that scales beyond ~25 nodes, the Thread control plane is
+   a meaningful upgrade.
+5. **Power gating the Pi is the load-bearing power decision.** Soft
+   suspend leaks; hard FET cut does not. The proposal's instinct is
+   right, but the supercap/transient story has to be designed in.
+
+---
+
+## 11. Items where no primary source was found
+
+This section is required by the project conventions and lists each
+non-trivial claim where a primary source could not be located in this
+research pass:
+
+- **Through-multiple-walls CSI pose accuracy at room scale.** Published
+  papers focus on line-of-sight or single-wall environments. *Mark as
+  conjecture for now.*
+- **WiFlow inference latency on Pi Zero 2W (Cortex-A53).** Estimated at
+  50–100 ms; no measurement found. *Mark as conjecture; benchmark
+  before claiming.*
+- **Espressif silicon roadmap for 802.11bf-aware MAC primitives.** No
+  public announcement from Espressif as of 2026 Q2. *Mark as
+  conjecture.*
+- **Pi Zero 2W gated cold-boot wake-up time under 5 s with the proposed
+  buildroot image.** Mentioned in the proposal as a constraint, no
+  measurement found. *Mark as benchmark target.*
+- **ESP-WIFI-MESH stable-state tested deployment beyond ~25 nodes.**
+  Espressif documents 1,000-node theoretical ceilings but published
+  third-party deployment data at scale is sparse. *Mark as conjecture
+  pending field test.*
+
+---
+
+## 12. Source list
+
+(Primary references are inlined per-section. This is the unique
+domains list for quick reuse.)
+
+- IEEE Standards Association — `standards.ieee.org`
+- arXiv — `arxiv.org`
+- IEEE Xplore — `ieeexplore.ieee.org`
+- Espressif documentation — `docs.espressif.com`
+- Espressif GitHub — `github.com/espressif`
+- esp-rs project — `github.com/esp-rs`, `crates.io/crates/esp-csi-rs`,
+  `docs.rs/esp-idf-hal`
+- Embassy project — `embassy.dev`
+- The Things Network — `thethingsnetwork.org`
+- Texas Instruments — `ti.com`
+- Adafruit — `adafruit.com`, `blog.adafruit.com`
+- Buildroot — `lists.buildroot.org`
+- Silicon Labs — `silabs.com`
+- DigiKey forum — `forum.digikey.com`
+- NIST — `nist.gov`
+- MDPI Sensors — `mdpi.com`
+- EMQ technical blog — `emqx.com`
+- Raspberry Pi forum / GitHub — `forums.raspberrypi.com`,
+  `github.com/raspberrypi/usbboot`
+- nicerf comparison guide — `nicerf.com`
+- DFRobot wiki — `wiki.dfrobot.com`
+
+---
+
+## Sources
+
+- [WiFlow: A Lightweight WiFi-based Continuous Human Pose Estimation Network](https://arxiv.org/html/2602.08661)
+- [Towards Robust and Realistic Human Pose Estimation via WiFi Signals (DT-Pose)](https://arxiv.org/abs/2501.09411)
+- [Graph-based 3D Human Pose Estimation using WiFi Signals (GraphPose-Fi)](https://arxiv.org/abs/2511.19105)
+- [IEEE 802.11bf-2025](https://standards.ieee.org/ieee/802.11bf/11574/)
+- [An Overview on IEEE 802.11bf: WLAN Sensing](https://arxiv.org/pdf/2207.04859)
+- [IEEE 802.11bf NIST page](https://www.nist.gov/publications/ieee-80211bf-enabling-widespread-adoption-wi-fi-sensing)
+- [ISAC-Fi: Enabling Full-Fledged Monostatic Sensing Over Wi-Fi](https://arxiv.org/abs/2408.09851)
+- [Multistatic ISAC Macro–Micro Cooperation](https://www.mdpi.com/1424-8220/24/8/2498)
+- [esp-rs/esp-hal releases](https://github.com/esp-rs/esp-hal/releases)
+- [esp-idf-svc CHANGELOG](https://github.com/esp-rs/esp-idf-svc/blob/master/CHANGELOG.md)
+- [esp-idf-svc Embassy ISR-safety issue #342](https://github.com/esp-rs/esp-idf-svc/issues/342)
+- [esp-csi-rs crate](https://crates.io/crates/esp-csi-rs)
+- [Embassy Book](https://embassy.dev/book/)
+- [esp-tflite-micro](https://github.com/espressif/esp-tflite-micro)
+- [ESP32-S3 TFLite Micro practical guide](https://zediot.com/blog/esp32-s3-tensorflow-lite-micro/)
+- [ESP32-S3 TinyML Optimization](https://zediot.com/blog/esp32-s3-tinyml-optimization/)
+- [quinn QUIC](https://docs.rs/quinn)
+- [MQTT-over-QUIC IIoT evaluation (MDPI)](https://www.mdpi.com/1424-8220/21/17/5737)
+- [MQTT trends for 2025 (EMQ)](https://www.emqx.com/en/blog/mqtt-trends-for-2025-and-beyond)
+- [LoRa SX1262 / LR1121 / LR2021 comparison](https://www.nicerf.com/news/lr2021-vs-sx1262-vs-lr1121.html)
+- [LoRa hardware breakdown (DigiKey)](https://forum.digikey.com/t/lora-hardware-breakdown-key-chips-and-modules-for-iot-applications/52243)
+- [LoRaWAN duty cycle (TTN)](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/)
+- [LoRaWAN regional EU868 (TTN)](https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/eu868/)
+- [BQ25798 launch coverage (Adafruit/DigiKey)](https://blog.adafruit.com/2025/05/15/eye-on-npi-ti-bq25798-i2c-controlled-1-to-4-cell-5-a-buck-boost-battery-charger-mppt-for-solar-panels-eyeonnpi-digikey-digikey-adafruit/)
+- [BQ25798 datasheet](https://www.ti.com/lit/ds/symlink/bq25798.pdf)
+- [BQ24074 product page](https://www.adafruit.com/product/4755)
+- [SPV1050 reference](https://wiki.dfrobot.com/dfr0579/)
+- [ESP-WIFI-MESH guide](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/esp-wifi-mesh.html)
+- [esp-mesh-lite](https://github.com/espressif/esp-mesh-lite)
+- [Silicon Labs mesh benchmarking](https://www.silabs.com/wireless/multiprotocol/mesh-performance)
+- [Bluetooth/Thread/Zigbee comparison (EE Times)](https://www.eetimes.com/bluetooth-thread-zigbee-mesh-compared/)
+- [Zigbee vs Matter-over-Thread (arXiv 2603.04221)](https://arxiv.org/html/2603.04221v1)
+- [Raspberry Pi USB-boot secure-boot example](https://github.com/raspberrypi/usbboot/blob/master/secure-boot-example/README.md)
+- [Raspberry Pi forum: secure boot](https://forums.raspberrypi.com/viewtopic.php?t=352061)
+- [Buildroot Pi Zero 2 W defconfig (April 2025)](https://lists.buildroot.org/pipermail/buildroot/2025-April/776753.html)
+- [Nexmon CSI](https://github.com/seemoo-lab/nexmon_csi)

docs/security-audit-wasm-edge-vendor.md

@@ -2,7 +2,7 @@
 
 **Date**: 2026-03-03
 **Auditor**: Security Auditor Agent (Claude Opus 4.6)
-**Scope**: All 29 `.rs` files in `rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/`
+**Scope**: All 29 `.rs` files in `v2/crates/wifi-densepose-wasm-edge/src/`
 **Crate version**: 0.3.0
 **Target**: `wasm32-unknown-unknown` (ESP32-S3 WASM3 interpreter)
 

docs/tutorials/cognitum-seed-pretraining.md

@@ -909,7 +909,7 @@ For users with the Rust toolchain, the `wifi-densepose-train` crate
 provides the full training pipeline with RuVector integration:
 
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo run -p wifi-densepose-train -- \
   --data pretrain-vectors.rvf \
   --epochs 50 \

docs/user-guide.md

@@ -119,7 +119,7 @@ This prepares the native GTK/WebKit dependencies used by the desktop/Tauri crate
 
 ```bash
 git clone https://github.com/ruvnet/RuView.git
-cd RuView/rust-port/wifi-densepose-rs
+cd RuView/v2
 
 # Build
 cargo build --release
@@ -558,7 +558,7 @@ RuView can generate real-time 3D point clouds by fusing camera depth estimation
 
 ```bash
 # Build the pointcloud binary
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build --release -p wifi-densepose-pointcloud
 
 # Start the server (auto-detects camera + CSI). Loopback-only by default.

docs/wifi-mat-user-guide.md

@@ -92,7 +92,7 @@ sudo apt-get install -y build-essential pkg-config libssl-dev
 ```bash
 # Clone the repository
 git clone https://github.com/ruvnet/wifi-densepose.git
-cd wifi-densepose/rust-port/wifi-densepose-rs
+cd wifi-densepose/v2
 
 # Build the wifi-mat crate
 cargo build --release --package wifi-densepose-mat

examples/happiness-vector/README.md

@@ -159,7 +159,7 @@ The happiness scoring algorithm also exists as a WASM module for on-device execu
 
 ```bash
 # Build the happiness scorer WASM
-cd rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge
+cd v2/crates/wifi-densepose-wasm-edge
 cargo build --bin ghost_hunter --target wasm32-unknown-unknown --release --no-default-features
 
 # Output: target/wasm32-unknown-unknown/release/ghost_hunter.wasm (5.7 KB)
@@ -201,6 +201,6 @@ This system is designed to be privacy-preserving by construction:
 
 - [ADR-065](../../docs/adr/ADR-065-happiness-scoring-seed-bridge.md) — Happiness scoring pipeline architecture
 - [ADR-066](../../docs/adr/ADR-066-esp32-swarm-seed-coordinator.md) — ESP32 swarm with Seed coordinator
-- [exo_happiness_score.rs](../../rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm-edge/src/exo_happiness_score.rs) — WASM edge module (Rust)
+- [exo_happiness_score.rs](../../v2/crates/wifi-densepose-wasm-edge/src/exo_happiness_score.rs) — WASM edge module (Rust)
 - [swarm_bridge.c](../../firmware/esp32-csi-node/main/swarm_bridge.c) — ESP32 firmware swarm bridge
 - [ruview_live.py](../ruview_live.py) — RuView Live dashboard with `--mode happiness`

install.sh

@@ -25,7 +25,7 @@
 set -euo pipefail
 
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-RUST_DIR="${SCRIPT_DIR}/rust-port/wifi-densepose-rs"
+RUST_DIR="${SCRIPT_DIR}/v2"
 
 # ─── Colors ───────────────────────────────────────────────────────────
 if [ -t 1 ]; then
@@ -955,7 +955,7 @@ post_install() {
             ;;
         rust)
             echo "    # Run benchmarks:"
-            echo "    cd rust-port/wifi-densepose-rs"
+            echo "    cd v2"
             echo "    cargo bench --package wifi-densepose-signal"
             echo ""
             echo "    # Start Rust API server:"
@@ -963,7 +963,7 @@ post_install() {
             ;;
         browser)
             echo "    # WASM package is at:"
-            echo "    # rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm/pkg/"
+            echo "    # v2/crates/wifi-densepose-wasm/pkg/"
             echo ""
             echo "    # Open the 3D visualization:"
             echo "    python3 -m http.server 3000 --directory ui"
@@ -999,17 +999,17 @@ post_install() {
             echo "    # WiFi-Mat disaster response module built."
             echo ""
             echo "    # Run WiFi-Mat tests:"
-            echo "    cd rust-port/wifi-densepose-rs"
+            echo "    cd v2"
             echo "    cargo test --package wifi-densepose-mat"
             echo ""
             echo "    # Field deployment WASM package at:"
-            echo "    # rust-port/wifi-densepose-rs/crates/wifi-densepose-wasm/pkg/"
+            echo "    # v2/crates/wifi-densepose-wasm/pkg/"
             ;;
         full)
             echo "    # Verification:  ./verify"
             echo "    # Python API:    uvicorn v1.src.api.main:app --host 0.0.0.0 --port 8000"
-            echo "    # Rust API:      cd rust-port/wifi-densepose-rs && cargo run --release --package wifi-densepose-api"
-            echo "    # Benchmarks:    cd rust-port/wifi-densepose-rs && cargo bench"
+            echo "    # Rust API:      cd v2 && cargo run --release --package wifi-densepose-api"
+            echo "    # Benchmarks:    cd v2 && cargo bench"
             echo "    # Visualization: python3 -m http.server 3000 --directory ui"
             echo "    # Docker:        docker compose up"
             ;;

requirements-dev.txt

@@ -0,0 +1,13 @@
+# Development and testing dependencies
+# Install with: pip install -r requirements.txt -r requirements-dev.txt
+
+# Testing
+pytest>=7.0.0
+pytest-asyncio>=0.21.0
+pytest-mock>=3.10.0
+pytest-benchmark>=4.0.0
+
+# Linting and formatting
+black>=23.0.0
+flake8>=6.0.0
+mypy>=1.0.0

requirements.txt

@@ -4,14 +4,6 @@ scipy>=1.7.0
 torch>=1.12.0
 torchvision>=0.13.0
 
-# Testing dependencies
-pytest>=7.0.0
-pytest-asyncio>=0.21.0
-pytest-mock>=3.10.0
-pytest-benchmark>=4.0.0
-httpx>=0.24.0
-pydantic-settings>=2.0.0
-
 # API dependencies
 fastapi>=0.95.0
 uvicorn>=0.20.0
@@ -20,6 +12,8 @@ pydantic>=1.10.0
 python-jose[cryptography]>=3.3.0
 python-multipart>=0.0.6
 passlib[bcrypt]>=1.7.4
+httpx>=0.24.0
+pydantic-settings>=2.0.0
 
 # Database dependencies
 sqlalchemy>=2.0.0
@@ -42,8 +36,3 @@ scikit-learn>=1.2.0
 
 # Monitoring dependencies
 prometheus-client>=0.16.0
-
-# Development dependencies
-black>=23.0.0
-flake8>=6.0.0
-mypy>=1.0.0

rust-port/wifi-densepose-rs/.claude-flow/daemon.pid

@@ -1 +0,0 @@
-26601

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/.claude-flow/data/pending-insights.jsonl

@@ -1,42 +0,0 @@
-{"type":"edit","file":"unknown","timestamp":1773100520674,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100630628,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100635269,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100648222,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100660593,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100670480,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100765961,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100793408,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100801110,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100806887,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100820942,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100857691,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100894224,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773100911798,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773101430507,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773101470221,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773101478246,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773103575668,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773103693989,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115108388,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115362485,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115372676,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115388605,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115394377,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115415015,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773115600459,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146102258,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146113449,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146119695,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146128174,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146133721,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146150082,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773146337071,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150581963,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150596765,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773152997925,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153073387,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153109436,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153121443,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153290476,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153290781,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773153291056,"sessionId":null}

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/.claude-flow/sessions/current.json

@@ -1,12 +0,0 @@
-{
-  "id": "session-1773150558480",
-  "startedAt": "2026-03-10T13:49:18.480Z",
-  "cwd": "/Users/cohen/GitHub/ruvnet/RuView/rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop",
-  "context": {},
-  "metrics": {
-    "edits": 9,
-    "commands": 0,
-    "tasks": 0,
-    "errors": 0
-  }
-}

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/.claude-flow/sessions/session-1773100562538.json

@@ -1,14 +0,0 @@
-{
-  "id": "session-1773100562538",
-  "startedAt": "2026-03-09T23:56:02.538Z",
-  "cwd": "/Users/cohen/GitHub/ruvnet/RuView/rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop",
-  "context": {},
-  "metrics": {
-    "edits": 13,
-    "commands": 0,
-    "tasks": 0,
-    "errors": 0
-  },
-  "endedAt": "2026-03-10T00:07:15.557Z",
-  "duration": 673020
-}

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/.claude-flow/sessions/session-1773101285009.json

@@ -1,14 +0,0 @@
-{
-  "id": "session-1773101285009",
-  "startedAt": "2026-03-10T00:08:05.009Z",
-  "cwd": "/Users/cohen/GitHub/ruvnet/RuView/rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop",
-  "context": {},
-  "metrics": {
-    "edits": 19,
-    "commands": 0,
-    "tasks": 0,
-    "errors": 0
-  },
-  "endedAt": "2026-03-10T13:48:30.150Z",
-  "duration": 49225141
-}

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui/.claude-flow/data/pending-insights.jsonl

@@ -1,28 +0,0 @@
-{"type":"edit","file":"unknown","timestamp":1772835768740,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835786050,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835802335,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835865846,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835875824,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835892636,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835909237,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835921184,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835930809,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835942468,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1772835952451,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773070971487,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773070977376,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773101503481,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773107530083,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773107530201,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773107530319,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773114830434,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773114834713,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773114838852,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150617007,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150621430,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150628006,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150640909,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150672276,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150677219,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150683839,"sessionId":null}
-{"type":"edit","file":"unknown","timestamp":1773150688912,"sessionId":null}

rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui/.claude-flow/sessions/current.json

@@ -1,12 +0,0 @@
-{
-  "id": "session-1773103750755",
-  "startedAt": "2026-03-10T00:49:10.755Z",
-  "cwd": "/Users/cohen/GitHub/ruvnet/RuView/rust-port/wifi-densepose-rs/crates/wifi-densepose-desktop/ui",
-  "context": {},
-  "metrics": {
-    "edits": 14,
-    "commands": 0,
-    "tasks": 0,
-    "errors": 0
-  }
-}

scripts/gcloud-train.sh

@@ -263,7 +263,7 @@ export LIBTORCH=\$(python3 -c "import torch; print(torch.__path__[0] + '/lib')")
 export LD_LIBRARY_PATH="\${LIBTORCH}:\${LD_LIBRARY_PATH:-}"
 
 # Build the training binary with tch-backend
-cd ~/wifi-densepose/rust-port/wifi-densepose-rs
+cd ~/wifi-densepose/v2
 echo "Building with LIBTORCH=\$LIBTORCH ..."
 cargo build --release --features tch-backend --bin train 2>&1 | tail -5
 
@@ -325,7 +325,7 @@ set -euo pipefail
 source \$HOME/.cargo/env
 export LIBTORCH=\$(python3 -c \"import torch; print(torch.__path__[0] + '/lib')\")
 export LD_LIBRARY_PATH=\"\${LIBTORCH}:\${LD_LIBRARY_PATH:-}\"
-cd ~/wifi-densepose/rust-port/wifi-densepose-rs
+cd ~/wifi-densepose/v2
 
 # Set auto-shutdown timer (safety net)
 sudo shutdown -P +$((MAX_HOURS * 60)) &
@@ -408,7 +408,7 @@ mkdir -p "$LOCAL_RESULTS"
 
 # Package results on the VM
 gcloud compute ssh "$INSTANCE_NAME" --zone="$ZONE" --command="
-cd ~/wifi-densepose/rust-port/wifi-densepose-rs
+cd ~/wifi-densepose/v2
 tar czf ~/training-artifacts.tar.gz \
     checkpoints/ \
     logs/ \

scripts/generate-witness-bundle.sh

@@ -60,7 +60,7 @@ with open('$BUNDLE_DIR/proof/reference_signal_metadata.json', 'w') as f:
 # ---------------------------------------------------------------
 echo "[3/7] Running Rust test suite..."
 mkdir -p "$BUNDLE_DIR/test-results"
-cd "$REPO_ROOT/rust-port/wifi-densepose-rs"
+cd "$REPO_ROOT/v2"
 cargo test --workspace --no-default-features 2>&1 | tee "$BUNDLE_DIR/test-results/rust-workspace-tests.log" | tail -5
 # Extract summary
 grep "^test result" "$BUNDLE_DIR/test-results/rust-workspace-tests.log" | \
@@ -98,7 +98,7 @@ fi
 # ---------------------------------------------------------------
 echo "[6/7] Generating crate manifest..."
 mkdir -p "$BUNDLE_DIR/crate-manifest"
-for crate_dir in "$REPO_ROOT/rust-port/wifi-densepose-rs/crates/"*/; do
+for crate_dir in "$REPO_ROOT/v2/crates/"*/; do
   crate_name="$(basename "$crate_dir")"
   if [ -f "$crate_dir/Cargo.toml" ]; then
     version=$(grep '^version' "$crate_dir/Cargo.toml" | head -1 | sed 's/.*"\(.*\)".*/\1/')

scripts/qemu-mesh-test.sh

@@ -82,7 +82,7 @@ PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
 
 FIRMWARE_DIR="$PROJECT_ROOT/firmware/esp32-csi-node"
 BUILD_DIR="$FIRMWARE_DIR/build"
-RUST_DIR="$PROJECT_ROOT/rust-port/wifi-densepose-rs"
+RUST_DIR="$PROJECT_ROOT/v2"
 PROVISION_SCRIPT="$FIRMWARE_DIR/provision.py"
 VALIDATE_SCRIPT="$SCRIPT_DIR/validate_mesh_test.py"
 

scripts/qemu_swarm.py

@@ -46,7 +46,7 @@ except ImportError:
 SCRIPT_DIR = Path(__file__).resolve().parent
 PROJECT_ROOT = SCRIPT_DIR.parent
 FIRMWARE_DIR = PROJECT_ROOT / "firmware" / "esp32-csi-node"
-RUST_DIR = PROJECT_ROOT / "rust-port" / "wifi-densepose-rs"
+RUST_DIR = PROJECT_ROOT / "v2" / "wifi-densepose-rs"
 PROVISION_SCRIPT = FIRMWARE_DIR / "provision.py"
 PRESETS_DIR = SCRIPT_DIR / "swarm_presets"
 

ui/README.md

@@ -125,7 +125,7 @@ Open http://localhost:3000/ui/index.html
 
 ### With local Rust binary
 ```bash
-cd rust-port/wifi-densepose-rs
+cd v2
 cargo build -p wifi-densepose-sensing-server --no-default-features
 
 # Run with simulated data

v1/README.md

@@ -51,4 +51,4 @@ pytest tests/
 
 ## Note
 
-This is the legacy Python implementation. For the new Rust implementation with improved performance, see `/rust-port/wifi-densepose-rs/`.
+This is the legacy Python implementation. For the new Rust implementation with improved performance, see `/v2/`.

v2/.claude-flow/daemon-state.json

@@ -64,8 +64,8 @@
   },
   "config": {
     "autoStart": false,
-    "logDir": "/home/user/wifi-densepose/rust-port/wifi-densepose-rs/.claude-flow/logs",
-    "stateFile": "/home/user/wifi-densepose/rust-port/wifi-densepose-rs/.claude-flow/daemon-state.json",
+    "logDir": "/home/user/wifi-densepose/v2/.claude-flow/logs",
+    "stateFile": "/home/user/wifi-densepose/v2/.claude-flow/daemon-state.json",
     "maxConcurrent": 2,
     "workerTimeoutMs": 300000,
     "resourceThresholds": {

v2/.claude-flow/metrics/codebase-map.json

@@ -1,6 +1,6 @@
 {
   "timestamp": "2026-02-28T14:40:51.151Z",
-  "projectRoot": "/home/user/wifi-densepose/rust-port/wifi-densepose-rs",
+  "projectRoot": "/home/user/wifi-densepose/v2",
   "structure": {
     "hasPackageJson": false,
     "hasTsConfig": false,

v2/Cargo.lock

@@ -7979,6 +7979,7 @@ dependencies = [
  "chrono",
  "clap",
  "futures-util",
+ "ruvector-mincut",
  "serde",
  "serde_json",
  "tempfile",

v2/crates/README.md

@@ -213,7 +213,7 @@ cargo run -p wifi-densepose-train --features tch-backend --bin verify-training
 ```bash
 # Clone the repository
 git clone https://github.com/ruvnet/wifi-densepose.git
-cd wifi-densepose/rust-port/wifi-densepose-rs
+cd wifi-densepose/v2
 
 # Check workspace (no GPU dependencies)
 cargo check --workspace --no-default-features

v2/crates/ruv-neural/README.md

@@ -214,7 +214,7 @@ All crates are published on [crates.io](https://crates.io/search?q=ruv-neural):
 ### Build
 
 ```bash
-cd rust-port/wifi-densepose-rs/crates/ruv-neural
+cd v2/crates/ruv-neural
 cargo build --workspace
 cargo test --workspace
 ```