Taskmanager Pro
Windows-first process inspector. Live telemetry, guarded termination, Rust-helper roadmap.
TL;DR
- 11-part design spec before any code.
- Electron + React renderer; planned Rust native helper.
- Live process telemetry with rolling history.
- Role-based grouping (system / service / user / helper).
- Guarded termination flow — no accidental kill -9.
Architecture
Electron renders the UI. A native Rust helper does the heavy Windows work. Telemetry flows one way.
Screens
Overview · triage-first
Concept render from the design spec. Live resource strip across the top, three compact triage tables below: top impact processes, sustained slowdown, and items that need a human review.
Processes + detail drawer
Virtualized 60fps table on the left, sticky detail drawer on the right. Drawer shows live impact, sustained averages over the last 15 min, risk explainability, process tree, full path, and guarded actions (open file, end task).
Suspicious processes
Processes flagged by the risk engine, ranked by score, with explainable reasons (unsigned publisher, mimics svchost, hidden window, etc.) and guarded actions per row. End task always confirms.
Problem
Windows Task Manager tells you what's running but not what it's doing to your machine. A high-CPU process gets a name and a number; you don't get a story. The diagnostic loop is missing.
Approach
Electron + React for a fast, web-shaped UI. TypeScript through and through. A native Rust helper (planned milestone) for the lower-level Windows APIs that Node can't reach cleanly. Live process table, detail drawer with rolling history, role-based categorization (system / service / user / helper), guarded termination flow.
Deep dive
Why a Rust helper instead of pure Node
Some Windows process telemetry — accurate per-process disk I/O, GPU stats, sandbox info — is awkward or impossible from Node. A small Rust helper called over IPC keeps the renderer pure web while letting the data layer reach what it needs without N-API gymnastics.
use sysinfo::{ProcessExt, System, SystemExt};
#[derive(serde::Serialize)]
pub struct ProcessSnapshot {
pub pid: u32,
pub name: String,
pub cpu: f32,
pub memory_kb: u64,
pub role: &'static str,
}
pub fn snapshot() -> Vec<ProcessSnapshot> {
let mut sys = System::new_all();
sys.refresh_processes();
sys.processes()
.iter()
.map(|(pid, p)| ProcessSnapshot {
pid: pid.as_u32(),
name: p.name().to_string(),
cpu: p.cpu_usage(),
memory_kb: p.memory(),
role: classify(p),
})
.collect()
}
fn classify(p: &sysinfo::Process) -> &'static str {
// ...heuristics: parent PID, signing, path prefix...
"user"
}Spec-first, code-second
An 11-part spec sounds like overkill for a one-developer project. But the cost of writing 'here are the open decisions' before opening an editor is hours. The cost of finding them mid-implementation is days. The spec sits in the repo as living context.
Outcome
Pre-implementation: 11-part specification document suite covering product analysis, technical architecture, UX, user flows, acceptance criteria, AI implementation roadmap, rule catalog, open decisions, gap analysis, dev protocol, and agent branching. Build kicks off from a known-good spec.
Related
