mirror of
https://github.com/ruvnet/RuView
synced 2026-07-25 17:51:48 +00:00
7bd188ab60
Speculative 10-20y vision thread covering three concrete vertical sketches: * V1 stress-responsive lighting (5y) — breathing-rate baseline + warm-shift lights * V2 adaptive HVAC for thermal-stress envelopes (10y) — published HVAC-personalisation 15-20% energy savings * V3 conversational appliances respecting attention state (15y) — don't interrupt during focused work Maps existing RuView components to each: 5 already shipped (breathing rate detector, occupancy gates via cog-pose / cog-count, motion intensity, partial RollingP95 baseline learner, MCP API via ADR-104), 4 still to build (full per-room baseline learner, state classifier model, MCP vitals subscribe tool, consent UI). Ethical framework drafted as binding constraints any product must honour: 1. Opt-in by default — sensing on only after active enable 2. Data stays on-device — per-second values never cross the building boundary 3. Override is one tap — physical kill switch must work without WiFi/cloud 6-row privacy threat model with mitigations: compromised appliance, MCP raw-signal leak, adversarial poisoning (mitigated by R7 multi-link consistency), long-term re-identification, insurance/employer access, non-consenting cohabitants. Honest scope: clinical breathing-rate-as-stress literature is lab-condition adults; real-home generalisation unproven. R14 is CSI-only (RSSI loses the per-subcarrier shape needed for shallow-breathing-during-focus signature), bounds rollout to ESP32-S3-class deployments. Connections established to R5, R7, R8, ADR-103, ADR-104. Identifies ruview_vitals_subscribe as the highest-leverage next MCP tool addition. Coordination: ticks/tick-7.md, no PROGRESS.md touch.
2.3 KiB
2.3 KiB
Tick 7 — 2026-05-22 05:14 UTC
Thread: R14 (empathic appliances) Verdict: Speculative 10-20y vision note with concrete vertical sketches, ethical framework, privacy threat model, and infrastructure-gap inventory.
What shipped
docs/research/sota-2026-05-22/R14-empathic-appliances.md— research note covering:- Three concrete vertical sketches (stress-responsive lighting / adaptive HVAC / attention-respecting conversational appliances) with timelines (5y / 10y / 15y).
- Infrastructure inventory — which existing RuView components map to which empathic-appliance category. 5 ✅ in-repo, 4 ⚠️/❌ to-build.
- Ethical framework (opt-in-by-default, data-stays-on-device, override-one-tap) committed in writing as constraints any product must honour.
- 6-row privacy threat model with concrete mitigations.
- Honest scope: lab-condition literature doesn't validate real-home generalisation; no per-occupant identity yet; appliance integration half is out of repo scope.
Why this matters for the loop
R14 is the first explicitly speculative vision thread (R5/R7/R8/R9/R10/R12 were all experimental or physics). It catalogues the product-level surface area for the longest-horizon items, which informs:
- Which sensing primitives we should invest in next (per-room baseline learner is the clearest gap).
- Which ADRs to write next (consent/override is a separate ADR — possibly ADR-105).
- Which MCP tools to add to
@ruv/ruview-mcp(the deferredruview_vitals_subscribeis now the highest-leverage next addition per ADR-104 + R14).
Connections established
- R14 explicitly cross-links to R5 (saliency is task-specific), R8 (CSI required, not RSSI), R7 (adversarial poisoning defence), ADR-104 (hands-off appliance API surface), ADR-103 (per-room occupancy gate).
- The infrastructure-gap inventory (5 in-repo, 4 to-build) is a useful artefact for any future product roadmap discussion.
Coordination
ticks/tick-7.md convention. No PROGRESS.md touch.
Major notes from prior tick
R10 (PR not auto-created due to bash flow issue) ended up committed directly to main and pushed in this tick. Future-tick reminder: always check git branch --show-current before git commit. The cron prompt assumes branch hygiene that the bash plumbing sometimes breaks under back-to-back tick pressure.