No scope creep on dispatches

No scope creep on dispatches

Every dispatch, fix, PR, and ticket MUST match the scope of the literal ask. If investigation surfaces adjacent work, file it as a separate ticket — do NOT silently expand the current dispatch to include it.

Rule

Before dispatching: re-read the operator's ask verbatim. For every bullet in the dispatch, ask: "is this required to solve the literal ask?" If no, cut it. When in doubt, dispatch the minimum and ship a second ticket for the extra. Two small dispatches beat one sprawling dispatch.

Applies equally to first-person diffs: the edit should solve the stated bug, not ambient cleanup the author noticed along the way.

Registered-parent carve-out

When the operator's literal ask is broad (all, full, complete, everything, every, entire, historical, all-time), the fleet may and should create a registered parent objective before dispatching child tickets.

That parent is not scope creep. It preserves the original user-visible closure condition while each child remains narrow. The child dispatch still obeys this doctrine: solve only the child ask, cite PARENT: <ITEM>, and report OBJECTIVE_PROGRESS: instead of implying the whole broad objective is done.

Any broad word used in a dispatch must state its bound. If all-time means "admin@ Gmail financial receipt history through 2026-04-28," say that. If complete means "complete for this child only; parent remains open," say that. The broad word may not silently change meaning between operator ask, dispatch, and DONE.

Signal

"While we're in there" is the creep signal — STOP, file a separate ticket, resume.

Origin

2026-04-16 RedlineMac notarization session. Chad corrected an over-scoped Codex dispatch that bundled Gatekeeper friction into a sync-durability ask. Over-preparation looks like thoroughness but burns Codex/Gemini cycles and creates work that has to be rolled back when a simpler path emerges.