#864 — Docker no longer exposes the sensing API/stream unauthenticated:
- Add `require_ws_token` middleware gating `/ws/*` (sensing + introspection)
with the API token via `?token=` (browser) or `Authorization: Bearer`
(programmatic). Previously /ws/sensing was ungated even with a token set.
- docker-entrypoint.sh now fails closed: auto-generates a strong
RUVIEW_API_TOKEN when none is supplied and prints it; explicit
RUVIEW_ALLOW_UNAUTHENTICATED=1 restores the open LAN posture.
- compose/Dockerfile wire the env vars; startup logs + CI smoke test updated
to assert secure-by-default (401 with no token) and the opt-out path.
- 7 new bearer_auth unit tests (15 total pass).
#866 — CSI callbacks were starving (~3 in 70s, 0pps) under the MGMT-only
promiscuous filter:
- The documented "10 Hz probe injection" never existed — implement it for
real (csi_inject_probe_request + 10 Hz timer). Validated on ESP32-C6 (COM9):
probe TX succeeds at 10 Hz, but management-frame CSI stays sparse.
- Re-admit DATA frames (MGMT+DATA) now that the original wDev_ProcessFiq
SPI-cache crash is mitigated by WiFi RX/TX IRAM opts + the existing 50 Hz
rate gate. Kconfig CSI_PROMISC_MGMT_ONLY falls back if needed.
- Hardware-validated on COM9: yield 0 -> ~9pps avg (peak 19), presence/motion
sensing restored, 0 panics over 35s.
Co-Authored-By: claude-flow <ruv@ruv.net>
The HOMECORE native Rust port of Home Assistant landed in v0.10.0
(PR #800). The published Docker image now ships its binary alongside
sensing-server and cog-ha-matter so a single `docker run` brings up
the full RuView + HA-wire-compatible stack.
Dockerfile.rust:
- cargo build --release -p homecore-server in the build stage
- strip the new binary
- copy /app/homecore-server in the runtime stage
- sanity-check: image build now fails if /app/homecore-server isn't
executable (same guard pattern that already covers sensing-server
and cog-ha-matter)
- EXPOSE 8123 (HA-compat REST + WebSocket port — homecore-api
binds 0.0.0.0:8123 by default per its --bind CLI flag)
docker-entrypoint.sh:
- new dispatch keyword: `homecore` or `homecore-server`
Usage: docker run --network host ruvnet/wifi-densepose:latest homecore
Defaults --bind to 0.0.0.0:8123 (overridable via HOMECORE_BIND env)
The existing two dispatch paths (no arg → sensing-server, `cog-ha-matter`
→ HA + Matter cog) keep working unchanged. Three-binary image, one
entrypoint, operator picks the role at run time.
Triggers a workflow rebuild on push to main per the docker workflow's
path filter; the multi-arch (amd64 + arm64) image will be published
to Docker Hub as `ruvnet/wifi-densepose:latest` after CI green.
Refs ADRs 126-134, v0.10.0 release.
Co-Authored-By: claude-flow <ruv@ruv.net>
Three changes:
1. Dockerfile.rust now builds sensing-server with `--features mqtt`
(ADR-115 HA-DISCO publisher) and also builds + ships the
cog-ha-matter binary (ADR-116 Home Assistant + Matter cog with
mDNS, embedded broker, RuVector-backed thresholds, Ed25519 witness).
Adds EXPOSE 1883 for the embedded MQTT broker.
2. docker-entrypoint.sh routes `docker run <image> cog-ha-matter ...`
(or `ha-matter`) to /app/cog-ha-matter, defaulting --sensing-url to
http://127.0.0.1:3000 so a docker-compose deployment works out of
the box. The default entrypoint (no first arg) still launches
sensing-server unchanged.
3. Workflow path filter now also fires on changes to
v2/crates/wifi-densepose-bfld/** and v2/crates/cog-ha-matter/**
so future iteration on those crates rebuilds the image.
DOCKERHUB_TOKEN rotated separately (was expired since 2026-05-13,
which is why the last 5 workflow runs failed at the Docker Hub login
step and `latest` on Docker Hub has stayed amd64-only despite #631
being merged). With this commit + rotated token, the next CI run
should land a multi-arch `:latest` with HA-DISCO + cog-ha-matter +
BFLD support.
Reproduced kutayozdur's pull failure on ruv-mac-mini (Apple Silicon,
Darwin arm64) via Tailscale before fixing.
Refs #794, #631, ADR-115, ADR-116, ADR-118.
Co-Authored-By: claude-flow <ruv@ruv.net>
Closes#520, #514, #443.
## #520 / #514 — stale Docker image, missing UI assets
`ruvnet/wifi-densepose:latest` was published before `ui/observatory*` and
`ui/pose-fusion*` were added; users see /app/ui missing those files and the
v0.6+ packet format doesn't reach the server. Two fixes:
1. `docker/Dockerfile.rust` now `RUN`s a build-time guard after `COPY ui/`
that fails the build if `index.html` / `observatory.html` / `pose-fusion.html`
/ `viz.html` (or the `observatory/` / `pose-fusion/` / `components/` /
`services/` directories) are missing, plus an exec-bit check on
`/app/sensing-server`. A stale image can never be silently produced again.
2. New `.github/workflows/sensing-server-docker.yml` rebuilds + pushes on
every change to the Dockerfile, the server crate, the signal/vitals/
wifiscan crates, the workspace manifests, the `ui/` tree, or itself —
plus `v*` tags and manual dispatch. Pushes to both `docker.io/ruvnet/
wifi-densepose` AND `ghcr.io/ruvnet/wifi-densepose` with `latest` +
`vX.Y.Z` + `sha-<short>` tags, then post-push smoke-tests the artifact:
/health, /api/v1/info, the observatory + pose-fusion HTML, AND the
bearer-auth path (no token → 401, wrong → 401, correct → 200). Uses the
`DOCKERHUB_USERNAME`/`DOCKERHUB_TOKEN` repo secrets; ghcr.io rides on
the workflow's GITHUB_TOKEN.
## #443 — sensing-server REST API auth model
QE security audit raised that 40+ /api/v1/* routes have no auth layer with
a default `0.0.0.0` bind. New `wifi_densepose_sensing_server::bearer_auth`
module + middleware:
- Env-var-gated: `RUVIEW_API_TOKEN` unset/empty ⇒ middleware is a no-op
(current LAN-mode behaviour preserved — **no default change**); set ⇒
every `/api/v1/*` request must carry `Authorization: Bearer <token>`
or the server returns 401.
- Constant-time byte compare via local `ct_eq` (no new dep).
- `/health*`, `/ws/sensing`, and `/ui/*` are intentionally never gated
(orchestrator probes + local browsers).
- Startup logs which mode is active and warns when auth is ON with a
`0.0.0.0` bind.
- 8 unit tests on the middleware via `tower::ServiceExt::oneshot`
(sensing-server lib tests 191 → 199, 0 failures).
Verified locally: `cargo build --workspace --no-default-features` ✓,
`cargo test -p wifi-densepose-sensing-server --no-default-features` ✓.
Co-Authored-By: claude-flow <ruv@ruv.net>
The Rust port lived two directories deep (rust-port/wifi-densepose-rs/)
without any sibling under rust-port/ that warranted the extra level.
Move the whole workspace up to v2/ to match v1/ (Python) at the same
depth and shorten every cd / build command across the repo.
git mv preserves history for all tracked files. 60 files updated for
path references (CI workflows, ADRs, docs, scripts, READMEs, internal
.claude-flow state). Two manual fixes for relative-cd paths in
CLAUDE.md and ADR-043 that became wrong after the depth change
(cd ../.. → cd ..).
Validated:
- cargo check --workspace --no-default-features → clean (after target/
nuke; the gitignored target/ was carried by the OS rename and had
hard-coded old paths in build scripts)
- cargo test --workspace --no-default-features → 1,539 passed, 0 failed,
8 ignored (same totals as pre-rename)
- ESP32-S3 on COM7 → still streaming live CSI (cb #40300, RSSI -64 dBm)
After-merge follow-up: contributors should `rm -rf v2/target` once and
let cargo regenerate from the new path.
Fixes#384: docker run with --source/--tick-ms flags now works correctly.
Fixes#399: model files in mounted volumes are now discoverable via MODELS_DIR env var.
Root cause (issue #384):
The Dockerfile used ENTRYPOINT ["/bin/sh", "-c"] with a shell-form CMD.
When users passed flags like `--source wifi --tick-ms 500` as docker run
arguments, Docker replaced CMD entirely, resulting in
`/bin/sh -c "--source wifi --tick-ms 500"` which executes `--source` as
a shell command → `--source: not found`.
Root cause (issue #399):
Model directory was hardcoded to the relative path `data/models`. When Docker
users mounted models to `/app/models/`, the scan looked in the wrong place.
Changes:
1. docker/docker-entrypoint.sh (new):
- Proper entrypoint script that handles both env-var-based defaults and
user-passed CLI flags
- No arguments → starts server with CSI_SOURCE env var as --source
- Flag arguments (start with -) → prepends /app/sensing-server + defaults,
appends user flags (clap last-wins allows overrides)
- Non-flag first arg → exec passthrough (e.g., /bin/sh for debugging)
- Sets --bind-addr 0.0.0.0 (was 127.0.0.1 which blocks container access)
2. docker/Dockerfile.rust:
- Switch from ENTRYPOINT ["/bin/sh", "-c"] to exec-form entrypoint
- Add MODELS_DIR env var (default: data/models)
- COPY the entrypoint script into the image
3. docker/docker-compose.yml:
- Remove shell-form command (entrypoint handles defaults)
- Add MODELS_DIR env var
4. model_manager.rs + main.rs:
- Replace hardcoded `data/models` path with `effective_models_dir()`
/ `models_dir()` that reads MODELS_DIR env var at runtime
- Docker users can now: docker run -v /host/models:/app/models -e MODELS_DIR=/app/models
5. tests/test_docker_entrypoint.sh (new, 17 tests):
- Default CSI_SOURCE substitution (6 assertions)
- Custom CSI_SOURCE propagation
- User-passed flag arguments (--source, --tick-ms, --model)
- Unset CSI_SOURCE defaults to auto
- Explicit command passthrough
- MODELS_DIR env var propagation
- Docker default changed from --source simulated to --source auto
(auto-detects ESP32 on UDP 5005, falls back to simulation)
- Pose derivation now driven by real sensing features: motion_band_power,
breathing_band_power, variance, dominant_freq_hz, change_points
- Temporal feature extraction: 100-frame circular buffer, Goertzel
breathing rate estimation (0.1-0.5 Hz), frame-to-frame L2 motion
detection, SNR-based signal quality metric
- Signal field driven by subcarrier variance spatial mapping instead
of fixed animation circle
- UI data source indicators: LIVE/RECONNECTING/SIMULATED banner on
sensing tab, estimation mode badge on live demo tab
- Setup guide panel explaining ESP32 count requirements for each
capability level (1x: presence, 3x: localization, 4x+: full pose)
- Tick rate improved from 500ms to 100ms (2fps to 10fps)
- Fixed Option<f64> division bug from PR #83
- ADR-035 documents all decisions
Closes#86
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>
- 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>
ruv
voidborne-d