# TUI Resource Monitor Plan

## Language Choice: Rust

Why Rust for this:
- Produces a single static-ish native binary easily (great for self-contained executables).
- Strong ecosystem for TUIs (`ratatui`, `crossterm`) and system stats (`sysinfo`).
- Good performance and low runtime overhead for frequent refresh loops.

## Plan

1. Define scope and MVP metrics
- CPU usage (total + per core), memory, swap, disk usage, network throughput, process count, uptime.
- Target Linux first (then add macOS/Windows support if needed).

2. Bootstrap project structure
- Create a Rust CLI app with modules for `collectors`, `ui`, `state`, and `config`.
- Add dependencies: `ratatui`, `crossterm`, `sysinfo`, `anyhow`, `clap`, `serde` (optional config).

3. Implement data collection layer
- Build a polling engine (e.g., 500ms–1s interval) that samples resource metrics.
- Normalize all values into a shared state model for UI rendering.
- Add delta-based metrics (network/disk rates) from successive samples.

4. Build TUI layout and rendering
- Header: host info, uptime, refresh rate.
- Main panes: CPU, memory/swap, disk, network.
- Footer/help bar with keybindings.
- Add responsive layout for small terminal sizes.

5. Add interaction model
- Keybindings: quit, pause/resume, change refresh interval, toggle detailed view.
- Optional sorting/filtering for top processes view.

6. Packaging and self-contained build
- Configure release profile (`lto`, `panic=abort`, `strip`) for small fast binary.
- Document build command for optimized executable.
- Optional: static linking strategy for fully portable Linux binary.

7. Quality gates
- Unit tests for metric calculations and rate/delta logic.
- Smoke test for startup/render loop.
- Run `clippy` and `fmt` checks.

8. Delivery
- Provide binary + README with usage, keybindings, and supported platforms.
- Include known limitations and next-step roadmap (alerts, historical sparklines, per-process drilldown).