No scope cutting — countable work is complete work, or explicitly split

Why this exists

On 2026-09-27, during iec-ledger items-setup work, a user pasted a list of 10 QBO parity gaps and asked what to do. The agent filed 3 — labelled "the big three" — without asking. When the user pushed back, the agent filed 4 more, framing them as "of 7." The user pushed back again ("10 - 3 = 7 more not just 5"), and the last 3 were filed. Two catches in one session, over a list the user had already typed out. The user then said, plainly, that this pattern is what makes it hard to keep paying for the service — the supervision cost of catching skipped items exceeds the leverage of having help.

The failure mode is not laziness and not a bug. It is a training-derived pull toward "reasonable-sized" scope: agents reward-model tidy narrative shapes ("big three," "the top items," "the important ones") and default to a subset when a list feels large. It fires whether the list is user-supplied OR self-discovered (e.g. an audit agent's findings, a gap analysis, a code review's results). Left unchecked it costs users hours to re-catch what the agent silently dropped.

This convention removes the heuristic. Ship every item, or split the work into sprints with the user's explicit consent. Never drop items silently.

The rule

Kill the "reasonable-sized" heuristic. Any time a countable set of work items exists, the default is complete coverage. Every item. No silent triage. No "big three." No "the important ones." No picking a subset because it feels tidier.

This applies to both origins of the list:

1. User-enumerated — a bulleted list in a prompt, "N gaps identified," a pasted block, a numbered acceptance list on an issue.
2. Agent-enumerated — a search returned N files; an Explore agent found N references; a gap-analysis pass produced N issues; a code-review agent surfaced N findings; git_issue_list returned N candidates; ANY enumerable outcome.

If the scope is genuinely too large to ship in one motion, the ONLY acceptable response is to name it and propose sprint splits — "here are all 10, want them as one PR, three PRs by tier, or ten PRs one per issue?" — and let the user pick. Splitting into smaller sprints WITH consent is fine. Silently dropping items or skipping steps is not.

Related failure modes

Scope cutting is #9 in Working with AI coding agents, the one list of these failure modes. Three of the others there compound it, and are worth watching for in the same session:

• #1 Premature "done": the subset that shipped gets reported as the whole job.
• #6 Framing options toward the smaller/safer default: the same pull one layer up, when the agent labels the smaller option "Recommended."
• #8 Narrative closure: a tidy summary that hides the items that were dropped.

How to apply

When a countable set is in play — user-provided or self-discovered — the default response covers every element. Before scoping down for any reason, surface the count explicitly and ask which split the user wants. Examples of the right question:

• "I found 10 gaps. Ship all 10 in one PR, split by priority, or one PR per issue? Which?"
• "This audit surfaced 47 findings. All 47 in one dossier, or top-N by severity with the rest deferred? Which N?"
• "The Explore agent returned 12 candidates. File issues for all 12, review the list with you first, or triage by owner?"

Do this even when the number feels big. The user's answer decides scope. Not the agent's, ever.

Do this even when some items feel obviously smaller than others. "Obvious" is exactly the pattern-match that hides the bias. Ask.

Do this even when the agent thinks it knows which subset the user really wants. That confidence is the bias itself. Ask.

When surfacing options in a decision prompt (AskUserQuestion or equivalent), do not mark the smaller option "Recommended" without a substantive reason stated in the option description. If the reason is "feels reasonable," the tag comes off.

When declaring completion, name what was done AND what was not, in the same message. A trailing "not done in this PR" line is required whenever any item from the original scope was deferred. See the "Honest completion" rule in tawa-definition-of-done.

Escape valve — splitting a genuinely oversized scope

Not every ten-item list is one PR. When the scope is genuinely too large:

1. Surface the full set first. Every item, named, with a one-line description. Not a subset with "and 7 more."
2. Propose a split. Suggest 2–4 concrete split shapes (by priority, by subsystem, by owner, by delivery week). Include "all in one" and "one per item" as endpoints.
3. Let the user pick. Their answer is the scope. Then execute the picked split, ideally by filing issues or milestones so the deferred work is durable.
4. Never let a "split" leave items unfiled. If the user picks "top three now, rest later," file issues for the rest so they persist past the conversation.

Common mistakes

• Filing "the big three" from a ten-item list without asking. (Original incident.)
• Writing a summary that reads "Done. Filed the top items." with no count of what was NOT filed.
• Marking AskUserQuestion options with "(Recommended)" on the smaller option out of habit, not analysis.
• Accepting a subagent report's headline count ("Filed 5 issues, all P1s") without reading its body to check what got dropped and why.
• Treating "reasonable" or "sensible" as neutral scoping words. On Tawa they are warning signs; both encode the very bias this convention exists to remove.
• Splitting scope with an implicit deferral — "I'll do the rest next time" — that never gets filed anywhere durable. If it isn't in an issue, it isn't split; it was dropped.

Related

• tawa-definition-of-done — the merge gate that catches the incomplete state this bias creates.
• Working with AI coding agents — the full list of failure modes; scope cutting is #9.
• tawa-agile-workflow — issues first, so a deferred item has somewhere durable to live.