Layer 3: Control Plane View, Run State Machine, and Failure Handling

[d3v07]

using opus 4.8 on extra high effort

Before starting this issue, confirm you are using Opus 4.8 on extra high effort. Ask this every time you start a new work item.

Shared execution rules:

• Work on branch: feature/frex22-layers-1-4-operator-control
• Submit Layers 1 to 4 as one PR only.
• PR title: Build Layers 1-4 Operator, Intake, Control Plane, and Oversight UI
• d3v07 reviews that PR before any work starts on Layers 5 to 8.
• Do not change EvidencePack v1.
• Do not add API endpoints.
• Do not rename tools.
• Do not modify backend verification logic unless a frontend build cannot compile without a tiny type-safe adapter. If a backend change seems necessary, stop and ask d3v07.
• All agents remain read-only. Mutation remains backend-only after matching hash-bound approval.

Title:
Layer 3: Control Plane View, Run State Machine, and Failure Handling

Assignee:
frex22

Branch:
feature/frex22-layers-1-4-operator-control

Context:
Use the Layer 3 architecture image as the visual spec. This layer explains the deterministic control plane. It must make the product feel governed, not agent-random.

Goal:
Build the Control Plane view in the dashboard using existing EvidencePack v1 fields, run status, and trace data. Do not change backend contracts.

Required control plane components:
Show six deterministic service cards:

1. Run Orchestrator
   Description:
   orchestrates phases and state, tracks run lifecycle

Responsibilities:

• orchestrates phase flow and tasks
• maintains run state and transitions
• tracks lifecycle and metadata

2. Policy / Phase Gates
   Description:
   enforce policy and phase transitions

Responsibilities:

• evaluates policies and rules
• enforces phase entry/exit conditions
• blocks or routes based on policy

3. Approval Service
   Description:
   human approvals and delegation

Responsibilities:

• manages human approvals
• records approver decisions and time
• validates matching evidence hash

4. Execution Guard
   Description:
   backend-only safety guardrails

Responsibilities:

• enforces backend-only execution
• validates safety rules and scopes
• blocks unsafe or out-of-policy requests

5. Verification Engine
   Description:
   re-explain and verify results

Responsibilities:

• re-explains results independently
• verifies outcomes and assertions
• produces verification status and proof

6. Health Monitor
   Description:
   watches run status, agent completion, and failures

Responsibilities:

• monitors run progress and health
• detects failures and anomalies
• surfaces alerts and escalations

Required Run state machine:
Show this lifecycle:

Intake
Diagnose
Candidate Review
Approval Pending
Apply
Verify
Closed

The current state should be highlighted when derivable from existing pack fields.
If current state cannot be derived, show the sequence as the product lifecycle and mark actual run status separately.

Required Failure handling section:
Show these failure types:

• Invalid proposal
• Approval mismatch
• Verification failure
• Agent timeout

If a failure exists in trace, highlight it.
If not, show them as handled failure classes.

Required note:
This layer is deterministic. It coordinates policy, timing, approvals, and state for every run.

Strict constraints:

• Do not implement backend state machine changes in this issue.
• Do not add new API endpoints.
• Do not change EvidencePack v1.
• Do not create fake completed states.
• Do not hide unknown states. Use Unknown or Not recorded when needed.
• Do not mark VERIFIED in UI unless existing data says verified.

Acceptance criteria:

• Control Plane view exists and is linked from System Map or equivalent navigation.
• Six service cards render cleanly.
• Run state machine renders cleanly.
• Failure handling section renders cleanly.
• Existing verified and failed-verification packs display correctly.
• Unknown or missing data has honest empty states.
• Mobile layout is readable.

Tests:
Run:
cd dashboard && npm run lint
cd dashboard && ./node_modules/.bin/tsc --noEmit
cd dashboard && npm run build

Manual QA:

• desktop 1440x1100
• mobile 390x1000
• verified run
• pending run
• rejected run
• verification-failed run
• fallback example pack