ADR-0372: Mid-delivery findings accumulate on one snag list per Epic and are adjudicated at close-out — the agent never creates an Epic

Status: accepted (2026-08-09) · amended 2026-08-12 — decision point 5 now carries one narrow carve-out for an approved /grillme design

Context

ADR-0274 drew the acceptance boundary for findings discovered after an Epic closes: those are incidents, not backlog. It left the other side of the boundary governed by the original RULE 2 wording — find the relevant Epic for the work, and if there isn’t one, create a new one. That sentence is the intake rule for everything noticed during a delivery run, and it made minting an Epic the agent’s reflex for any observation that didn’t fit the Epic in hand.

Arron raised the consequence on 2026-08-09: “I don’t like the way that all these issues are being randomly thrown across the board. I can’t track them. Some of them don’t get done. They may not end up in the right place.” The board measured on that date bears it out:

Measure	Count
Open Epics	119
…with no open children at all	50
…untouched for 30+ days	45
Open Issues/Tasks	249
…older than 30 days	144

Fifty childless Epics is the signature of the failure: an Epic is a commitment — a goal with a lifecycle, a delivery report and a close-out — but the rule let it be used as a note. Nothing ever groomed the difference, so intent and commitment became indistinguishable on the board and the whole thing stopped being trackable.

