---
name: cockpit-rendering
description: Use when designing or revising Emerge cockpit presentation, summaries, filters, action labels, or empty/error states without changing the HTTP API contract.
---

# Cockpit Rendering

## Purpose

Keep cockpit code focused on serving state and validating actions. Put presentation judgment here: what sections matter, how to label them, and how to keep the operator focused on flywheel progress.

## Rendering Principles

- Lead with actionable flywheel state: stable pipelines, canary risks, blocked synthesis, runner health.
- Treat cockpit copy as operator guidance, not implementation truth. Source data still comes from `/api/*` and resources.
- Do not invent new API fields. If a view needs data, first check existing endpoints and only propose API expansion explicitly.
- Prefer short status labels over narrative prose in tables and cards.
- Expose confidence and verification state when a recommendation could trigger operator action.

## Empty States

- No stable intents: explain that repeated successful spans are needed before zero-inference execution appears.
- No runners: point to `admin-runner-operations` or `runner-install-url` instead of embedding long setup flow in code.
- Synthesis blocked: show the reason and the latest sample/job ID so the operator can inspect the right artifact.

## Action Labels

Use verb-first labels: `Freeze policy`, `Resume policy`, `Open runner`, `Resolve conflict`, `Retry synthesis`. Avoid labels that imply human approval gates for auto-promoted paths.