# UI-003 Operations

| Field | Value |
| --- | --- |
| Route | `/admin/workspaces/{workspace}/operations` |
| Source | `Operations`, `OperationRunLinks` |
| Area / scope | Monitoring / workspace |
| Archetype | Operations / Monitoring |
| Design depth | Strategic Surface |
| Repo truth | repo-verified |
| Screenshot | `../screenshots/desktop/ui-003-operations.png` |
| Browser status | Reached through local workspace route. |

## First Five Seconds

The page reads as an operations monitor. It communicates execution truth, but it still needs a sharper split between active work, terminal follow-up, and diagnostic history.

## Productization Review

- Decision-first: medium; monitoring tends to be chronological.
- Evidence-first: OperationRun records are the source.
- Context: workspace route is explicit.
- Customer/auditor safety: not customer-facing by default.
- Diagnostics: appropriate as the primary mode here, but should not imply governance health.

## Information Inventory

The page exposes run state, status, recent work, and likely links to run detail. Execution outcome is visible; governance result and artifact truth remain separate surfaces.

## Dangerous Actions

Potential actions include retry, cancel, investigate, or open related artifacts. Target design should keep terminal actions confirmation-gated and secondary to run inspection.

## Scores

| IA | Density | User Clarity | Sellability | Disclosure | Hierarchy | DS Fit | A11y | Responsive | Components | UX Writing | Perf |
| ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| 3 | 4 | 4 | 3 | 4 | 3 | 4 | 3 | 3 | 4 | 3 | 4 |

## Top Issues

1. Execution truth must stay visually separate from product health.
2. Detail drilldowns need consistent evidence/result links.
3. Responsive/table behavior was not captured.

## Target Direction

P1 strategic target. Use one monitoring pattern for active, failed, partial, and completed runs, with evidence/result links delegated to shared OperationRun UX contracts.