The estate had already invented the correct shape twice without generalising it: the standards-gap register (Epic #2259) and the notification KB-draft backlog (Epic #1809) are standing homes for a recurring class of finding, precisely so those findings do not each mint an Epic. What was missing was the general case and, critically, a drain — a forcing function that empties the queue rather than letting it accrue.

Arron’s framing supplied the missing half: the findings should stay attached to the delivery that produced them, marked as not to be delivered, so that at the end of a delivery run he can “sit down and really go through the detritus/the fallout from a delivery run in a more controlled way and decide what’s done, how, and where it gets linked/logged.” That is the snag list (punch list) of enterprise project delivery, adjudicated at the close-out review — the same ceremony PRINCE2 calls End Project and ITIL calls service transition.

Decision

A mid-delivery finding is a snag: it lands on ONE [SNAG LIST] Issue under the Epic being delivered, is invisible to that Epic’s delivery burn-down, and is adjudicated in a single controlled review when the Epic closes.

1. Three-way triage at the moment of discovery

Every finding is routed by one test, applied when it is spotted, not at wrap-up:

The incident branch is ADR-0274 widened: a defect in an accepted capability is an incident whenever it is found, not only in a post-close session. Discovering it while delivering something unrelated does not make it project work.

2. One snag list per Epic, not one Issue per finding

Findings accumulate as a checklist inside the description of a single Issue titled [SNAG LIST] <topic> — findings for close-out review, tagged snag; close-out-review, parented to the Epic. The board therefore grows by exactly one row per Epic regardless of how much fallout a delivery run throws off — the direct answer to “sprayed across the board”. Per-finding state and ownership are deliberately deferred: a snag has no owner until it is adjudicated, at which point it becomes an incident, an Epic, or nothing, each of which carries its own tracking.

3. Snags are excluded from delivery — the burn-down must not see them

The snag list is not work to be done. /wrapup’s resume-artifact generator excludes it when batching open children into the next-session prompt, and it is never counted as outstanding delivery scope. A snag that leaked into a delivery batch would defeat the entire mechanism by turning the detritus back into a to-do list.

4. The close-out review is the drain — every snag exits to a named disposition

A register with no drain is the same swamp under a new name, so the close-out is mandatory and blocking. At Epic close, /wrapup Check Q presents the whole list and each item is routed to exactly one of:

Disposition	Meaning
fixed	remediated during the close-out
incident	raised in the FreeScout Incidents mailbox (the capability is now accepted/live)
epic	promoted to a new Epic — Arron’s explicit approval, per point 5
folded	absorbed into an existing open Epic as a child
wontfix	consciously closed with no action

The snag helper refuses to close a list with any unadjudicated item (exit 2). Because the existing invariant already forbids a Done Epic from carrying open children, the snag list closing is a hard precondition for the Epic closing — the forcing function is the machinery that already exists, not a new one.

5. The agent never creates an Epic — except on an approved, grilled design

An Epic is created only by Arron — via /idea, or by directing the work in conversation. This is the single change that stops the board growing sideways, and it extends ADR-0274 point 3 (“new Epics with Arron’s approval”) from a wrap-up-time rule to a standing one. Backlog growth is a conscious act at all times, never a reflex.

Amendment, 2026-08-12 — an approved /grillme design is the one authorisation the agent may act on directly. When a design has been through the four-layer grill and Arron explicitly approves it at the close-out gate, that approval is the commitment, and the agent mints the Epic in the same turn rather than asking a second time.

This does not weaken the rule; it satisfies it. The rule’s purpose is that an Epic represents a conscious commitment rather than a reflex, and an approval given against a technical-executive brief, a resolved decision tree and a named delivery plan is the most deliberate commitment the estate can produce — strictly stronger evidence of intent than the /idea path it sits alongside. Asking “shall I create the Epic?” immediately after “is this design approved?” was ceremony, not control.

The carve-out is deliberately narrow and does not generalise. It authorises exactly one Epic, for the design just approved, in the session that approved it. An unapproved design, an abandoned grill, an “approved with changes” awaiting re-brief, or any finding surfaced outside that design mints nothing — those still route to a snag, an incident, or a question, exactly as §1 requires.

Every Epic minted this way carries the grilled tag, so the board distinguishes at a glance between work resting on a designed-and-approved foundation and work that has not been through that scrutiny. Ungrilled work is not forbidden — it is simply visibly ungrilled, which is a governance signal the board did not previously carry.

6. snag is the capture path

ansible/scripts/snag.py, deployed to /usr/local/bin/snag on control01:

snag add   <epic> "<finding>"                 # capture (creates the list if absent)
snag list  [<epic>]                           # one Epic's snags, or every open list
snag route <epic> <n> <disposition> [<ref>]   # adjudicate one finding
snag close <epic>                             # close the list once every finding is routed

Capture is one command deliberately: a discipline that costs a multi-step ADO dance during focused delivery work is a discipline that silently stops happening.

Alternatives considered

• Log every mid-delivery finding as an incident (Arron’s opening proposal): rejected on the ITIL definition. An incident is unplanned interruption or degradation of a live service — it carries impact, an owner and an SLA. A “this could be better” observation has none of those, and filing it as an incident makes the incident queue permanently dirty, so the one queue with a working drain stops being trustworthy. Defects in accepted capabilities do go this route (point 1); improvements do not.
• A single estate-wide standing “discovery register” Epic (the first proposal in this conversation): rejected in favour of per-Epic lists because it severs the finding from the delivery run that produced it, which is exactly the context Arron needs to adjudicate it. Retained only as the fallback home for findings discovered with no active Epic (a /health or /investigate sweep) — Epic #2259’s register.
• Individual snag-tagged Issues under the Epic: rejected — individually queryable and cross-Epic-comparable, but the board row count still grows per finding, which is the stated complaint. Reconsider if cross-Epic snag pattern analysis is ever wanted.
• A markdown register in pitlab-docs: rejected — inert, no state, no forcing function, easiest of all to ignore.
• Status quo (create an Epic per finding): rejected — it produced the 119/50/45 board measured above.

Consequences

• The board’s Epic count reflects committed goals only. A delivery run adds at most one row (its snag list) for its entire fallout.
• Arron gets one controlled adjudication per Epic instead of a continuous drip of unexplained items — his stated requirement.
• An Epic cannot close on unadjudicated detritus, so “some of them don’t get done” becomes structurally impossible for anything captured. The corresponding risk is the reverse: a snag list is a blocker on Epic closure, so a large pile of un-routed snags will hold an otherwise-finished Epic open. That is intended — it makes the fallout visible at exactly the moment there is appetite to deal with it.
• Snags carry no per-item history until adjudication. If cross-Epic snag trend analysis is ever wanted, the alternative above (individual tagged Issues) is the migration path.
• The existing backlog is not retro-fitted by this ADR. The 119 open Epics, 50 of them childless, remain to be groomed under Epic #1865 (Backlog grooming — full To-Do review, dedup, and scope decision); this decision stops the inflow, it does not drain the existing pool.
• The grilled tag makes design rigour a board-visible property (2026-08-12 amendment). Because only an approved grilled design mints its own Epic, the tag is self-enforcing rather than a label anyone must remember to apply, and the board can be filtered to ask “how much in-flight work was actually designed?” — a question it could not answer before.
• RULE 2 (ADO Session Tracking), the ADO Work-Item Conventions Standard, the /wrapup checklist (new Check Q, amended Checks I and D and the resume artifact) and /ado-session are all amended to match.