Scope Prune

Start with the problem, not the patch. The target is the smallest durable implementation of the agreed outcome, not the fewest lines and not a general cleanup of nearby code.

1. Recover the boundary

Recover the accepted user outcome and later explicit decisions from the conversation and linked context. Use a Feature Contract, plan, or PR as evidence, not as independent authority to enlarge that outcome. Separate agreed behavior from suggested mechanisms, and record the in-scope failure path, non-goals, real compatibility obligations, and proof needed to know the problem stays solved. If the boundary is missing or contradictory, ask for the decision that would change what can be removed; do not infer product intent from the implementation or its tests.

Establish the requested diff baseline before judging size. For a PR or branch, include commits since the intended base plus staged, unstaged, and relevant untracked work; distinguish inherited and unrelated changes. For a narrower target, follow the user's range. Use subtract's Change Scopes to protect the index and history when editing staged or committed work.

2. Challenge the entire diff

Inspect every changed surface, including production code, tests, fixtures, docs, configuration, and generated output. Trace additions through their callers and the accepted failure path. For each coherent change, classify it as:

• Essential: directly delivers the agreed result.
• Necessary support: required for that result to work safely in a realistic supported path, including a named compatibility, security, or data-integrity obligation.
• Extra: adjacent feature, speculative guard or fallback, generalized abstraction, redundant representation, broad refactor, or test that proves only an extra behavior or mirrors code without closing a risk.
• Uncertain: removal depends on missing contract or consumer evidence.