## P2.4 — light-theme contrast
- --ink-3 from #6b7684 (3.7:1 on bg-1) → #54606e (~5.4:1, AA-compliant)
- --ink-4 from #9ba4b0 → #7a8390 (better incidental-text legibility)
- --line/--line-2 firmed (#d8dde3 / #c1c8d1) for clearer panel edges
- Dark-theme palette unchanged
## P2.6 — keyboard arrow-key scene navigation
nv-scene now listens for keydown on window:
- Tab from document body → selects first draggable
- Tab / Shift-Tab cycles through draggables
- Arrow keys nudge selected item by 8 px
- Shift+Arrow nudges by 32 px
- Esc deselects
- Position changes persist via scenePositions signal
ADR-093 §2/§3 updated to mark P2.4 and P2.6 resolved. Iteration N
added to §5 plan. Status header updated to Implemented (21/21 gaps
closed).
Co-Authored-By: claude-flow <ruv@ruv.net>
This folder contains 44 Architecture Decision Records (ADRs) that document every significant technical choice in the RuView / WiFi-DensePose project.
Why ADRs?
Building a system that turns WiFi signals into human pose estimation involves hundreds of non-obvious decisions: which signal processing algorithms to use, how to bridge ESP32 firmware to a Rust pipeline, whether to run inference on-device or on a server, how to handle multi-person separation with limited subcarriers.
ADRs capture the context, options considered, decision made, and consequences for each of these choices. They serve three purposes:
Institutional memory — Six months from now, anyone (human or AI) can read why we chose IIR bandpass filters over FIR for vital sign extraction, not just see the code.
AI-assisted development — When an AI agent works on this codebase, ADRs give it the constraints and rationale it needs to make changes that align with the existing architecture. Without them, AI-generated code tends to drift — reinventing patterns that already exist, contradicting earlier decisions, or optimizing for the wrong tradeoffs.
Review checkpoints — Each ADR is a reviewable artifact. When a proposed change touches the architecture, the ADR forces the author to articulate tradeoffs before writing code, not after.
ADRs and Domain-Driven Design
The project uses Domain-Driven Design (DDD) to organize code into bounded contexts — each with its own language, types, and responsibilities. ADRs and DDD work together:
ADRs define boundaries: ADR-029 (RuvSense) established multistatic sensing as a separate bounded context from single-node CSI. ADR-042 (CHCI) defined a new aggregate root for coherent channel imaging.
DDD models define the language: The RuvSense domain model defines terms like "coherence gate", "dwell time", and "TDM slot" that ADRs reference precisely.
Together they prevent drift: An AI agent reading ADR-039 knows that edge processing tiers are configured via NVS keys, not compile-time flags — because the ADR says so. The DDD model tells it which aggregate owns that configuration.
How ADRs are structured
Each ADR follows a consistent format:
Context — What problem or gap prompted this decision
Decision — What we chose to do and how
Consequences — What improved, what got harder, and what risks remain
References — Related ADRs, papers, and code paths
Statuses: Proposed (under discussion), Accepted (approved and/or implemented), Superseded (replaced by a later ADR).
