jianzhichun/emerge/cockpit-rendering

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.