mirror of
https://github.com/ruvnet/RuView
synced 2026-07-17 16:33:18 +00:00
rUv
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.
57 lines
2.2 KiB
Markdown
57 lines
2.2 KiB
Markdown
# 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
|
|
|
|
1. **wifi-densepose-core**: Foundation types, traits, and error handling shared across all crates
|
|
2. **wifi-densepose-signal**: CSI data processing, phase sanitization, FFT, feature extraction
|
|
3. **wifi-densepose-nn**: Neural network inference using ONNX Runtime, Candle, or tch-rs
|
|
4. **wifi-densepose-api**: HTTP/WebSocket server using Axum
|
|
5. **wifi-densepose-db**: Database operations with SQLx
|
|
6. **wifi-densepose-config**: Configuration loading and validation
|
|
7. **wifi-densepose-hardware**: Router and hardware interfaces
|
|
8. **wifi-densepose-wasm**: WebAssembly bindings for browser deployment
|
|
9. **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
|
|
|
|
## References
|
|
- [Cargo Workspaces](https://doc.rust-lang.org/cargo/reference/workspaces.html)
|
|
- [ruvector crate structure](https://github.com/ruvnet/ruvector)
|