Parent-Objective Tickets Preserve Broad User Intent

Parent-Objective Tickets Preserve Broad User Intent

Rule

When the operator asks for a broad or exhaustive user outcome, the fleet MUST register that outcome as a parent objective before decomposing it into smaller child tickets.

Broad objective signals include words like:

• all
• full
• complete
• everything
• every
• entire
• historical
• all-time

These words are overloaded. They can mean a literal implementation bound, a business promise, a user-visible closure condition, or a rhetorical way of saying "do not stop at the first easy slice." The dispatcher must preserve the operator's broad intent in a parent objective, then let child tickets use narrow literal scope.

Parent Objective Contract

A parent objective is an actionable work item whose job is to hold the user outcome, not to prescribe every implementation step.

It MUST name:

1. The user-visible closure condition. 2. The bounded domain being covered. 3. The evidence required to close the parent. 4. The known child tickets or the next child-discovery rule.

Child tickets MUST cite the parent when they satisfy only part of the objective:

PARENT: FLT-0624
OBJECTIVE_PROGRESS: <what fraction of the parent closure condition changed>

The child DONE post proves the child. It does not imply the parent is done. The parent closes only when the closure evidence covers the registered domain, or when explicit non-coverage exceptions are recorded in the parent.

Registered-Parent Carve-Out

ORA-2026-0021 still applies: do not expand a child ticket beyond its literal ask. The carve-out is that creating or maintaining the parent objective is not scope creep. It is the mechanism that prevents literal child tickets from erasing the user's broader ask.

This is the split:

• Parent objective: preserves what the user should experience and `why it

matters`.

• Child ticket: ships one bounded slice with its own proof and progress line.

Without the parent, decomposition turns broad words into local words. A child called "backfill March receipts" can finish while the original request "all admin@ receipts are represented" rots. With the parent, the March child can finish honestly and the fleet still sees what remains.

Word-Overload Discipline

Any dispatch or DONE using all, full, complete, everything, every, entire, historical, or all-time MUST make the bound explicit.

Use this form:

BROAD WORD: all-time
BOUND: admin@ Gmail financial receipt history from first available message
through 2026-04-28, excluding messages already proven non-receipts
CLOSURE: parent has month-by-month coverage proof or named gap exceptions

If the broad word is intentionally rhetorical, say so:

BROAD WORD: complete
BOUND: current ticket only; parent objective remains open

The point is not to ban broad words. The point is to stop them from silently changing meaning as work moves from operator ask to dispatch to child ticket to DONE.

Idle And Queue Implication

A seat that finds no direct claimable work must also scan open parent objectives before treating the queue as empty for its role. If a parent objective has an uncovered child that matches the seat's lane and warm context, that is claimable work. File or claim the child instead of retiring or posting idle.

Why

The fleet's coordination layer is part of the world model. Tickets are entities that claim to represent work in reality. When a broad user objective is split into narrow children without a parent, the world model loses the thing the user asked for. The fleet can become locally truthful and globally false: every child DONE is accurate, but the original promise is still unmet.

Parent-objective tickets keep the map faithful. They let the fleet decompose aggressively without losing the closure condition that mattered to the user.

Evidence

The all-time receipt backfill incident showed the failure mode. The literal children were reasonable slices, but the fleet lacked a registered parent that held the complete user outcome: every relevant admin@ receipt should be represented or explicitly excepted. That allowed progress to look complete at the child level while the parent objective still needed coverage proof.

USER-VALUE-CLOSURE

• user: Chad, Zack, and every fleet seat consuming queue state
• surface: FLEET_FEED.md, fleet-active-queue, and lane DONE posts
• change: broad requests remain visible until the user-visible closure

condition is proven, even when implementation is split across tickets

• closure_date: doctrine slice shipped 2026-04-29; runtime enforcement remains

a separate child of FLT-0624