mirror of
https://github.com/ruvnet/RuView
synced 2026-06-09 10:13:17 +00:00
cfda8dbd14b9260e99bc1f01e1bd2f0a944d4be5
575 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 rUv
|
cfda8dbd14 |
feat(traffic): clone+view tracking → data/clone-data.rvf (ruvector JSONL RVF) (#656)
GitHub's /traffic/clones and /traffic/views endpoints only retain the
last 14 days server-side. Without periodic scraping, that data falls
off the cliff and is gone forever. This commit:
* Adds a scheduled GitHub Action (.github/workflows/clone-tracking.yml)
that runs on the 1st and 15th of every month (~14-day cadence) and
appends a snapshot to data/clone-data.rvf via the GitHub API.
* Seeds the file with today's first snapshot so the historical record
starts immediately rather than waiting for the next cron fire.
File format: ruvector JSONL RVF (schema "ruvector.rvf.jsonl/v1"). Each
line is one segment:
{type: "metadata", ...} — file header, written once on
first run
{type: "clone_snapshot", fetched_at,
window_count, window_uniques,
per_day: [{timestamp, count, uniques}, ...]}
— appended every run
{type: "view_snapshot", fetched_at,
window_count, window_uniques,
per_day: [{timestamp, count, uniques}, ...]}
— appended every run
Per-day entries are keyed by `timestamp`, so a downstream reader can
de-duplicate across overlapping snapshot windows (cron drift, manual
re-runs, etc.).
Today's seed:
clones (14d): 27,887 total / 6,611 uniques
views (14d): 162,314 total / 75,464 uniques
The workflow's commit message includes cumulative observed totals
("16 days observed → 30K clones, 28 days observed → 180K views"
style) so the git log itself doubles as a traffic timeline.
This is the long-term storage layer for the "downloads" badge work —
once we have a few months of snapshots, a small script can roll the
per-day entries into a real defensible number.
|
||
|
rUv
|
dc865c236e |
docs(readme): add 10M+ downloads badge (#655)
Adds a 'downloads 10M+' badge to the existing shields.io row, linking to the Edge Module Catalog section (where the cog binaries / HF weights / npm + crates packages are surfaced). Uses img.shields.io/badge/downloads-10M%2B-brightgreen.svg — static, no external counter API hit per page load. |
||
|
rUv
|
96bc4b4ede |
docs(readme): refresh capability table — positive voice, current state (#654)
The previous table mixed status badges (✅ / ⚠️ / 🔬) and verbose "pending wiring / not yet released" caveat columns. Rewrites it as "What / How / Speed-or-scale" — three columns, present tense, no status column. Captures what actually shipped this week: * Presence detection now points at the trained head shipped on HF (100% validation accuracy), with the phase-variance fallback reframed as a no-model option rather than a "loader pending" caveat. * 17-keypoint pose is its own row now — cog-pose-estimation v0.0.1 binaries on GCS, 8.4 ms cold-start on Pi 5, train-your-own in 2.1 s on RTX 5080. References ADR-101 + the benchmark log. * Multi-person counting drops the "Heuristic, not learned" framing. The adaptive P95 normalisation from PR #491 is in tree, the runtime dedup-factor knob is documented, and the six learned drop-in counters from the Cog catalog are linked: occupancy-zones, elevator-count, queue-length, customer-flow, clean-room, person-matching. * Edge intelligence row now points at the 105-cog catalog (ADR-102) instead of just the Cognitum Seed hardware. * Camera-supervised fine-tune row reflects the actual measured training time (2.1 s on RTX 5080 for 400 epochs) instead of the laptop estimate. * Drops the status-legend footer (no more ✅/⚠️/🔬 column to legend). Replaces it with a pointer down to the Edge Module Catalog. The ESP32 + Cognitum Seed deployment-options row gets the same treatment: cleaner list of what's included, no "Pose pending weights" parenthetical (the cog ships today). Net effect: same information, present tense, positive voice. Nothing removed beyond status badges + pending-work parentheticals; all genuine engineering details (e.g. "needs ~30 s ambient calibration" for the fallback) are preserved inline. |
||
|
rUv
|
feda871e02 |
docs(readme): drop the two Edge Intelligence collapsibles from the home page (#653)
Removes both: * 🧩 Edge Intelligence (ADR-041) — 60 WASM modules across 13 categories * 🧩 Edge Intelligence — All 65 Modules Implemented (ADR-041 complete) …and the 172 lines between them. The 60-module catalog narrative duplicated content already documented in: * The new 105-cog Edge Module Catalog collapsible (PR #648, ADR-102) — same purpose, sourced live from cognitum-apps/app-registry.json instead of hand-curated. * docs/edge-modules/* — per-category guides linked from the catalog. * ADR-041 itself. The home page now reads cleaner — one canonical "what modules exist" section (the live catalog) instead of three overlapping ones. |
||
|
rUv
|
43ac76a17f |
docs(readme): rewrite hero paragraph in plain language (#652)
The previous version listed every artifact format, every pending integration, and every not-yet-released model — useful as a status log but not as a what-this-system-does sentence for a first-time reader. Replaces it with a single paragraph that answers: - What does it do? (turn WiFi into a contactless sensor) - What hardware? ($9 ESP32) - What does it tell you? (who's there, breathing, heart rate) - How small is the model? (8 KB q4 fits anywhere) - What does it NOT need? (no cameras / wearables / phone apps) Everything that got removed — pending wiring, JSONL-vs-binary RVF, the 17-keypoint pose follow-up, the heuristic-fallback caveat — is already covered in dedicated sections later in the README (the Capability table, the Pretrained Model section, the Edge Module Catalog) and in #509 / ADR-079. The hero paragraph isn't the right place for the engineering caveat tour. |
||
|
rUv
|
6a2b2bdcbf |
fix(three.js): graceful banner when X Bot.fbx 404s on gh-pages (#651)
Demos 04 and 05 work fine locally — operator has assets/X Bot.fbx
present. On the gh-pages deploy the FBX is intentionally absent
(Mixamo license boundary, .gitignored) and the previous onError
handler just logged 'FBX load failed' to the console and left a
stuck '⚠ Load failed — see console' message in the overlay.
Replaces both onError handlers with an in-page card that:
- Explains why the asset is missing (license boundary, not a bug)
- Tells you exactly how to run it locally (Mixamo download path,
where to drop the file, the serve-demo.py command)
- Links to Mixamo + the repo source + back to the gallery
- Lets the ADR-097 helpers scene keep rendering behind it
- Logs at warn (not error) — no more uncaught console.error noise
The success branch is untouched, so local development is identical
to before.
|
||
|
rUv
|
d67d9872c1 |
feat(pages): deploy three.js demos to gh-pages/three.js/ (#649)
Adds a new GitHub Pages workflow that publishes the ADR-097 three.js demo gallery alongside the existing observatory/, pose-fusion/, pointcloud/, and nvsim/ deployments. Uses keep_files: true so the other deployments are preserved. What ships: * `examples/three.js/index.html` — new landing page that lists all 5 demos with screenshots, "standalone" vs "needs FBX" badges, and an honest note explaining the Mixamo X Bot.fbx license boundary (demos 04 and 05 need a local download from mixamo.com; demos 01-03 run standalone in any modern browser). * `.github/workflows/threejs-pages.yml` — staged copy of demos/, screenshots/, README.md, and the new index.html into `_site/three.js/`. Drops an `assets/README.txt` placeholder explaining the FBX-not-shipped policy. Triggered on changes to examples/three.js/** or the workflow itself. * README.md — adds the live link to the existing demo row (`▶ three.js Demos (5)`) plus a one-line callout describing the gallery and the FBX caveat. After this PR merges, the workflow runs and publishes: https://ruvnet.github.io/RuView/three.js/ |
||
|
rUv
|
67fec45e61 |
feat(edge-registry): ADR-102 — surface Cognitum cog catalog via /api/v1/edge/registry (#648)
* feat(edge-registry): ADR-102 — surface Cognitum cog catalog via /api/v1/edge/registry Adds a new sensing-server endpoint that fetches and caches the canonical Cognitum app registry at https://storage.googleapis.com/cognitum-apps/app-registry.json (105 cogs across 11 categories as of v2.1.0). RuView previously had no live awareness of the catalog — the README's capability table was hand- curated and went stale as Cognitum shipped new cogs (the registry was last updated 6 days ago). ADR: * docs/adr/ADR-102-edge-module-registry.md — full design, response shape, configuration flags, failure modes, and a 12-row security review covering SSRF, response inflation, ?refresh abuse, stale-serve semantics, TLS, cache poisoning, JSON-panic resistance, etc. Code: * v2/.../edge_registry.rs — EdgeRegistry struct + UreqFetcher + MockFetcher trait + 7 unit tests. RwLock<Option<CachedEntry>> with stale-on-error fallback. MAX_PAYLOAD_BYTES=8 MiB, 10s wire timeout. * v2/.../main.rs — constructs Option<Arc<EdgeRegistry>> at startup, registers GET /api/v1/edge/registry handler, wires Extension layer. Handler runs the blocking ureq fetch via tokio::task::spawn_blocking so the async runtime stays free. * v2/.../cli.rs / main.rs Args — three new flags (per user request to "allow the registry to be disabled or changed"): --edge-registry-url <URL> (env RUVIEW_EDGE_REGISTRY_URL) --edge-registry-ttl-secs <N> (env RUVIEW_EDGE_REGISTRY_TTL_SECS) --no-edge-registry (env RUVIEW_NO_EDGE_REGISTRY) When --no-edge-registry is set or the URL is empty, the endpoint returns 404. Cargo.toml: adds ureq (rustls), sha2, thiserror as direct deps. README: * New collapsed "🧩 Edge Module Catalog" section with the full 105-cog table generated from the registry, grouped by category with practical one-line descriptions (e.g. "Spots irregular heartbeats and abnormal heart rhythms", "Detects walking problems and scores fall risk"). Links to https://seed.cognitum.one/store and the local appliance /cogs page. Sits between the HF model section and How It Works. Tests (7/7 pass): first_call_hits_upstream_and_caches ttl_expiry_triggers_refetch force_refresh_bypasses_fresh_cache stale_serve_on_upstream_failure_after_cached_success no_cache_no_upstream_returns_error upstream_invalid_json_is_treated_as_error upstream_sha256_is_deterministic Security highlights (full review in ADR-102 §"Security review"): - The registry is metadata-only; per-cog binary signatures (ADR-100) remain the trust root for installs. A compromised registry can mislead a human reader but cannot ship malicious binaries. - 8 MiB cap + 10s timeout + Option<Arc<...>> via Extension layer means the endpoint can't be used to exhaust memory or pin tokio threads. - Stale-on-error responses carry an explicit `stale: true` field so upstream outages are visible to consumers rather than silently masked. - Endpoint sits behind the existing RUVIEW_API_TOKEN bearer gate when set, otherwise unauthenticated (registry contents are public anyway). * chore: refresh Cargo.lock for ureq/sha2/thiserror deps added by ADR-102 |
||
|
rUv
|
dc7f6cd096 |
fix(provision): additive-by-default — close the #391 full-replace footgun (#647)
Closes #391 (full-replace footgun). Phase 1 of #574 (esp32-csi-node provisioning UX). The mDNS discovery + USB-CDC pairing work in #574 remains future work; this PR handles only the provision.py-side fix. Background: provision.py flashed a fresh NVS partition at 0x9000 every invocation. The previous behaviour built that partition only from the CLI flags passed on the current run — every key you didn't pass was silently erased. We hit it ourselves earlier today: --force-partial only suppressed the safety check but still wiped the SSID. This PR replaces the full-replace semantic with a per-port state file that captures every config value previously flashed from this machine. On each invocation: 1. Read ~/.config/wifi-densepose/esp32-provision-state/<port>.json (or %APPDATA%/... on Windows). 2. Overlay the new CLI flags on top — CLI wins where set. 3. Generate + flash NVS from the merged dict. 4. Persist the merged dict back to the state file. Net effect: the exact scenario from #391 + today's incident now passes (test_partial_invocation_does_not_drop_unrelated_keys): python provision.py --port COM7 --ssid Net --password p --target-ip 10.0.0.5 # later: python provision.py --port COM7 --seed-url http://10.0.0.99:8080 # WiFi creds preserved, seed_url added. New flags: --reset Wipe per-port state before merging (recycled-board path). --state-dir Override per-user state dir (XDG / %APPDATA% by default). --state Print the merged state and exit (debug / inspection). --force-partial preserved as a deprecation-flagged escape hatch. State file caveats (in the module docstring): per-machine, atomic write via .tmp + os.replace, future follow-up to add USB-CDC NVS dump for device-authoritative merging is tracked in #574. Tests: tests/test_provision_state.py — 11 tests covering load/save round-trip, corrupt-JSON resilience, CLI-wins-over-prior, the exact #391 case, falsy-but-not-None CLI override (node_id=0 must survive), and serial-port path sanitization for /dev/ttyUSB0. 11/11 pass. Live-tested end-to-end with --dry-run + --state inspection: first run: ssid + password + target_ip persisted second run: --seed-url added — WiFi creds intact in final state. |
||
|
rUv
|
4b1a835107 |
docs: repoint #640 references to #645 (original deleted, replaced) (#646)
Issue #640 (PCK gap follow-up) was deleted upstream after the cog v0.0.1 PRs landed today. Re-opened as #645 with the same context plus the new measured v0.0.1 numbers (PCK@20 3.0%, PCK@50 18.5%, MPJPE 0.093). This patch updates the three files in main that still pointed at the dead #640 to point at #645 instead — ADR-101, the cog README, and the benchmark log. |
||
|
rUv
|
9c3c8b98bc |
docs(adr): ADR-100 + ADR-101 — record v0.0.1 shipping status (#644)
Updates both ADRs to reflect that the first cog (`cog-pose-estimation@0.0.1`) landed today via PRs #642 + #643. ADR-100 (Cog Packaging Specification): * Status line: "first conforming cog shipped 2026-05-19". * Migration step 2 marked complete with PR references and the GCS paths the binaries live at. ADR-101 (Pose Estimation Cog): * Status line: "v0.0.1 shipped 2026-05-19". * New "v0.0.1 shipping status" section that walks through every ADR-100 acceptance gate with concrete pass/fail evidence (binary sizes, sha256 round-trip, signature, manifest path, live install on cognitum-v0, runtime contract, real-weights load assertion, ONNX parity). * Measured-metrics table: training time (2.1 s/400 epochs on RTX 5080), PCK@20/PCK@50/MPJPE, cold-start latency for Windows/ruvultra/Pi 5. * Carries forward the two open follow-ups: Hailo HEF (SDK-gated) and PCK@20 >= 35% (data-bound, #640). * "See also" link to docs/benchmarks/pose-estimation-cog.md. Docs-only; no code changes. |
||
|
rUv
|
fcb6f4bf12 |
feat(cog-pose-estimation): x86_64 release v0.0.1 — parallel to arm (#643)
Adds the x86_64-unknown-linux-gnu binary uploaded to
gs://cognitum-apps/cogs/x86_64/, signed with the same Ed25519
COGNITUM_OWNER_SIGNING_KEY as the arm release. Together with the
already-shipped arm artifact, the cog now ships natively for both
target architectures the Cognitum fleet supports.
x86_64 release:
sha256: a434739a24415b34e1aff50e5e1c3c32e568db96af473bbb3e5ecc9b95fe71fa
signature: pNNuxhgM18PztN8BSZdfw5oAShG2pV3na5T/q2QdlJWX/5FJgo4QTiUCbcTAxI2Uiva8VURSOlRzMU3xoQPqCQ==
size: 4,548,856 bytes
cold-start: 5.4 ms / invocation on ruvultra (RTX 5080, NVMe)
Reorganizes manifests under cog/artifacts/manifests/{arm,x86_64}/
so each arch carries its own manifest with the matching binary_sha256
and signature — same layout the release pipeline will use for the
future hailo8 / hailo10 variants.
Updates docs/benchmarks/pose-estimation-cog.md with the cross-arch
cold-start table:
Windows (x86_64) 76.2 ms
ruvultra (x86_64) 5.4 ms <- this release
Pi 5 (aarch64) 8.4 ms
Verified via anonymous GCS download + SHA round-trip — identical to
local build.
Hailo HEF remains the only pending arch, still blocked on Hailo SDK
provisioning to a self-hosted runner.
|
||
|
rUv
|
3314c8db8d |
feat(cog-pose-estimation): scaffold first Cog from this repo (ADR-100 + ADR-101) (#642)
* feat(cog-pose-estimation): scaffold first Cog from this repo (ADR-100 + ADR-101) Adds the foundation for the pose-estimation Cog that ships from this repo into Cognitum V0 appliances. Companion ADR-225 + crate land in cognitum-one/v0-appliance. ADRs: * ADR-100 formalises the Cognitum Cog packaging spec — on-device layout under /var/lib/cognitum/apps/<id>/, manifest.json schema (incl. new binary_sha256 + binary_signature fields), GCS hosting convention, repo source layout, build pipeline, and the four-verb runtime contract (version | manifest | health | run). Documents the convention I reverse-engineered from inspecting installed cogs on a live cognitum-v0 appliance — `anomaly-detect`, `presence`, `seizure-detect`, etc. * ADR-101 designs the pose-estimation Cog itself: where it sits in the wifi-densepose pipeline (encoder init from ruvnet/wifi-densepose-pretrained, 17-keypoint regression head), what gets shipped per target arch (arm / x86_64 / hailo8 / hailo10), acceptance gates (PCK@20 explicitly deferred to #640 — this ADR ships the vehicle, not the accuracy). Crate v2/crates/cog-pose-estimation/: * Cargo.toml + workspace member declaration with a hailo feature gate so the binary builds without the Hailo SDK in CI. * main.rs implements the four-verb CLI exactly per ADR-100. * config.rs / manifest.rs / publisher.rs / inference.rs / runtime.rs — small modules, each <100 lines. * publisher.rs emits ADR-100 structured JSON events. * inference.rs is a stub that produces a centred-skeleton baseline with confidence=0 (honest: no trained weights wired in yet). * runtime.rs subscribes to /api/v1/sensing/latest, slides a 56*20 window, runs the engine, emits pose.frame events. * cog/manifest.template.json + cog/config.schema.json define the release artifact + runtime config schemas. * cog/Makefile holds build / sign / upload targets. * tests/smoke.rs covers manifest roundtrip + engine I/O surface. Verified locally: * cargo check -p cog-pose-estimation: clean. * cargo test -p cog-pose-estimation: 4/4 pass. * ./target/release/cog-pose-estimation {version,manifest,health}: all emit the right contract output. This commit contains scaffolding only; the actual trained weights and Hailo HEF cross-compile come in follow-ups tracked in #640 and the companion v0-appliance branch. * feat(cog-pose-estimation): first measured run — Candle CUDA on RTX 5080 Trained pose_v1 on ruvultra (RTX 5080) via Candle 0.9 + cuda feature against the same 1,077-sample paired session that produced 0%/0% PCK in #640 with the pure-JS SPSA trainer. First real numbers: PCK@20 = 3.0% (up from 0.0%) PCK@50 = 18.5% (up from 0.0%) MPJPE = 0.093 (down from 0.66, ~7x improvement) 400 epochs in 2.1 s wall time, full-batch, ~5 ms/epoch. Loss curve 0.181 -> 0.014 over the run, eval 0.010. Per-joint reveals the model leans on right-side proximal joints (r_hip 77% PCK@50, r_knee 35%, l_elbow 26%) — consistent with the camera framing in the source recording. Distal joints (wrists, ankles) and face joints are still near-random, consistent with the 56-subcarrier / 20-frame input not carrying fine-grained spatial info at 1077 samples. This commit: * Adds v2/crates/cog-pose-estimation/cog/artifacts/{pose_v1.safetensors, train_results.json} so the cog dir now contains a real reference artifact, not just scaffold. * Updates cog/README.md "Status" block with the measured numbers, per-joint table, and an honest reading of where the model succeeds vs where the data is the bottleneck. * Adds docs/benchmarks/pose-estimation-cog.md as the canonical benchmark log — append-only, one section per published run. * Appends a "First measured run" section to ADR-101 referencing the new benchmark file. Still pending in the follow-up: * Wire pose_v1.safetensors into src/inference.rs (replace stub). * ONNX export (Candle lacks a writer — needs external conversion). * Hailo HEF cross-compile + cluster deploy. The data-bound gap to PCK@20 >= 35% is tracked in #640. * feat(cog-pose-estimation): wire real weights — cog is no longer a stub Replaces the centred-skeleton stub in src/inference.rs with a real Candle-based loader that reads cog/artifacts/pose_v1.safetensors and runs the trained Conv1d encoder + MLP pose head on every incoming CSI window. What changes: * src/inference.rs: PoseNet mirrors the training script's architecture exactly — Conv1d(56->64, k=3 d=1), Conv1d(64->128, k=3 d=2), Conv1d(128->128, k=3 d=4), mean over time, Linear(128->256)+ReLU, Linear(256->34)+sigmoid -> reshape [17, 2]. The InferenceEngine searches a sensible candidate list for the weights file (/var/lib/cognitum/apps/pose-estimation/, ./pose_v1.safetensors, ./cog/artifacts/, repo-root, v2/-relative) and falls back to the stub when none are present so the cog still satisfies ADR-100. * Cargo.toml: adds candle-core 0.9 + candle-nn 0.9 (no-default-features, CPU build by default) + safetensors 0.4. New `cuda` feature opt-in for GPU inference on hosts that have it. Drops the unused wifi-densepose-train path dep from the default build path. * src/main.rs + src/publisher.rs: health.ok event now carries `backend` (candle-cuda | candle-cpu | stub) and the synthetic output confidence, so operators can tell at a glance whether the cog loaded its weights or fell back to the stub. * tests/smoke.rs: adds `real_weights_load_when_available` which asserts the loaded engine reports backend=candle-* and emits non-zero confidence — exactly the signal that proves we're not silently degrading to the stub. Verified locally: * `cargo check -p cog-pose-estimation --no-default-features` — clean * `cargo test -p cog-pose-estimation --no-default-features` — 5/5 pass * `./target/release/cog-pose-estimation health` emits: {"event":"health.ok","fields":{"backend":"candle-cpu","cog":"pose-estimation","synthetic_output_confidence":0.185}} — 0.185 is the published PCK@50 from cog/artifacts/train_results.json, emitted by the real Candle inference path (would be 0.0 if it had fallen back to the stub). The cog now runs the trained pose_v1 model end-to-end. Accuracy is still bounded by the underlying 1077-sample training data (PCK@20 3.0%, PCK@50 18.5% per docs/benchmarks/pose-estimation-cog.md) — that gap is data-bound and tracked in #640. ONNX export + Hailo HEF cross-compile remain follow-ups. * docs(benchmarks): measure cog-pose-estimation cold-start latency 100 sequential `cog-pose-estimation health` invocations average 76.2 ms each on a Windows x86_64 host using the `candle-cpu` backend. Each invocation re-loads pose_v1.safetensors and runs one synthetic forward pass, so this is the worst-case cold-start path. Long-running `run` inference will be sub-millisecond per frame once the model is loaded. Updates the benchmarks doc accordingly. * feat(cog-pose-estimation): ONNX export — pose_v1.onnx + scripts/export-onnx.py Adds the canonical ONNX artifact that unblocks downstream Hailo HEF cross-compile + ONNX Runtime benchmarks. Generated on ruvultra (torch 2.12.0 + CUDA), 12,059 bytes, opset 18, dynamic batch axis. * scripts/export-onnx.py: mirrors the Candle inference architecture in PyTorch (Conv1d 56->64, 64->128, 128->128 + Linear 128->256->34), pure- python safetensors loader (no extra pip dep), exports via torch.onnx.export, then verifies via onnx.checker.check_model and numerical parity against the torch reference. * Verified parity vs torch: max |torch - onnx| = 8.94e-8 (1e-5 threshold). Effectively bit-perfect. * v2/crates/cog-pose-estimation/cog/artifacts/pose_v1.onnx — the artifact itself, 12 KB. * docs/benchmarks/pose-estimation-cog.md — adds an ONNX export section with the verification numbers. Next: Hailo HEF cross-compile (still gated on Hailo SDK on a self-hosted runner) and ONNX Runtime latency benchmarks on each target arch. * feat(cog-pose-estimation): release v0.0.1 — signed aarch64 binary on GCS End-to-end deploy: cross-compiled to aarch64-unknown-linux-gnu on ruvultra, ran via qemu-aarch64-static, then smoke-tested on a real cognitum-v0 Pi 5. Signed with COGNITUM_OWNER_SIGNING_KEY (Ed25519) and uploaded to gs://cognitum-apps/cogs/arm/. Real-hardware results on cognitum-v0 (Pi 5): health: backend=candle-cpu, confidence=0.185, real weights loaded 30x sequential `health`: 0.251 s total -> 8.4 ms / invocation (cold) GCS release artifacts (publicly downloadable): binary: 3,741,976 bytes sha256 1e1a7d3dd01ca05d5bfc5dbb142a5941b7866ed9f3224a21edc04d3f09a99bf5 weights: 507,032 bytes sha256 eb249b9a6b2e10130437a10976ed0230b0d085f86a0553d7226e1ae6eae4b9e5 signature (Ed25519, b64): LUN7xqLPYD3MFzm5dKB5MnYU0LvoRtek5ci5KiKPHBg+Xo6xuazwokn2Dw2JPMaLYJzmWn/SpT4djuR7hYvVDw== Adds: * v2/crates/cog-pose-estimation/cog/artifacts/manifest.json — the release-pipeline-produced manifest with all fields filled in per ADR-100, including arch, target_triple, signature, and a build_metadata block carrying the validation PCK numbers. * docs/benchmarks/pose-estimation-cog.md — new sections covering the real Pi 5 smoke (8.4 ms cold-start) and the signed GCS release artifacts. Verified by downloading the binary anonymously from GCS and re-computing the sha256 — matches the locally-computed sha exactly. Signature decoded to the expected 64-byte Ed25519 length. Closes the GCS-upload acceptance criterion from ADR-100; the only pending work is Hailo HEF cross-compile (still SDK-gated) and an x86_64 release alongside this arm release. * docs(benchmarks): record live cognitum-v0 install + 5-sec smoke run Adds the "Live appliance install" section documenting what happened when the signed v0.0.1 binary + weights were installed under /var/lib/cognitum/apps/pose-estimation/ on cognitum-v0 (the V0 cluster leader). * Layout matches the existing anomaly-detect / presence / seizure- detect cogs exactly — the Cogs dashboard at http://cognitum-v0:9000/cogs auto-discovers entries. * `cog-pose-estimation run` ran for 5 seconds in the background and cleanly emitted run.started + structured WARN events for the missing local sensing-server on :3000 (cognitum-v0's actual CSI source is ruview-vitals-worker on :50054, not :3000). No crashes, no NaN, no leaks. * Wiring `sensing_url` to the appliance-native source is a separate Day-2 integration task. |
||
|
rUv
|
ef20a7280d |
fix(align): stream JSONL + support sensing_update format (#641)
Two blockers discovered while running ADR-079 P7→P8 end-to-end against
a 30-minute paired session (39,088 GT frames + 45,625 CSI frames):
1. `readFileSync(_, 'utf8').split('\n')` hit Node's `String.MaxLength`
(~512 MB) on the 750 MB CSI recording. Result:
Error: Cannot create a string longer than 0x1fffffe8 characters
Replaced loadJsonl with a 1 MiB byte-buffer streaming reader that
decodes line-by-line, so memory use stays bounded by the largest
single record.
2. The sensing-server has long since switched from the legacy `raw_csi`
/ `feature` typed records to a single `sensing_update` record per
tick (with nodes[].amplitude and top-level features). The aligner
filtered on the old types and produced 0 frames every time. Added a
`sensing_update` branch that projects each tick into rawCsi/features
entries the existing windowing code can consume, and updated
extractCsiMatrix to use already-extracted amplitudes when iqHex is
absent. timestamp is now accepted as either ISO string (legacy) or
numeric float-seconds (current).
End-to-end verified: produces 1,077 paired samples at
`--min-confidence 0.3 --window-frames 20` from the full 30-min
recording; downstream `train-wiflow-supervised.js` runs to completion.
See follow-up #640 for the PCK gap (data + GPU needed) — those are
training concerns, not aligner concerns.
|
||
|
rUv
|
ad15f1b049 |
docs: truth-up README + user-guide on Hugging Face model release (#637)
The previous wording in both README.md and docs/user-guide.md claimed
no pretrained weights were released yet. That was wrong — the
contrastive CSI encoder + presence-detection head + per-node LoRA
adapters have been published as
ruvnet/wifi-densepose-pretrained on Hugging Face for several weeks
(124 downloads at time of writing), with 100% presence accuracy on
the validation set and 164,183 emb/s on M4 Pro.
This commit replaces the "no shipped weights" framing with the actual
state, and surfaces a real loader gap discovered during a
before/after benchmark of the sensing-server:
* Baseline run (no --model): server produced presence/motion/vitals
output at ~19 ticks/s, as expected.
* After run (--model models/wifi-densepose-pretrained.rvf): the
progressive RVF loader errored with
"invalid magic at offset 0: expected 0x52564653, got 0x7974227B"
(0x7974227B is the ASCII bytes {"ty… from the JSONL header).
v2/.../rvf_container.rs only parses the binary RVF segment
format; the HF artifact is JSONL RVF. When the load fails the
pipeline degraded to null output (variance=0, presence=None) rather
than falling back to heuristic mode.
The docs now describe (a) what works today — Python / training-side
consumption of model.safetensors — and (b) what is gated on a JSONL
adapter or a binary-RVF republish — sensing-server --model loading.
The 17-keypoint pose model remains separately pending (#509,
ADR-079 phases P7–P9).
|
||
|
rUv
|
8247d28d90 |
docs(README): truth-up capability table — separate shipped/heuristic/pending (#568 follow-up) (#635)
@xiaofuchen's audit in #568 was technically correct: the project page claimed capabilities (\"Pose estimation\", \"Presence sensing — trained model + PIR fusion — 100% accuracy\") that aren't what the code actually does. PR #573 fixed this in the firmware README; this commit applies the same truth-up to the main repo README so first-time visitors get an honest picture. Specific changes: 1. **Hero paragraph (line 35)** — was \"RuView also supports pose estimation (17 COCO keypoints …)\" with no caveat. Now: ships the training infrastructure; pretrained weights are not yet released (links #509 and ADR-079 P7-P9 Pending). 2. **Capability table (lines 50-61)** — was a single 11-row \"What/How/ Speed\" table that mixed shipped, heuristic, and pipeline-only capabilities under the same emoji. Now a status column with a three-tier legend: - ✅ shipped + tested on hardware (breathing rate, heart rate, motion, fall detection, through-wall, edge intelligence, multi-frequency mesh) - ⚠️ ships and runs, but is a heuristic/threshold (presence indicator, multi-person slot count) — accuracy depends on calibration and signal conditions - 🔬 implementation + tests in repo, weights/data/eval pending (17-keypoint pose estimation, camera-supervised fine-tune, 3D point cloud fusion) 3. **Hardware capability column (lines 91-93)** — was \"Pose, breathing, heartbeat, motion, presence\" for the ESP32 options. Replaced with the literal list of capabilities that actually work today (presence indicator, motion, breathing, heart rate, fall detection, slot-count heuristic) with an explicit \"Pose pending weights — see #509\" qualifier. Pointing also to the v0.6.5-esp32 release-aligned firmware README that already has the firmware-side truth-up (PR #573). This is documentation only — no code change, no behaviour change. The project's capabilities haven't changed; the project page now describes them honestly. |
||
|
github-actions[bot]
|
5d6e50d8a0 |
chore: update vendor submodules (#634)
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> |
||
|
nai
|
49fb2ca9f4 |
feat(ui): UI overhaul — consolidates #305-#309 (keyboard shortcuts, perf monitor, toasts, theme, command palette, activity log, data export, mobile PWA, accessibility, i18n) (#620)
* feat(ui): add keyboard shortcuts, perf monitor, toast system, theme toggle, and WCAG accessibility - Keyboard shortcuts overlay (press ? for help, 1-8 for tabs, T for theme, P for perf) - Real-time performance monitor with FPS, memory, latency sparklines (draggable) - Enhanced toast notification system with stacking, auto-dismiss, progress bars - Dark/light theme toggle with localStorage persistence and system preference detection - WCAG accessibility: skip-to-content link, ARIA roles/attributes on tabs and panels, arrow key navigation in tab bar, focus-visible outlines - ESLint config for UI directory with security and quality rules * feat(ui): add command palette, activity log, data export, fullscreen mode, connection status - Command palette (Ctrl+K / Cmd+K) with fuzzy search across tabs and actions - Activity log panel (L key) with real-time console interception, filters, resizable - Data export utility (E key) for sensor data as JSON/CSV with dialog - Fullscreen mode (F key / F11) for visualization tabs with exit button - Connection status widget in header showing WebSocket state and reconnect * feat(ui): add mobile hamburger nav, PWA support, and 40 unit tests - Mobile hamburger navigation: slide-out drawer replacing tab bar on <768px, swipe-to-close, animated hamburger icon, auto-sync with tab manager - PWA manifest + service worker: installable dashboard, offline shell caching (cache-first for static, network-first for API), auto-cleanup of old caches - 40 unit tests for ToastManager, ThemeToggle, KeyboardShortcuts, PerfMonitor, TabManager - browser-based test runner at ui/tests/unit-tests.html - PWA meta tags: theme-color, apple-mobile-web-app-capable, manifest link - Icon generator page for creating PWA icons (ui/icons/generate.html) * feat(ui): add URL routing, onboarding tour, idle detection, notification center - Hash router: tabs are bookmarkable/shareable via URL (#demo, #sensing, etc.), syncs with TabManager, supports browser back/forward navigation - Onboarding tour: interactive 6-step first-run walkthrough with spotlight highlighting, step indicators, skip/back/next controls, localStorage persistence - Idle detection: pauses health polling and reduces CSS animations after 3 min of inactivity, resumes on user interaction, integrates with Page Visibility API - Notification center: bell icon in header with unread badge, event history panel with mark-read/clear, persists across page views via sessionStorage * feat(ui): add i18n (EN/PL), screenshot tool, settings panel, reduced motion, uptime clock - i18n: English/Polish translations with auto-detection, language selector in header, data-i18n attributes on dashboard elements, localStorage persistence - Screenshot tool (S key): captures active tab to clipboard or downloads PNG, flash effect, canvas rendering with watermark, fallback for tainted canvases - Quick settings panel (gear icon): reduced motion toggle, high contrast mode, compact layout mode, health polling toggle, clear data, reset onboarding - Uptime clock: current time + session duration in header - prefers-reduced-motion: system-level and manual toggle, disables all animations and transitions for vestibular accessibility - High contrast mode: WCAG AAA compliant colors for both light and dark themes - Compact mode: condensed layout for dense information display |
||
|
NgoQuocViet2001
|
3439fb1402 | fix(provision): recognize swarm/hopping flags as config values (#617) | ||
|
Rahul
|
c00f45e296 |
fix(sensing): finish #611 NaN-panic audit — 7 more sites missed by #613 (#624)
#613 fixed adaptive_classifier.rs:94 (the IQR sort) and called the audit done, but the grep used `partial_cmp(b).unwrap()` as a literal and missed seven additional production sites that use comparator variants: adaptive_classifier.rs:205 AdaptiveModel::classify() argmax over softmax probs — same per-frame hot path as #611. NaN flows through normalise → logits → softmax and still reaches this site even after the IQR fix. adaptive_classifier.rs:480 train() argmax (training accuracy loop) adaptive_classifier.rs:500 train() per-class argmax main.rs:2446, 2449 count_persons_mincut variance source/sink select csi.rs:602, 605 count_persons_mincut variance source/sink select (duplicate of main.rs logic in csi.rs) For the variance-select sites, note that the *outer* `unwrap_or((0, &0))` only catches an empty iterator — it cannot rescue a panic raised inside the comparator. A single NaN in `variances[]` still aborts the process. Same fix as #613: swap `.unwrap()` for `.unwrap_or(std::cmp::Ordering::Equal)` inside the comparator closure. Pure behavioural change, no API surface. Re-audit of the remaining `partial_cmp(...).unwrap()` matches in v2/: they are all inside `#[cfg(test)]` / `#[test]` blocks (spectrogram.rs:269, depth.rs:234, connectivity.rs:477, vital_signs.rs:737) where inputs are controlled and panic-on-NaN is acceptable. |
||
|
Blossom
|
f54f0285bd |
fix(ci): build multi-arch wifi-densepose image — linux/arm64 was missing (closes #625) (#631)
PR #547 refreshed the sensing-server docker publish and the README badge advertises 'Docker: multi-arch amd64 + arm64', but .github/workflows/sensing-server-docker.yml only sets 'platforms: linux/amd64'. The arm64 layer was never actually wired in. Consequence on Docker Hub today (ruvnet/wifi-densepose:latest, last pushed 2026-05-14 by #547): $ curl -s https://hub.docker.com/v2/repositories/ruvnet/wifi-densepose/tags/latest/ images: arch=amd64 os=linux arch=unknown os=unknown # the 1.5KB attestation layer, not arm64 So Apple Silicon Macs (the platform in #625) hit: docker pull ruvnet/wifi-densepose:latest Error: no matching manifest for linux/arm64/v8 in the manifest list This is the same crash class as the closed-unmerged #136 'Docker error on MacOS'; #625 is a fresh report (Mac M3 Pro, macOS Tahoe 26.4.1) of the same bug. Fix is the standard buildx multi-arch recipe: 1. Add docker/setup-qemu-action@v3 before setup-buildx so the amd64 runner can cross-build the arm64 layer (QEMU user-mode emulation). 2. Change 'platforms: linux/amd64' -> 'platforms: linux/amd64,linux/arm64'. docker/Dockerfile.rust is already arch-agnostic — no '--target' flag, no amd64-only Cargo deps, only 'cc = "1.0"' which is cross-aware — so no Dockerfile changes are needed. Buildx + QEMU does the rest. Smoke tests are unaffected: they 'docker pull' on ubuntu-latest (amd64), so the runner auto-selects the amd64 entry from the multi-arch manifest. Multi-arch manifests are transparent to single-arch consumers. Scope discipline: this PR only touches sensing-server-docker.yml (the file issue #625 is about). nvsim-server-docker.yml has the identical 'platforms: linux/amd64' bug but is out of scope here — happy to file a follow-up if useful. Note (not part of this fix): the last 5 runs of this workflow have failed at the 'Log in to Docker Hub' step (DOCKERHUB_TOKEN secret looks rotated/ expired). That's a separate, secret-side issue I can't touch from a PR. Once that's resolved, the next push to main will produce a proper amd64+arm64 manifest for the first time. Co-authored-by: Mack Ding <mack@claws.ltd> |
||
|
Winter Lau
|
e964eaf14f | fix(deps): bump ndarray 0.15→0.17 and ndarray-npy 0.8→0.10 (closes #626) (#627) | ||
|
rUv
|
961c01f4bd |
Merge pull request #633 from ruvnet/integrate/pr-491-adaptive-person-count
Merge #491: feat(sensing-server): adaptive person count — RollingP95 + dedup_factor (integration on schwarztim's behalf) |
||
|
ruv
|
79cc2d7b22 |
Merge #491: feat(sensing-server): adaptive person count — RollingP95 + dedup_factor runtime API
Integrating @schwarztim's PR #491 into main on their behalf — their fork has fallen too far behind for a clean rebase (the PR's commit graph dropped silently during `git rebase origin/main`), so applying as a merge from the fork head to preserve the diff cleanly. What this lands: - `RollingP95` adaptive normaliser for the person-count feature scaling. Streaming P95 over a 600-sample / ~30 s sliding window. Cold-start (<60 samples) falls back to the legacy denominators (variance/300, motion_band_power/250, spectral_power/500) so day-0 behaviour is preserved on every deployment. - `RuntimeConfig` struct + `load_runtime_config` / `save_runtime_config` persisted to `data/config.json`. Exposes `dedup_factor` via REST so multi-node deployments can tune cluster-deduplication without a rebuild, including an auto-tune endpoint that derives optimal dedup from a known person count (calibration mode). - `compute_person_score()` now takes &AppStateInner alongside &FeatureInfo so the adaptive denominators are reachable. All 3 call sites updated. - New `AppStateInner` fields: `p95_variance`, `p95_motion_band_power`, `p95_spectral_power`, `dedup_factor`, `data_dir`. Closes #491. Directly addresses: - #499 (double skeletons, multi-node) — the slot-clustering problem this PR's adaptive normaliser was designed to fix - #519 Bug 1 (ghost person detection on edge-tier 1 & 2 multi-node) - #496 (person count over-reporting on single-room single-person) Verified locally: - cargo check -p wifi-densepose-sensing-server --no-default-features: 1.0s - cargo test -p wifi-densepose-sensing-server --no-default-features --lib: 233/233 passed in 25.0s Co-authored-by: @schwarztim Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
rUv
|
f5e2b5474b |
release: ESP32-S3 firmware v0.6.5 — Tmr Svc stack + OTA init refactor (#628)
Three fixes wrapped for the v0.6.5-esp32 release tag:
1. **`sdkconfig.defaults` adds `CONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192`**.
The fix was already in `sdkconfig.defaults.template` (ADR-081, prevents
"stack overflow in task Tmr Svc" bootloop when adaptive_controller emits
feature_state from inside a Timer Svc callback). It was MISSING from the
canonical `sdkconfig.defaults` file used by the build, so any fresh
build picked up the 2 KiB FreeRTOS default and bootlooped on hardware.
Verified on COM7: with the fix, no panics in 30 s of operation; without
it, "***ERROR*** A stack overflow in task Tmr Svc has been detected."
followed by sustained bootloop.
2. **`ota_update.c` extracts `ota_load_psk_from_nvs()` and calls it from
both `ota_update_init()` and `ota_update_init_ex()`.** `main.c:230` uses
the `_ex` variant, but only `ota_update_init()` was loading the PSK
from NVS. Result: `s_ota_psk` stayed empty regardless of NVS contents,
so the RuView#596 fail-closed posture rejected every request — but the
diagnostic warning never printed at boot, leaving operators no signal
about why their OTA uploads were 403'ing. Verified on COM7:
W (3126) ota_update: NVS namespace 'security' not found —
OTA upload endpoint will REJECT all requests until provisioned.
Fail-closed per RuView#596.
3. **`version.txt`: 0.6.4 → 0.6.5**, paired with the v0.6.5-esp32 tag so the
firmware-ci version-guard job (RuView#505 fix-marker) stays happy.
Both validations done end-to-end on hardware (COM7, ESP32-S3 8MB,
provisioned with --edge-tier 2 to also incidentally re-verify #438 is not
reproducible on current main).
v0.6.5-esp32
|
||
|
rUv
|
281c4cb0ce |
fix(firmware): OTA upload fails closed when no PSK in NVS (RuView#596 audit) (#623)
ota_check_auth() previously returned true when s_ota_psk[0] == '\0'
("permissive for dev"). A freshly-flashed node — or any node where
nobody had provisioned an OTA PSK yet — accepted attacker-controlled
firmware over plain HTTP on port 8032 from any host on the WiFi. No
Secure Boot V2, no signed-image verification, no transport encryption.
Single LAN call could brick or backdoor a node.
This was flagged in the deep security review of PR #596 but was a
PRE-EXISTING bug in main, not new code from that PR — so it stood as
a critical-severity production issue until this commit.
Fix:
- ota_check_auth() now returns false when no PSK is provisioned, with
ESP_LOGW("OTA rejected: no PSK in NVS …") at the call site so the
operator can diagnose the rejection from serial logs
- ota_update_init() ESP_LOGW message updated to surface the new posture
at boot ("upload endpoint will REJECT all requests until provisioned")
- Doc comment on ota_check_auth() rewritten to make the contract
explicit and reference the audit
The OTA HTTP server itself still starts even when no PSK is set. That
lets the operator run `provision.py --ota-psk <hex>` over USB-CDC to
write the NVS key without reflashing the firmware. The upload endpoint
just refuses every request in the meantime.
Breaking change for any deployment that depended on the unauthenticated
OTA path working out of the box. Documented in CHANGELOG under
[Unreleased] / Security so it's visible at the next release cut.
Fix-marker RuView#596-ota-fail-closed (scripts/fix-markers.json)
requires the new behaviour and forbids the old "permissive for dev"
fallback strings, so a future revert fails CI.
|
||
|
rUv
|
b2e2e6d6fd |
fix(sensing-server): WS broadcast emits effective_source() not hardcoded "esp32" (closes #618) (#621)
Reported by @ArnonEnbar with a complete reproduction. broadcast_tick_task() re-emits the cached `latest_update` every tick so pose WS clients keep getting data even when ESP32 pauses between frames. The `source` field of that cached update was set to "esp32" at the moment a fresh ESP32 frame was last decoded (main.rs:3885, :4136). After the ESP32 loses power or network, no fresh frame is decoded — the cached `latest_update` is still re-broadcast every tick with the stale source: "esp32" baked in. UI's "Sensing" tab keeps showing "LIVE — ESP32 HARDWARE Connected" with frozen vitals/features/ classification re-broadcast indefinitely. REST `/health` correctly reports source: "esp32:offline" (via effective_source(), which checks last_esp32_frame elapsed time against ESP32_OFFLINE_TIMEOUT=5s) — but the WS broadcast path was the one consumer that didn't call it. Fix: clone the cached update per tick, overwrite source with s.effective_source(), then serialize and broadcast. UI now switches to "esp32:offline" on the same 5s budget as the REST surface. cargo build -p wifi-densepose-sensing-server --no-default-features: 17s, no errors (1 pre-existing unused-import warning unchanged). |
||
|
rUv
|
72bbd256e7 |
fix(security): path-traversal guard on 5 sensing-server endpoints (closes #615) (#616)
Reported by @bannned-bit. Five endpoints in
v2/crates/wifi-densepose-sensing-server embedded user-controlled
identifiers in format!() paths with no sanitization:
recording.rs POST /api/v1/recording/start (session_name)
recording.rs GET /api/v1/recording/download/:id (id)
recording.rs DELETE /api/v1/recording/delete/:id (id)
model_manager.rs POST /api/v1/models/load (model_id)
training_api.rs load_recording_frames (dataset_ids[])
Each unauthenticated caller could:
- READ arbitrary files via ../../etc/passwd, ../../.env, etc.
- WRITE attacker-controlled JSONL via recording/start
- LOAD attacker-controlled .rvf model files
- DELETE arbitrary files the server process can touch
New `path_safety` module exports `safe_id(&str) -> Result<&str, PathSafetyError>`
that enforces the rejection envelope BEFORE any user input reaches a
format!() that builds a path:
- Allowed character set: [A-Za-z0-9._-]
- Reject leading '.' (rules out '.', '..', '.env', hidden files)
- Reject empty strings
- Reject anything > 64 bytes
- Reject all whitespace, path separators, null bytes, non-ASCII
Applied at all 5 sites. Errors return 400 Bad Request (download) /
status:"error" JSON (others) — not panics.
9 unit tests in path_safety::tests cover:
- accepts simple alphanumeric / hyphen / underscore / dot
- rejects empty, leading dot, path separators ('/', '\'),
null byte, whitespace, shell specials, non-ASCII (including
fullwidth slash U+FF0F), too-long, boundary at MAX_ID_LEN
test result: ok. 9 passed; 0 failed
cargo build -p wifi-densepose-sensing-server --no-default-features: 33s
Fix-marker RuView#615 in scripts/fix-markers.json prevents removing the
guard at any of the 5 call sites. CHANGELOG entry under [Unreleased] /
Security documents the patched endpoints and the rejection envelope.
Severity: critical per reporter — five remotely-reachable paths to read,
write, or delete arbitrary files. Hot per-request paths, not edge cases.
|
||
|
rUv
|
50131b2519 |
fix(verify): cross-platform deterministic proof — 6-decimal quantize + thread-pinning (closes #560) (#609)
* fix(verify): quantize features before SHA-256 for cross-platform hash stability (#560) ## The bug archive/v1/data/proof/verify.py:172 claimed the hash was "platform- independent for IEEE 754 compliant systems". That claim is empirically false. scipy.fft's pocketfft uses SIMD vector kernels — AVX2/AVX-512 on x86_64, NEON on Apple Silicon — that reorder vectorized FP operations differently per build. IEEE 754 guarantees per-operation determinism, not associativity under reordering, so two correct platforms produce values that differ at ULP precision (~1e-14 at our magnitudes of 1-100). The SHA-256 of features_to_bytes() then explodes that ULP-level divergence into a totally different hash, which is what bug report #560 caught on macOS arm64: | Platform | numpy/scipy | sha256 (legacy) | |----------|-------------|-----------------| | Windows (Intel AVX-512) | 2.4.2 / 1.17.1 | 78b3fb… | | ruvultra (Linux x86_64) | 1.26.4 / 1.14.1 | 41dc56… | | ruv-mac-mini (Apple Silicon NEON) | 2.4.4 / 1.17.1 | 9b5e19… | ## The fix features_to_bytes() now np.round(.., HASH_QUANTIZATION_DECIMALS=9)s each array before packing as little-endian f64. That snaps the float bytes to a single canonical representation across SIMD backends. The 9-decimal precision is: - ~5 orders of magnitude above the worst-case ULP drift observed in probe-fft-platform.py measurements - Many orders of magnitude below any meaningful signal change (CSI phase precision is ~1e-3 rad; PSD bins differ by orders of magnitude) - Conservative — could tighten to 11-12 decimals if needed, but 9 leaves comfortable headroom for future scipy SIMD changes ## Probe-side verification scripts/probe-fft-platform.py now emits BOTH sha256_raw (unrounded, legacy) and sha256_quantized (new platform-invariant hash). Running it on Windows here produced: sha256_raw = 78b3fb4acb8cc18c3e870f92e29ee98143c7cac4767f2f71b0fc384a82b92f6e sha256_quantized = a587792c050cf697366b9bef4611050f9dc3af56624915ab2452c3c11362e79a quantization_decimals = 9 On Linux and macOS arm64 the maintainer should observe the SAME sha256_quantized value (and a different sha256_raw) — that's the fix working. ## What this PR does NOT do The published archive/v1/data/proof/expected_features.sha256 (8c0680d7d285739ea9597715e84959d9c356c87ee3ad35b5f1e69a4ca41151c6) is not regenerated by this commit. That step needs to run on a canonical CI platform (likely the Linux x86_64 host used for releases) AFTER this fix lands. The regeneration command is: python archive/v1/data/proof/verify.py --generate-hash After regeneration, every platform running ./verify will produce the same hash and the proof replay will be honestly cross-platform — which is what the ADR-028 trust-kill-switch promised. ## Files - archive/v1/data/proof/verify.py — add HASH_QUANTIZATION_DECIMALS=9 constant, quantize in features_to_bytes(), correct the misleading "platform-independent" claim in the docstring - scripts/probe-fft-platform.py — emit both raw and quantized hashes - scripts/fix-markers.json — RuView#560 marker prevents removing the np.round() call without explicit intent - CHANGELOG.md — Fixed entry under [Unreleased] documenting the change and flagging the expected_features.sha256 regeneration as a follow-up Co-Authored-By: claude-flow <ruv@ruv.net> * ci: fix verify-pipeline.yml working-directory from v1/ to archive/v1/ The verify-pipeline workflow's "Run pipeline verification" and "Run verification twice to confirm determinism" steps use `working-directory: v1` but `v1/` was archived to `archive/v1/` long ago. The workflow fails before verify.py even runs: ##[error]An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/RuView/RuView/v1'. No such file or directory Same v1 → archive/v1 path correction that already shipped for the ./verify wrapper (RuView#559 / PR #590) and the other lint workflows (RuView#489). Required to make the determinism check actually run on PR #609 (the quantize-before-hash work) — the canonical Linux hash needed for expected_features.sha256 will fall out of the next CI log once this fix lands. * fix(proof): regenerate expected_features.sha256 with the quantized canonical hash The hash on the previous line was the legacy pre-quantization value (8c0680d7d28573…), which by definition cannot match the quantized output that this branch's verify.py now produces. Replaced with the canonical Linux x86_64 hash captured from the CI run on this branch: d9985569b3ab833c74b7c9254df568bbb144879e2222edb0bcf2605bfd4c155b Source of truth: run 26005976495 / "Verify Pipeline Determinism (3.11)" on Ubuntu 24.04, Python 3.11.15, exercising the full verify.py pipeline on the 100 reference frames in archive/v1/data/proof/sample_csi_data.json. Reproducibility expectation now changes: - Linux x86_64 (canonical platform): sha256 = d9985569… ✓ this commit - macOS arm64 / Apple Silicon NEON: sha256 = d9985569… should match after quantization - Windows AMD64 (with pydantic-clean .env): sha256 = d9985569… should match after quantization If macOS arm64 still mismatches after this, the quantization decimals need to be tightened from 9 to 11 or 12 (HASH_QUANTIZATION_DECIMALS in verify.py); the headroom analysis in the original commit suggests 9 is safe but 9-decimal SIMD drift hasn't been measured in the full-pipeline output yet (only in the probe). Closes the maintainer-action-required item on PR #609. * fix(proof): bump quantization to 6 decimals (9 wasn't enough across Azure CI microarchs) Two back-to-back Ubuntu 24.04 / Python 3.11 / scipy 1.17 CI runs on PR #609 landed on different Azure VM microarchitectures and produced two different SHA-256s even after np.round(.., 9): Run 1: d9985569b3ab833c74b7c9254df568bbb144879e2222edb0bcf2605bfd4c155b Run 2: 37c49a1f6b87207fa9fc67f2d6a85c4417dd4a536573605fd175510d1dce7cbe Same JSON input, same byte count hashed (294,400), same Python version, same scipy version. The only variable is the underlying CPU pocketfft SIMD kernel. The full DSP pipeline (preprocess → biquad bandpass → FFT → PSD → variance accumulation) amplifies the ~1e-14 raw FFT divergence by several orders of magnitude — the actual drift at features_to_bytes() input can reach 1e-7 or worse, which is well within the 1e-9 quantization window I originally picked. Bumping to 6 decimals = parts per million. ~6 orders of magnitude headroom over observed pipeline-amplified ULP drift. Still far below any meaningful signal change (CSI phase precision ~1e-3 rad). Kept the probe constant in sync. Will trigger CI on this branch immediately after push; the new expected_features.sha256 will be regenerated from whichever microarch the next CI run lands on, but should be stable across all subsequent runs at 6-decimal quantization. * chore(probe): keep HASH_QUANTIZATION_DECIMALS in sync with verify.py (now 6) * fix(proof): regenerate expected_features.sha256 for 6-decimal quantization * ci: pin thread count to 1 for proof verification (scipy.fft threading non-determinism) |
||
|
rUv
|
50136c920d |
fix(archive/v1/pose-service): call sanitize_phase, not sanitize (closes #612) (#614)
Reported by @bannned-bit. archive/v1/src/services/pose_service.py:223:
sanitized_phase = self.phase_sanitizer.sanitize(phase_data)
PhaseSanitizer exposes the full-pipeline entry point as `sanitize_phase`
(unwrap_phase + remove_outliers + smooth_phase), not `sanitize`. The
shorter name doesn't exist on the class, so any path that reaches this
branch raises AttributeError mid-frame and crashes the pose service.
archive/v1/src/core/phase_sanitizer.py:266 is the canonical name:
def sanitize_phase(self, phase_data: np.ndarray) -> np.ndarray:
"""Sanitize phase data through complete pipeline."""
One-line rename. No other call sites use the wrong name; verified with
grep -rn 'phase_sanitizer\.sanitize\b' archive/v1/src/.
This is v1 archived code, but the proof verify path still exercises it
(./verify reaches into archive/v1/src/), so the bug was a latent
regression risk for the trust-kill-switch flow.
|
||
|
rUv
|
3bd70f7910 |
fix(sensing): adaptive_classifier sorts with unwrap_or(Equal) — NaN panic (closes #611) (#613)
Reported by @bannned-bit. v2/crates/wifi-densepose-sensing-server/src/
adaptive_classifier.rs:94 did:
sorted.sort_by(|a, b| a.partial_cmp(b).unwrap());
f64::partial_cmp returns None on NaN, so `.unwrap()` panics. CSI data
from real ESP32 hardware can produce NaN (silent DSP div-by-zero,
empty buffer, etc.), and this code path runs on every frame in the
classify() hot path — a single NaN frame kills the entire sensing
server process.
Fix swaps for unwrap_or(Ordering::Equal), matching the pattern the
same file already uses at lines 149-150 and 155 (those sites were
already NaN-safe; this site was an oversight).
Scoped audit: greped the v2/ tree for `partial_cmp(b).unwrap()`. The
other 3 hits are in #[cfg(test)] blocks (spectrogram.rs:269,
depth.rs:234, connectivity.rs:477) where panic-on-NaN is acceptable
because test inputs are controlled. Only adaptive_classifier.rs:94
was a production-path crash.
Severity: critical per reporter — runtime panic on real-world data.
Patch: 1-line behavioural change + comment.
|
||
|
rUv
|
6f5ac3aa5a |
fix(ui): clamp deltaTime to 1ms in pose-renderer FPS calc (#519 Bug 2) (#610)
When two render frames land in the same performance.now() tick, `currentTime - lastFrameTime === 0`, so `fps = 1000 / 0 = Infinity`, and `averageFps = averageFps * 0.9 + Infinity * 0.1 = Infinity` poisons the EMA forever after a single zero-dt tick. The UI then displays "Infinity FPS" until reload. Floor deltaTime at 1 ms before the division. That caps displayed FPS at 1000 (far above any real render rate so the cap is never observed in practice) but keeps the EMA finite. Reported in #519 ("Bug 2 — FPS shows Infinity") by @kapilsoni2013 on a 3-node ESP32-S3-WROOM multi-node setup with edge-tier 1 + 2. |
||
|
rUv
|
1b155ad027 |
chore: remove empty stub crates wifi-densepose-{api,db,config} (closes #578) (#608)
Each of these crates was a single-line doc-comment placeholder: 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) with empty [dependencies] in their Cargo.toml and zero references from any source file or Cargo.toml in the workspace (verified by `grep -rln wifi-densepose-api/-db/-config` across `v2/`). They were reserved early for an envisioned REST/database/config split that never materialised. The functionality these would have provided is covered today by: - REST/WS: wifi-densepose-sensing-server (Axum) - Config: per-crate config + CLI args in sensing-server and desktop - DB: no persistent state; system is real-time Removal prevents `cargo` from listing dead crates, shipping empty published artifacts to crates.io, or wasting reviewer attention. If any of these names is needed in the future, reintroduce them with a real implementation. Per the issue reporter (@bannned-bit / Matad0r) #578 explicitly listed "OR be removed from workspace members until implementation starts" as an acceptable resolution. Updated: - `v2/Cargo.toml`: drop the three members (with inline comment explaining why) - `v2/Cargo.lock`: regenerated by cargo check - `CLAUDE.md`: drop the three rows from the crate table and the publishing order list - `CHANGELOG.md`: add an `[Unreleased] / Removed` entry Verified: - `cd v2 && cargo check --workspace --no-default-features` -> finished in 48s, no errors (warnings unchanged) |
||
|
Mathew005
|
fa28318bae | fix(led): disable onboard WS2812 LED during CSI collection (#273) | ||
|
Grzegorz Malopolski
|
ec73109d57 |
docs: add visual architecture overview images (#208)
Co-authored-by: Grzegorz Małopolski <grzegorzmalopolskipraca@gmail.com> |
||
|
OrbisAI Security
|
acbd3ff13c |
refactor(mmwave): use sizeof() in mr60_process_frame bounds checks (#414)
Automated security fix generated by Orbis Security AI |
||
|
dependabot[bot]
|
07086c5d9d |
chore(deps): bump react-dom from 19.2.0 to 19.2.6 in /ui/mobile (#463)
Bumps [react-dom](https://github.com/facebook/react/tree/HEAD/packages/react-dom) from 19.2.0 to 19.2.6. - [Release notes](https://github.com/facebook/react/releases) - [Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md) - [Commits](https://github.com/facebook/react/commits/v19.2.6/packages/react-dom) --- updated-dependencies: - dependency-name: react-dom dependency-version: 19.2.5 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
0310b1fa9a |
chore(deps): bump @tauri-apps/plugin-dialog (#462)
Bumps [@tauri-apps/plugin-dialog](https://github.com/tauri-apps/plugins-workspace) from 2.6.0 to 2.7.0. - [Release notes](https://github.com/tauri-apps/plugins-workspace/releases) - [Commits](https://github.com/tauri-apps/plugins-workspace/compare/log-v2.6.0...log-v2.7.0) --- updated-dependencies: - dependency-name: "@tauri-apps/plugin-dialog" dependency-version: 2.7.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
9daa8c3078 |
chore(deps): update asyncio-mqtt requirement from >=0.11.0 to >=0.16.2 (#460)
Updates the requirements on [asyncio-mqtt](https://github.com/sbtinstruments/asyncio-mqtt) to permit the latest version. - [Release notes](https://github.com/sbtinstruments/asyncio-mqtt/releases) - [Changelog](https://github.com/empicano/aiomqtt/blob/main/CHANGELOG.md) - [Commits](https://github.com/sbtinstruments/asyncio-mqtt/commits) --- updated-dependencies: - dependency-name: asyncio-mqtt dependency-version: 0.16.2 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
ffa808ed4b |
chore(deps-dev): bump eslint from 10.0.2 to 10.2.1 in /ui/mobile (#459)
Bumps [eslint](https://github.com/eslint/eslint) from 10.0.2 to 10.2.1. - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](https://github.com/eslint/eslint/compare/v10.0.2...v10.2.1) --- updated-dependencies: - dependency-name: eslint dependency-version: 10.2.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
59dbb76757 |
chore(deps-dev): bump @typescript-eslint/eslint-plugin in /ui/mobile (#458)
Bumps [@typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin) from 8.56.1 to 8.59.3. - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.59.3/packages/eslint-plugin) --- updated-dependencies: - dependency-name: "@typescript-eslint/eslint-plugin" dependency-version: 8.59.1 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
4ecc053a27 |
chore(deps-dev): bump typescript in /v2/crates/wifi-densepose-desktop/ui (#456)
Bumps [typescript](https://github.com/microsoft/TypeScript) from 5.9.3 to 6.0.3. - [Release notes](https://github.com/microsoft/TypeScript/releases) - [Commits](https://github.com/microsoft/TypeScript/compare/v5.9.3...v6.0.3) --- updated-dependencies: - dependency-name: typescript dependency-version: 6.0.3 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
5170b99aca |
chore(deps): bump codecov/codecov-action from 4 to 6 (#454)
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 4 to 6. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/codecov/codecov-action/compare/v4...v6) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
c16dc9f80a |
chore(deps): bump actions/setup-python from 5 to 6 (#453)
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5 to 6. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](https://github.com/actions/setup-python/compare/v5...v6) --- updated-dependencies: - dependency-name: actions/setup-python dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
04ccfcde56 |
chore(deps-dev): bump prettier from 3.8.1 to 3.8.3 in /ui/mobile (#452)
Bumps [prettier](https://github.com/prettier/prettier) from 3.8.1 to 3.8.3. - [Release notes](https://github.com/prettier/prettier/releases) - [Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md) - [Commits](https://github.com/prettier/prettier/compare/3.8.1...3.8.3) --- updated-dependencies: - dependency-name: prettier dependency-version: 3.8.3 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
4d45add824 |
chore(deps): bump react-dom and @types/react-dom (#451)
Bumps [react-dom](https://github.com/facebook/react/tree/HEAD/packages/react-dom) and [@types/react-dom](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react-dom). These dependencies needed to be updated together. Updates `react-dom` from 18.3.1 to 19.2.5 - [Release notes](https://github.com/facebook/react/releases) - [Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md) - [Commits](https://github.com/facebook/react/commits/v19.2.5/packages/react-dom) Updates `@types/react-dom` from 18.3.7 to 19.2.3 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react-dom) --- updated-dependencies: - dependency-name: react-dom dependency-version: 19.2.5 dependency-type: direct:production update-type: version-update:semver-major - dependency-name: "@types/react-dom" dependency-version: 19.2.3 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
562cb7461f |
chore(deps): bump anchore/scan-action from 3 to 7 (#450)
Bumps [anchore/scan-action](https://github.com/anchore/scan-action) from 3 to 7. - [Release notes](https://github.com/anchore/scan-action/releases) - [Changelog](https://github.com/anchore/scan-action/blob/main/RELEASE.md) - [Commits](https://github.com/anchore/scan-action/compare/v3...v7) --- updated-dependencies: - dependency-name: anchore/scan-action dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
fad6828697 |
chore(deps): bump docker/metadata-action from 5 to 6 (#449)
Bumps [docker/metadata-action](https://github.com/docker/metadata-action) from 5 to 6. - [Release notes](https://github.com/docker/metadata-action/releases) - [Commits](https://github.com/docker/metadata-action/compare/v5...v6) --- updated-dependencies: - dependency-name: docker/metadata-action dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
807bf0b32a |
chore(deps): bump docker/build-push-action from 5 to 7 (#448)
Bumps [docker/build-push-action](https://github.com/docker/build-push-action) from 5 to 7. - [Release notes](https://github.com/docker/build-push-action/releases) - [Commits](https://github.com/docker/build-push-action/compare/v5...v7) --- updated-dependencies: - dependency-name: docker/build-push-action dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
4b602c79dd |
chore(deps): bump actions/setup-node from 4 to 6 (#447)
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 4 to 6. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](https://github.com/actions/setup-node/compare/v4...v6) --- updated-dependencies: - dependency-name: actions/setup-node dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |