Process View
Process Visibility
Gantry learned to show the process groups a build run owns, from terminal commands to the TUI and MCP.
2 milestones 6 tasks 15 agents
3 plan 6 execute 8 review 1 fix
337k peak context
198k median execute
11h 16m total 27m 2s per task
2h 39m execute 1h 1m review
222 edits 711 commands
claude harness
143.3M tokens in 628.2k tokens out
$110.95 nominal cost
This run turned the process-safety work from something Gantry could enforce into something an operator and an attached assistant could inspect. The source plan was about visibility without control: keep discovery read-only, trust the roster and process identity checks, and render the same process picture through every surface that needs it.
The decomposition first built the durable data and terminal readers, then carried that shared model into the build-run interface and the MCP server. The result still stands in the tree as a process model, a repo-scoped `ps` command, a `status` process line, a TUI processes overlay, and a `list_processes` read tool.
How this walkthrough is structured
Feature
What did the run build and ship?
Gantry now reports a run's recorded process groups through terminal, TUI, and MCP readers that share one verified process model.
Build
How did Gantry structure the work?
The run separated process visibility into a shared model milestone and a surface milestone, with only the model/status sprint needing repair before the later readers composed on top.
Milestone 1
Process Model and Surfaces
4 tasks 12 agents 2h 40m wall time 256k peak context $57.29 nominal cost
The current tree still has `src/process_view.rs` as the shared reporting model, with explicit ownership, roster history, live sampling, state labels, absent handling, and payload formatting. `src/commands.rs` still routes `status` and `ps` through that model instead of reading the roster in each renderer. The archived plan and CLI docs also remain aligned with the design: process reporting is discovery only, and `list` was not widened with process columns.
This milestone carried the core contract for the whole run: one process picture, then terminal surfaces that proved it. The brief kept it bounded by making the roster, ownership, and live process sample the only sources, while leaving the TUI and MCP readers for the next milestone. Its child sprints mostly stayed green, but the model/status cut exposed the hard boundary and needed a repair pass before the rest of the terminal work could depend on it. Reconciliation later had to fold this milestone with the second one, which is where overlapping surface code met.
Roster Records
2 agents 24m 7s wall time 148k peak context 46.7k tokens out $7.37 nominal cost
`src/engine/process_roster.rs` still carries structured `ProcessAttribution`, launch and reap timestamps, and a `replay_history` path for reporting consumers. The file documents that the roster is a join key, not a metrics store, and keeps absent fields optional for older records. Spawn attribution is still typed by kind, including agent stages, assistant turns, utility one-shots, gate commands, and pattern scripts.
This sprint was the prerequisite data change, small enough for one agent because it touched recording and parsing rather than any display surface. The brief asked it to enrich append-only roster records with structured attribution and lifecycle times while keeping old records readable. Its boundary held: the checks went green without a repair stage, and later sprints could treat the roster history as an input contract instead of a guess. The duplicate ledger row reflects the milestone wrapper's retry notation rather than a sprint restart in the run facts.
Process Model
3 agents 57m 55s wall time 233k peak context 111.3k tokens out $17.88 nominal cost 1 fix
The model module still owns the verdicts for live, stray, reaped, exited, and stale groups, and it explicitly refuses to credit a reused pid with another process's usage. `status` still asks that model for its process line and omits the line when process data is absent rather than printing an invented zero. The same module also owns shared wording such as the absent marker and stop remedy, which later surfaces reuse.
This was the difficult cut in the first milestone. It had to join ownership, roster history, and live process identity while publishing the state vocabulary every later reader would use. The gate went red after review and Gantry ran a fix before accepting it, which matches the risk in the brief: a small error here would leak into every surface. Because the sprint stopped at the model and `status`, the repair stayed local instead of being tangled with the terminal table or overlay.
Fleet Monitoring
2 agents 42m 5s wall time 256k peak context 116.1k tokens out $17.54 nominal cost
`gantry ps` still renders unfinished runs from the registry as sections, with owner information and current process-group rows sourced from `process_view`. The process model samples usage at read time and keeps every sampled field optional, so unreadable machine data remains visibly absent. The CLI documentation describes the fleet form as repo-scoped, read-only, and intentionally separate from `list`.
This sprint added live usage sampling and replaced the no-argument `ps` readout, after the model already defined which entries were safe to sample. The cut was narrow: live rows, fleet sections, local column sizing, and proof that discovery did not signal. It stayed green, which says the previous sprint had already absorbed the identity and absent-data complexity. The next sprint could then focus on history and watch behavior without changing the sampled entry contract.
Forensics and Watch
2 agents 24m 21s wall time 165k peak context 50.9k tokens out $9.17 nominal cost
The named `ps` form still resolves a run name with the common rules and shows the full recorded history, including reaped and exited groups. `--watch` still recomputes a complete frame on an interval and leaves process control to `stop`. The CLI docs preserve the distinction between the compact fleet form and the forensic form with launch and reap times.
This sprint closed the terminal milestone by adding the by-name forensic form and the watch loop on the already-built renderer. The brief was mostly about scope discipline: show recorded history, keep name resolution consistent, redraw plainly, and do not turn watching into a TUI or daemon. It passed without repair, which fits a surface extension over a proven model. Its output became the terminal reference that the later overlay and MCP tool could match.
Milestone 2
Process Overlay and APIs
2 tasks 7 agents 1h 37m wall time 337k peak context $46.42 nominal cost
The current tree still exposes process data in the build-run TUI and over the run-scoped MCP server. Both readers call the shared model and reuse its vocabulary, absent handling, and stop-remedy wording. The assistant documentation lists `list_processes`, while the TUI code keeps the processes panel under the Stats menu beside the full stats panel.
This milestone consumed the first milestone's model and put it in front of users who were not reading terminal output. Its scope was deliberately surface-only: the TUI overlay and MCP read tool had to agree with the model instead of deriving their own facts. Both child sprints ran green, but final integration ran into merge and resolve trouble after the milestones met. That stress belonged at the shared-code boundary, not inside either surface brief.
Processes Overlay in TUI
2 agents 51m 31s wall time 337k peak context 109.1k tokens out $29.77 nominal cost
`src/tui/processes.rs` still separates the off-thread reader from the pure modal body renderer, and it only asks `process_view` for data. `src/tui/state.rs`, `src/tui/mod.rs`, and `src/tui/render.rs` still carry the processes overlay, its sampling throttle, menu action, input ownership, and shared modal drawing. Tests in the TUI modules cover the menu row, overlay precedence, sampling cadence, and rendered process readout.
This sprint gave the live operator a process panel without changing the engine. The brief made it a local reader, opened from the existing Stats menu, drawn through shared modal chrome, and refreshed off the render path. It stayed green because it could lean on terminal-proven model behavior rather than recomputing process state. The acceptance boundary was interaction and rendering: open, close, sample on cadence, and never add a kill action.
Process Data Over MCP
2 agents 29m 44s wall time 198k peak context 59.1k tokens out $11.47 nominal cost
`src/mcp/tools.rs` still advertises `list_processes` as a read tool, and `src/mcp/server.rs` implements it by resolving the scoped run and returning `process_view::process_payload`. The payload keeps process data absent when a run recorded none, includes full recorded history when it exists, and reports remedies only as command strings. The process-view source plan is archived, and the assistant documentation describes the tool beside the other run-scoped read surfaces.
This sprint closed the run by moving the same process picture onto the assistant wire. The brief kept the tool read-only and run-scoped: no signal arguments, no alternate vocabulary, and clean failure when the scoped run disappears. It also carried closing hygiene by retiring the source plan once the terminal, TUI, and MCP surfaces were all present. The sprint passed green, but the whole run still hit integration stress afterward as the two milestone branches were merged together.