Question set on deploying WiFi-CSI pose/vitals on 2.4GHz ESP32-S3

Question set on deploying WiFi-CSI pose/vitals on 2.4GHz ESP32-S3

Hi ruv — first, genuinely excellent work on the RuView stack. I've been
evaluating it for a production 2.4GHz ESP32-S3 deployment (elderly-care
in-room monitoring) and hit a few walls I'd like your guidance on.

My setup (measured, not imagined):

• 4× ESP32-S3 (flash v0.8.4, self-built sdkconfig.defaults.devkitc — the
  release_bins v0.6.7 display build collapses CSI yield to 0 pps on
  display-less DevKitC, so I compiled the display-free firmware)
• edge_tier=2 dual-stream (raw CSI 0xC5110001 + feature vector 0xC5110003 +
  feature state 0xC5110006 + ESP-NOW sync 0xC511A110 all flowing)
• sensing-server (Rust), UDP via host relay (Windows Docker multi-source-UDP
  fold blunts all-but-one node otherwise)

Q1 — mmfi-pose on 2.4GHz ESP32-S3:

• mmfi-pose (82.69% torso-PCK@20) trains on
  3×3 MIMO NIC). Your doc lists ESP32-S3 as the production hardware, but it
  only captures 2.4GHz CSI (HT-only, 64/128/
• Does mmfi-pose (or its edge/micro variant) have any 2.4GHz-compatible
  path on the S3? Or is there simply no in
  on an ESP32-S3 today? If not, is the intended 2.4G pose route the
  camera-supervised `train-wiflow-superviseding
  that it's JS-format (no JSON→RVF bridge, per user-guide §Model-format-boundary)?

Q2 — ADR-027 MERIDIAN / 10-second auto-calibration LoRA: completion status:

• ADR-027 describes a 10-second automatic ca
  environment-specific LoRA weights (zero-shot adaptation via contrastive
  TTT). The FAQ and user-guide both cite it
  Status: Proposed, and I can't find the runtime path that actually ingests
  ~200 unlabeled frames → trains a LoRA → an
  inference.
• What I found in code: engine::AdapterInfo trained_samples (a provenance tag, appended to the witness chain) — it does **not** hold LoRA delta weights or /api/v1/models/lora/activate only loads a pre-existing data/models/*.lora.json.
• So: is the few-shot LoRA calibration (sher
  room → generate+apply a per-room LoRA) fully implemented end-to-end, or
  is it still Pending (ADR-079 P9)? If Pendi
  near-term way to adapt a base model to a new room on 2.4GHz?

Q3 — multistatic fusion on S3 without ESP-NOW mesh sync:

• I found the fuser used each node's *host-a
  timestamp, so my unsynchronized S3 fleet's timestamps were unboundedly
  skewing (hundreds of ms → seconds) and fusode.
  I wired the ESP-NOW sync packet (0xC511A110) into node_frame_from_state
  (mesh-aligned timestamp + one-basis-per-ba
  dropped fusion errors to ~0 at an 800ms guard.
• Two-part check: (a) does this match your i
  (consume 0xC511A110 → mesh-aligned timestamp → fuse), or did I
  mis-read it? (b) Is ~800ms the expected gu
  fleet (residual from seq→time fps estimation), or should it be tighter
  (i.e. is there a real time-sync path I'm m

Happy to open individual issues / PR for anyr
building this.

Compare ADR-027 and ADR-079 P9 with the runtime paths around engine::AdapterInfo and /api/v1/models/lora/activate, then check the user-guide model-format boundary for the 2.4GHz pose path. Trace node_frame_from_state and the 0xC511A110 packet handling to verify mesh-aligned timestamps and the fusion guard. Done means answering the three implementation-status and timing questions with evidence from the documented and existing paths.