# 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](agent-quality-practices.md),
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](definition-of-done.md).

## 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](definition-of-done.md) — the merge gate that catches the
  incomplete state this bias creates.
- [Working with AI coding agents](agent-quality-practices.md) — the full list of
  failure modes; scope cutting is #9.
- [tawa-agile-workflow](agile-workflow.md) — issues first, so a deferred item has
  somewhere durable to live.