mirror of https://github.com/ruvnet/RuView synced 2026-06-19 11:53:19 +00:00

Files

T

rUv f49c722764 chore(repo): rename rust-port/wifi-densepose-rs → v2/ (flatten to one level) (#427 )

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.

2026-04-25 21:28:13 -04:00

2.2 KiB

Raw Permalink Blame History

ADR-001: Rust Workspace Structure

Status

Accepted

Context

We need to port the WiFi-DensePose Python application to Rust for improved performance, memory safety, and cross-platform deployment including WASM. The architecture must be modular, maintainable, and support multiple deployment targets.

Decision

We will use a Cargo workspace with 9 modular crates:

wifi-densepose-rs/
├── Cargo.toml                    # Workspace root
├── crates/
│   ├── wifi-densepose-core/      # Core types, traits, errors
│   ├── wifi-densepose-signal/    # Signal processing (CSI, phase, FFT)
│   ├── wifi-densepose-nn/        # Neural networks (DensePose, translation)
│   ├── wifi-densepose-api/       # REST/WebSocket API (Axum)
│   ├── wifi-densepose-db/        # Database layer (SQLx)
│   ├── wifi-densepose-config/    # Configuration management
│   ├── wifi-densepose-hardware/  # Hardware abstraction
│   ├── wifi-densepose-wasm/      # WASM bindings
│   └── wifi-densepose-cli/       # CLI application

Crate Responsibilities

wifi-densepose-core: Foundation types, traits, and error handling shared across all crates
wifi-densepose-signal: CSI data processing, phase sanitization, FFT, feature extraction
wifi-densepose-nn: Neural network inference using ONNX Runtime, Candle, or tch-rs
wifi-densepose-api: HTTP/WebSocket server using Axum
wifi-densepose-db: Database operations with SQLx
wifi-densepose-config: Configuration loading and validation
wifi-densepose-hardware: Router and hardware interfaces
wifi-densepose-wasm: WebAssembly bindings for browser deployment
wifi-densepose-cli: Command-line interface

Consequences

Positive

Clear separation of concerns
Independent crate versioning
Parallel compilation
Selective feature inclusion
Easier testing and maintenance
WASM target isolation

Negative

More complex dependency management
Initial setup overhead
Cross-crate refactoring complexity

2.2 KiB Raw Permalink Blame History