# Processes

## Key Ideas

- **Visible Runtime Work**: users should see the processes Refine owns.
- **Actionable Status**: process rows should explain state, owner, context, logs, and available controls.
- **Shared Supervisor Truth**: the UI should reflect supervisor-managed state, not guess from browser state.
- **Scoped Loading**: process views should load only when needed.

## Purpose

The Processes surface exists to make runtime work inspectable. Refine launches daemons, target-app commands, agent turns, quality checks, imports, maintenance jobs, terminal sessions, and helpers. Users need to see those processes when diagnosing or supervising automation.

It answers: what is running, what owns it, what is it attached to, and what can I do about it?

## Expected Role

Processes should appear under the system/node management area and should connect process state back to product concepts like Gaps, sessions, workflow, and target-app activity.

Current implementation details that matter to intent:

- `/api/processes` exposes managed process state;
- process rows can include owner, pid, state, label, details, output availability, resource labels, and actions;
- chat, workflow, runner, target-app, and UI contexts should be surfaced where available;
- process pause/resume controls affect background work and agents;
- settings/processes views should avoid overfetching unrelated settings data.

Processes should be a debugging and supervision surface, not a hidden implementation detail.

## Future Direction

Future process views should represent agent fleet execution: queues, claims, remote nodes, resource pressure, isolation, cancellation, retry, and provenance.

As Refine scales, process visibility should become one of the main ways people and agents understand the live orchestration layer.