Splitting Issues

Sometimes one capture holds several unrelated problems: you froze the dashboard and pinned a typo, a broken chart, and a login bug. That’s three different fixes for three different parts of the codebase, and it shouldn’t travel as one issue.

During triage, an agent can split such an issue. Every sub-issue is dealt into two or more new, focused issues, each with a sharp title of its own.

What a split does

• Each new issue keeps the same screenshot and provenance, with its share of the pins and regions. Nothing you captured is lost or redrawn.
• Comments follow their sub-issue to the new issue it landed in; issue-level comments stay with the original.
• The original issue stays in the project as a breadcrumb: marked Split, off the open backlog, linking to its descendants — and each descendant links back. The lineage is always navigable in the Cockpit.
• The new issues then cluster like any others.

What a split doesn’t do

Splitting never fixes, resolves, or edits anything; it only reorganizes. And it’s meant to be rare: agents split only when sub-issues share no screen, component, or cause. A split is one-way (there’s no merge-back), which is why the bar for confidence is high — a coherent issue is always left intact.