Project Roadmap & Architecture

[SickleFire]

Hi contributors and users! 👋

Now that the core command architecture for m-vis is taking shape, I want to map out our priorities for the next few development cycles. Because m-vis targets both Windows and Linux out-of-process memory visualization, we have a lot of moving parts.

Right now, m-vis is separated into these layers:

1. CLI Layer - The headless entry point for the application. It handles command line argument parsing, executes standalone commands and outputs structured data.
2. TUI Layer - The interactive presentation view. Built for terminal-based visualization, this layer translates memory states into readable visual panels, driving user interactions, real-time data table streams, and terminal-friendly graphs.
3. Windows OS Layer - Our low-level target interface for Windows systems. It orchestrates process attachment via OpenProcess, safe cross-process memory scanning via ReadProcessMemory, and Win32 heap segment enumeration (HeapWalk).
4. Linux OS Layer - Our low-level target interface for Linux systems. It parses virtual memory maps via /proc/[pid]/maps or /proc/[pid]/smaps.

What should we prioritize next?

To align our goals with these layers, I'd love to get community feedback on which areas we should tackle first:

1. The TUI Layer: Building out the terminal user interface visualizer panels (Hex viewer, process selection tree, live graph of heap utilization).
2. OS Layers (Windows/Linux): Implementing the low-level backend for our address-aware snapshot diff engine. This involves writing the platform-specific abstractions to poll and diff active pointers over time to catch true memory leaks.
3. CLI Layer: Expanding our standalone command suite so users can run memory leak tracking and module diagnostics in headless environments (like CI/CD stress-test pipelines) without needing to boot up the full TUI.

Which layer's features would be most useful to your workflow right now?