Dev Process Tracker: Local Service Management with a CLI + TUI

Source: Dev.to

What I Built

I built Dev Process Tracker (devpt), a local development service manager with both CLI and TUI workflows.

It is built for a common reality: multiple local services, mixed startup methods, and failures that are hard to diagnose quickly.

With devpt, I can:

• register known services (add)
• run lifecycle actions (start, stop, restart)
• inspect runtime state (ls, status)
• check logs (logs)
• switch to an interactive workflow (devpt)

Managed vs. Discovered (why both matter)

This is a core design choice.

• Managed – services you explicitly define in devpt (name, cwd, command, expected ports)
• Discovered – anything currently listening on local TCP ports, even if started outside devpt

Example

1. You register a frontend in devpt with npm run dev on port 3100.
2. An older npm run dev process from another terminal is still running on 3100.

devpt ls --details shows both, so you can spot the duplicate and stop the stale process quickly.

Why not just PM2, Docker Compose, or make targets?

Those tools are useful, but they solve different parts of the problem.

devpt focuses on cross‑stack local runtime visibility + lifecycle control + crash diagnostics in one interface.

Demo

Repository:

---

A Day in the Life

Start the day: what’s already running?

./devpt ls --details

This gives you a single inventory view of everything currently listening on your machine, both services you’ve explicitly registered with devpt and processes that were started elsewhere and forgotten about.

Bring up your local stack

./devpt add frontend ./sandbox/servers/node-basic "npm run dev" 3100
./devpt add api ./sandbox/servers/python-basic "python3 server.py" 3300
./devpt start frontend
./devpt start api

Here, devpt is managing the same kinds of commands developers actually run every day, not simplified or synthetic examples.

Investigate a problem and recover

./devpt status frontend
./devpt logs frontend --lines 60
./devpt restart frontend
./devpt stop api

When something goes wrong, control and diagnosis stay in one place. You can see crash state, inspect recent logs, and take action without switching tools or terminals.

Switch to interactive mode

./devpt

The same workflow is available in a TUI, making it practical to leave running during the day and interact with it as your local environment changes.

My Experience with GitHub Copilot CLI

I used Copilot CLI as a high‑speed drafting and reasoning partner, then manually constrained behavior to fit project requirements.

Example 1: command validation

Prompt

gh copilot suggest "add command validation for managed service commands and include tests for blocked patterns"

Impact on final product

• Accelerated initial validation/test scaffold.
• Final logic was tightened manually to project‑safe patterns and clearer CLI errors.

Example 2: crash diagnostics design

Prompt

gh copilot suggest "show crash reason and recent log tail in status command for crashed services"

Impact on final product

• Helped shape the CRASH DETAILS section design.
• Final output and heuristics were edited to reduce noise and improve signal.

Example 3: what did not work

One early suggestion pushed a broader TUI refactor than needed. I rejected that direction and kept the CLI‑first design.

Why I Dropped the Full‑State Rewrite

The risk of interaction regressions was too high for the challenge scope, so I kept the focus on:

• Focused UI behavior improvements
• No disruptive state‑model rewrite

This trade‑off kept the tool stable while still improving usability.

Net Effect on My Workflow

• Faster implementation drafts
• Better early edge‑case discovery
• Tighter feedback loops during test writing
• Final behavior remained intentionally human‑reviewed

Detailed prompt‑level evidence is documented in:

• HOW_COPILOT_CLI_WAS_USED.md

Who This Is For

devpt is for developers running mixed local stacks (Node, Python, Go, containers) who need reliable runtime visibility and fast failure diagnosis.

Core question it answers: What is actually running, and what should I do next?