Issues

The issue model

An issue is a unit of work after intake. The moment you click Convert to issue in the Inbox, the row gets its own detail page, a kind, a priority, a readiness, and a status.

Three core fields drive behaviour:

• kind — BUG, FEATURE, or SUPPORT. The UI adapts.
• priority — critical, high, medium, or low.
• readiness — ready (dev-ready), investigate (look first), or blocked.

readiness is independent of status. An issue can be ready in status but investigate in readiness — for example, when the intake agent's confidence was low.

Operator workbench layout

Issues is the densest list page in the product. Layout choices follow Linear/Jira conventions so existing muscle memory lands.

• Sticky chrome. Page header, filter strip, the DataTable toolbar, and the column header all stay pinned while the row list scrolls. The filter strip hides itself when no buckets are populated so the chrome doesn't squat on empty state.
• Split view. Pressing Enter (or clicking a row) opens the issue in a right-hand detail pane. The list keeps its filter+sort; you triage without leaving the queue. The pane width is resizable (drag the divider, or focus it and use ←/→; Shift for 64px steps) and the choice persists per-operator. Toggle the pane with the panel-icon button in the toolbar — closed-state still routes activations to the standalone detail route.
• Detail pager. Inside the right pane (and on the standalone /issues/:key route), the prev/next pager walks the current filter set, not the whole tenant. [ steps prev, ] steps next.
• Bulk select. x toggles the active row, Shift+x extends a Gmail-style range from the last anchor, Cmd/Ctrl+A selects every visible row on the page. Selection survives pagination, sort, and filter changes — re-filtering hides rows but keeps them selected, so you can build a multi-page set from several passes and act on it once.
• Bulk actions. A sticky toolbar appears above the table whenever anything is selected: Approve, Reject, Delete. The bar shows N selected (M on page) and offers a one-click "select all matching" escalation when there's more behind the current page.
• Row shortcuts. With a row active: a runs the row's primary action (open / approve / send, depending on kind), f triggers Run fix. Both fall through to the same handlers the row buttons use, so optimistic state and audit trail stay identical.
• Live status. When an agent run is in flight on a row, the status cell flips to a live pill with an inline cancel; you don't have to navigate to the Runs page to abort.

The DataTable's keyboard map (j/k, /, Enter, Esc, etc.) and the global command palette are documented under Keyboard & command palette.

Per kind

For a SUPPORT issue, the dev-pipeline buttons are hidden. For a BUG with priority=critical or a PAYMENT flag, Dry run is promoted as the visually primary button — you'll see a warning that a CTO gate may be required before a real run.

Plan approval before execution

For risky work the AI team first drafts an execution plan before it starts building. That plan shows up as the "Awaiting plan approval" card on the issue page: the problem interpretation, the approach, affected systems, the risk, and the validation and rollback strategy — in plain language. You choose Approve plan, Request changes (the AI produces a new version with your feedback), or Reject plan. Until the plan is approved, the AI doesn't start.

This is the most powerful place to steer: you correct the approach before there's any code, rather than rejecting a wrong patch after the fact. The full walkthrough is in Approvals.

AI execution view

When a mission is running on an issue, the detail page shows an AI execution view: a status header with the current phase, an audit summary of what the AI team did, the QA pass-rate, and — where applicable — a real rollback button. It's audit-first: you read what happened, not just what's running now.

Statuses

• intake — just arrived, not yet reviewed.
• review — under review.
• ready — approved, waiting for or running through the dev pipeline.
• in_progress — work happening.
• blocked — waiting on input.
• done — handled or rejected.

AI supervision on issues

Every issue carries supervision metadata from the intake agent and (when patches exist) from the patch reviewers:

• Confidence — the model's self-rating on the classification.
• Risk — independent judgement on the consequences of acting (separate from confidence).
• Why — the model's stated reasoning.
• Sources — knowledge chunks the model used.
• Uncertainty — what the model says it's unsure about.
• Assumptions — what the model assumed.

Confidence is not safety. A confident wrong classification is still wrong. Read the "Why" before you act, especially when risk is medium or high.

When the agent is mid-run on an issue, the row's status pill shows the live phase (generating, applying, verifying) and exposes an inline cancel — the same handler the Runs page uses, so the audit trail is unchanged.

Patches and retry lineage

When a patch is produced for an issue, the detail page surfaces:

• The current revision in the Patch trust panel (confidence, risk, sources, "what changed").
• Retry lineage — the chain of revisions if there have been any. Each entry shows its state (approved, rejected, changes_requested, superseded) and rationale.
• Dry run results when a dry run was executed.

Auto-revise is bounded — by default after three rounds the chain is flagged for human triage rather than continuing to loop.

Actions on an issue

The action bar:

• Approve — moves the issue to ready and triggers the dev pipeline (hidden for SUPPORT).
• Reject — closes the issue (requires confirm).
• Mark duplicate — link to an existing issue.
• Split — break into multiple child issues.
• Dry run — produce a patch through the full pipeline without committing or pushing.
• Run fix — execute the fix and open a PR.

Starting a run from a row doesn't navigate away. The run streams into the side pane (or the cell's status pill if the pane is collapsed), and you stay on /issues to keep working.

After Run fix, the right pane shows a PR → link and a Last verification panel with the most recent QA results.

Common mistakes

• Approving a low-confidence classification without reading the rationale. The "Why" panel is short by design — read it.
• Running fix without a dry run for high-risk patches. The UI nudges you toward dry run for a reason.
• Treating `kind` as fixed. You can change it from the detail page; the layout switches over immediately.

FAQ

The `kind` is wrong — can I change it? Yes, from the detail page header.

Why don't I see Approve? This is a SUPPORT issue. Use Send in the Auto-reply panel.

Why is Dry run highlighted instead of Run fix? Either the issue is critical, touches a PAYMENT flow, or the patch has risk=high. FixControl is recommending you preview the change first.

What happens after the third revision in retry lineage? Auto-revise stops and the issue surfaces in the operator queue with requires triage. You decide whether to run another revision manually, change the prompt, or close.

See also: Keyboard & command palette.