Cockpit Product Model
This page is the review gate for the cockpit redesign. It defines the page model and user vocabulary before broader UI and data-shape changes.
Primary Questions
The cockpit should answer these questions in order:
- What needs a human now?
- Which workspaces need attention?
- What work is unfinished?
- Where do I click next?
Everything else is supporting detail.
Scopes
| Scope | Purpose | Default contents |
|---|---|---|
| Host cockpit | Host-wide situation awareness. | Action queue, workspace health, active threads, plugins, host capability summary. |
| Workspace cockpit | One workspace in context. | Selected item, work map, workspace HITL queue, tracked work, components, plugins, events. |
| Selected item | One thing the user clicked. | Summary, primary action, provider links, evidence, diagnostics. |
The host cockpit is not just a workspace switcher. It is the first screen when the user wants to understand the host.
Page Order
- Header and scope controls.
- Selected item summary when something is selected.
- Action queue.
- Parallel work map.
- Thread, tracked work, component, and plugin lists.
- Diagnostics or raw evidence.
This order keeps human decisions near the top and pushes supporting inventory lower on the page.
Vocabulary
Use these words in the primary UI:
| Use | Avoid in primary UI |
|---|---|
| approval | authority |
| review | handoff |
| blocker | raw policy failure strings |
| issue | provider object |
| pull request | provider pull_request |
| thread | lease |
| continue | resume work item execution |
| resume chat | Codex resume, unless Codex must be named |
| archive | stale cleanup |
| forget | delete reminder |
| rescue | salvage branch |
Technical terms can still appear in diagnostics, docs, and API fields.
Actions
Every blocked or review-needed card should expose a primary action when one is available.
| State | Primary action |
|---|---|
| Approval needed | Review approval |
| Provider issue found | Open issue |
| Provider PR found | Open pull request |
| Assistant thread found | Resume chat |
| No assistant thread found | Start chat |
| Local changes uncertain | Rescue |
| Useful but inactive thread | Archive |
| Not useful thread | Forget |
Action buttons should be short. Provider buttons should include provider icon, short id, title when known, and an external-link icon when opening a new tab.
Details
The selected item panel should have four sections:
- Summary
- Actions
- Evidence
- Diagnostics
Summary and Actions are open by default. Evidence and Diagnostics can be collapsed or lower on the page.
Configuration And Settings Direction
The default cockpit should show configuration-derived state, not become the configuration editor. Main panels stay read-only and operational: they explain which policy is active, which runs are waiting, and what needs a human next.
A future Settings surface should own edits to project configuration. Each setting needs a human-readable label, current value, source, validation state, permission boundary, pending diff, and explicit apply path. Settings changes should not be hidden behind status cards.
Git workflows are the first good fit for this split. The workspace cockpit can
show configured profiles and recorded runs now. Editing automation.gitWorkflows
belongs in Settings later, with validation and review before writing the project
config file.
Implementation-Ready Decisions
cockpit servewithout a workspace root opens the host cockpit.- The host cockpit should be a real status surface, not only a switcher.
- The default UI should avoid raw timestamps, raw ids, JSON-shaped text, and long paragraphs.
- Provider navigation is safe as read-only links.
- Assistant chat actions should use provider-neutral labels by default.
- Advisory leases can contribute hints but should not define the whole active work model.
Open Product Decisions
- Which assistant providers should appear when more than one is configured.
- Whether archive and forget mutate only cockpit state or also project tracker state.
- Whether plugin installation can be launched from the cockpit or only linked to a setup flow.
- Which diagnostics are important enough to expose on the first page.
Do not start broad UI refactors until this model is accepted or updated.