2.0 KiB
2.0 KiB
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
- Execution truth must stay visually separate from product health.
- Detail drilldowns need consistent evidence/result links.
- 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.