TASK-001F: Operator UI

• Status: Ready
• Parent: TASK-001
• Spec: SLICE-001
• Depends on: TASK-001B, TASK-001D, TASK-001E

Goal

Build the minimum operator-facing screen so the first slice is usable and the UI remains a projection of canonical state rather than a second orchestration layer.

Scope

• main operator screen
• ViewModels projecting canonical app state
• command bindings for connect, home, start, stop, abort, acknowledge, and recover or reset
• visible machine state, recipe, stage position, progress, alarms, preview, and diagnostics panel

Non-Scope

• advanced styling
• multi-page navigation
• detailed diagnostics workspace

AI Execution Profile

• Model class: Budget or Balanced
• Reasoning effort: Low to Medium
• Use cheaper models if the state and commands already exist
• Escalate only if binding or threading issues become tricky

Files Or Areas Expected To Change

• Presentation ViewModels
• WPF views
• command projection and binding glue

Acceptance Targets

• UI shows the required operational information
• command availability reflects canonical app state
• ViewModels stay thin and do not orchestrate workflow
• diagnostics and preview are visible enough for the first slice

Copy/Paste Prompt

Implement only TASK-001F: Operator UI in this repository.

Read first:
- docs/requirements.md
  Focus on Section 8 and the first-slice command/visibility rules from Sections 6.8, 7.11, and 13.2
- docs/specs/SLICE-001-first-strong-vertical-slice.md
  Focus on UI Expectations and Acceptance Criteria
- docs/tasks/slice-001/TASK-001F-operator-ui.md

Goal:
- Build the minimal operator UI for the first slice.

Scope:
- Add the main operator screen.
- Project canonical app state into the UI through thin ViewModels.
- Bind commands for connect, home, start, stop, abort, acknowledge, and recover/reset.
- Show connection status, workflow state, recipe, stage position, progress, defect count, active alarms, preview, and a minimal diagnostics surface.

Do not:
- Move orchestration logic into the UI
- Add polished styling beyond what is needed for clarity
- Build extra screens unless needed for a minimal diagnostics surface

Important constraints:
- Command availability must come from canonical app state.
- Background services must not update ViewModels directly.

Verification:
- Build if possible
- Summarize the screens/ViewModels added
- Explain how command enablement is derived

Important:
- Implement only this task
- Do not preemptively implement later tasks