Add native macOS LiDAR / WiFi sensing support via CoreWLAN:
- mac_wifi.swift: Swift helper to poll RSSI/Noise at 10Hz
- MacosWifiCollector: Python adapter for the sensing pipeline
- Auto-detect Darwin platform in ws_server.py
Rewrites CHANGELOG.md with detailed entries for every significant
feature, fix, and security patch across all three major versions:
- v3.0.0: AETHER contrastive embedding model (ADR-024), Docker Hub
images, UI port auto-detection fix, Mermaid architecture diagrams,
33 use cases across 4 verticals
- v2.0.0: Rust sensing server, DensePose training pipeline (ADR-023),
RuVector v2.0.4 integration (ADR-016/017), ESP32-S3 firmware
(ADR-018), SOTA signal processing (ADR-014), vital sign detection
(ADR-021), WiFi-Mat disaster module, 7 security patches, Python
sensing pipeline, Three.js visualization
- v1.1.0: Python CSI system, API services, UI dark mode
- v1.0.0: Initial release with core pose estimation
All entries reference specific commit hashes for traceability.
Co-Authored-By: claude-flow <ruv@ruv.net>
- Introduced ADR-025 documenting the implementation of a macOS CoreWLAN sensing adapter using a Swift helper binary and Rust integration.
- Added a new user guide detailing installation, usage, and hardware setup for WiFi DensePose, including Docker and source build instructions.
- Included sections on data sources, REST API reference, WebSocket streaming, and vital sign detection.
- Documented hardware requirements and troubleshooting steps for various setups.
The UI had hardcoded localhost:8080 for HTTP and localhost:8765 for
WebSocket, causing "Backend unavailable" when served from Docker
(port 3000) or any non-default port.
Changes:
- api.config.js: BASE_URL now uses window.location.origin instead
of hardcoded localhost:8080
- api.config.js: buildWsUrl() uses window.location.host instead of
hardcoded localhost:8080
- sensing.service.js: WebSocket URL derived from page origin instead
of hardcoded localhost:8765
- main.rs: Added /ws/sensing route to the HTTP server so WebSocket
and REST are reachable on a single port
Fixes#55
Co-Authored-By: claude-flow <ruv@ruv.net>
Reframe the ADR-024 section header to emphasize AI self-learning and
adaptive optimization rather than technical CSI embedding terminology.
Co-Authored-By: claude-flow <ruv@ruv.net>
The sensing server defaults to HTTP :8080 and WS :8765, but Docker
exposes :3000/:3001. Added --http-port 3000 --ws-port 3001 to CMD
in both Dockerfile.rust and docker-compose.yml.
Verified both images build and run:
- Rust: 133 MB, all endpoints responding (health, sensing/latest,
vital-signs, pose/current, info, model/info, UI)
- Python: 569 MB, all packages importable (websockets, fastapi)
- RVF file: 13 KB, valid RVFS magic bytes
Also fixed README Quick Start endpoints to match actual routes:
- /api/v1/health → /health
- /api/v1/sensing → /api/v1/sensing/latest
- Added /api/v1/pose/current and /api/v1/info examples
- Added port mapping note for Docker vs local dev
Co-Authored-By: claude-flow <ruv@ruv.net>
- ToC: Add ruvector GitHub link and integration point count
- RVF Container: Add deployment targets table (ESP32 0.7MB to server
50MB), link to rvf crate family on GitHub
- Training: Add RuVector column to pipeline table showing which crate
powers each phase, add SONA component breakdown table, link arXiv
- RuVector Crates: Split into 5 directly-used (with integration
points mapped to exact .rs files) and 6 additional vendored, add
crates.io and GitHub source links for all 11
Co-Authored-By: claude-flow <ruv@ruv.net>
Add collapsible Use Cases & Applications section organized from
practical (elderly care, hospitals, retail) to specialized (events,
warehouses) to extreme (search & rescue, through-wall). Includes
hardware requirements and scaling notes per category.
Fix multi-person description to reflect reality: no hard software
limit, practical ceiling is signal physics (~3-5 per AP at 56
subcarriers, linear scaling with multi-AP).
Co-Authored-By: claude-flow <ruv@ruv.net>
The 10-person limit is just the default setting (pose_max_persons=10).
The API accepts 1-50, docs show configs up to 50, and Rust uses Option<u8>.
Co-Authored-By: claude-flow <ruv@ruv.net>
Promotes Installation and Quick Start to top-level sections placed
between Key Features and Table of Contents for faster onboarding.
Co-Authored-By: claude-flow <ruv@ruv.net>
Consumer WiFi does not expose Channel State Information — clarify that
pose estimation, vital signs, and through-wall sensing require ESP32-S3
or a research NIC. Added Full CSI column to hardware options table.
Co-Authored-By: claude-flow <ruv@ruv.net>
- Snapshot best-epoch weights during training and restore before
checkpoint/RVF export (prevents exporting overfit final-epoch params)
- Add CsiToPoseTransformer::zeros() for fast zero-init when weights
will be overwritten, avoiding wasteful Xavier init during gradient
estimation (~2*param_count transformer constructions per batch)
- Deduplicate synthetic data generation in main.rs training mode
Co-Authored-By: claude-flow <ruv@ruv.net>
- Add docker/ folder with Dockerfile.rust (132MB), Dockerfile.python (569MB),
and docker-compose.yml
- Remove stale root-level Dockerfile and docker-compose files
- Implement --export-rvf CLI flag for standalone RVF package generation
- Generate wifi-densepose-v1.rvf (13KB) with model weights, vital config,
SONA profile, and training provenance
- Update README with Docker pull/run commands and RVF export instructions
- Update test count to 542+ and fix Docker port mappings
- Reply to issues #43, #44, #45 with Docker/RVF availability
Co-Authored-By: claude-flow <ruv@ruv.net>
process.env does not exist in vanilla browser ES modules (no bundler).
Use window.location.protocol check only for WSS detection.
Co-Authored-By: claude-flow <ruv@ruv.net>
Replace Python FastAPI + WebSocket servers with a single 2.1MB Rust binary
(wifi-densepose-sensing-server) that serves all UI endpoints:
- REST: /health/*, /api/v1/info, /api/v1/pose/current, /api/v1/pose/stats,
/api/v1/pose/zones/summary, /api/v1/stream/status
- WebSocket: /api/v1/stream/pose (pose_data with 17 COCO keypoints),
/ws/sensing (raw sensing_update stream on port 8765)
- Static: /ui/* with no-cache headers
WiFi-derived pose estimation: derive_pose_from_sensing() generates 17 COCO
keypoints from CSI/WiFi signal data with motion-driven animation.
Data sources: ESP32 CSI via UDP :5005, Windows WiFi via netsh, simulation
fallback. Auto-detection probes each in order.
UI changes:
- Point all endpoints to Rust server on :8080 (was Python :8000)
- Fix WebSocket sensing URL to include /ws/sensing path
- Remove sensingOnlyMode gating — all tabs init normally
- Remove api.service.js sensing-only short-circuit
- Fix clearPingInterval bug in websocket.service.js
Also removes obsolete k8s/ template manifests.
Co-Authored-By: claude-flow <ruv@ruv.net>
- Use environment variables instead of direct interpolation
- Prevent shell injection through github context data
- Follow GitHub security best practices
- Add table name whitelist validation in status.py
- Use SQLAlchemy ORM instead of raw SQL queries
- Replace string formatting with parameterized queries in migrations
- Add input validation for table names in migration scripts
- Add Python WebSocket sensing server (ws_server.py) with ESP32 UDP CSI
and Windows RSSI auto-detect collectors on port 8765
- Add Three.js Gaussian splat renderer with custom GLSL shaders for
real-time WiFi signal field visualization (blue→green→red gradient)
- Add SensingTab component with RSSI sparkline, feature meters, and
motion classification badge
- Add sensing.service.js WebSocket client with reconnect and simulation fallback
- Implement sensing-only mode: suppress all DensePose API calls when
FastAPI backend (port 8000) is not running, clean console output
- ADR-019: Document sensing-only UI architecture and data flow
- ADR-020: Migrate AI/model inference to Rust with RuVector ONNX Runtime,
replacing ~2.7GB Python stack with ~50MB static binary
- Add ruvnet/ruvector as upstream remote for RuVector crate ecosystem
Co-Authored-By: claude-flow <ruv@ruv.net>
Update ESP32 section with download-flash-provision workflow that
requires no build toolchain. Links to release v0.1.0-esp32 and
tutorial issue #34.
Co-Authored-By: claude-flow <ruv@ruv.net>
ADR-012 now reflects the actual working firmware: NVS runtime config,
Docker build workflow, pre-built binary release, and verified metrics
(20 Hz, zero frame loss). Status changed from Proposed to Accepted.
Co-Authored-By: claude-flow <ruv@ruv.net>
The source code was moved to v1/src/ but the Dockerfile still
referenced src/ directly, causing build failures. Updated all
COPY paths, uvicorn module paths, test paths, and bandit scan
paths. Also added missing v1/__init__.py for Python module
resolution.
Fixes#33
Co-Authored-By: claude-flow <ruv@ruv.net>
The IoT profile now shows the actual Docker build + esptool flash +
aggregator binary workflow that was validated on real hardware.
Co-Authored-By: claude-flow <ruv@ruv.net>
