mirror of
https://github.com/ruvnet/RuView.git
synced 2026-04-26 13:10:40 +00:00
f49c722764
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. |
||
|---|---|---|
| .. | ||
| chci-domain-model.md | ||
| deployment-platform-domain-model.md | ||
| hardware-platform-domain-model.md | ||
| README.md | ||
| ruvsense-domain-model.md | ||
| sensing-server-domain-model.md | ||
| signal-processing-domain-model.md | ||
| training-pipeline-domain-model.md | ||
| wifi-mat-domain-model.md | ||
Domain Models
This folder contains Domain-Driven Design (DDD) specifications for each major subsystem in RuView.
DDD organizes the codebase around the problem being solved — not around technical layers. Each bounded context owns its own data, rules, and language. Contexts communicate through domain events, not by sharing mutable state. This makes the system easier to reason about, test, and extend — whether you're a person or an AI agent.
Models
| Model | What it covers | Bounded Contexts |
|---|---|---|
| RuvSense | Multistatic WiFi sensing, pose tracking, vital signs, edge intelligence | 7 contexts: Sensing, Coherence, Tracking, Field Model, Longitudinal, Spatial Identity, Edge Intelligence |
| Signal Processing | SOTA signal processing: phase cleaning, feature extraction, motion analysis | 3 contexts: CSI Preprocessing, Feature Extraction, Motion Analysis |
| Training Pipeline | ML training: datasets, model architecture, embeddings, domain generalization | 4 contexts: Dataset Management, Model Architecture, Training Orchestration, Embedding & Transfer |
| Hardware Platform | ESP32 firmware, edge intelligence, WASM runtime, aggregation, provisioning | 5 contexts: Sensor Node, Edge Processing, WASM Runtime, Aggregation, Provisioning |
| Sensing Server | Single-binary Axum server: CSI ingestion, model management, recording, training, visualization | 5 contexts: CSI Ingestion, Model Management, CSI Recording, Training Pipeline, Visualization |
| WiFi-Mat | Disaster response: survivor detection, START triage, mass casualty assessment | 3 contexts: Detection, Localization, Alerting |
| CHCI | Coherent Human Channel Imaging: sub-millimeter body surface reconstruction | 3 contexts: Sounding, Channel Estimation, Imaging |
How to read these
Each model defines:
- Ubiquitous Language — Terms with precise meanings used in both code and conversation
- Bounded Contexts — Independent subsystems with clear responsibilities and boundaries
- Aggregates — Clusters of objects that enforce business rules (e.g., a PoseTrack owns its keypoints)
- Value Objects — Immutable data with meaning (e.g., a CoherenceScore is not just a float)
- Domain Events — Things that happened that other contexts may care about
- Invariants — Rules that must always be true (e.g., "drift alert requires >2sigma for >3 days")
- Anti-Corruption Layers — Adapters that translate between contexts without leaking internals
Related
- Architecture Decision Records — Why each technical choice was made
- User Guide — Setup and API reference