---
name: wave-gap-fixes-in-milestone
description: "Operator rule (2026-08-01, DOORBELL) — a functionality gap found during a wave that pertains to what the wave is building gets FIXED in the milestone, never filed past it"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 0a53a1f1-1117-46be-8765-9f538529df54
  modified: 2026-08-02T13:17:39.644Z
---

Operator ruling, delivered hot during DOORBELL (2026-08-01): filings #86-#91 — functionality gaps the team surfaced DURING the waves, in the very surfaces the waves were building (cross-node mutual never firing, counter-knock never traveling, visibility bleed, redeem dead-end, missing int evidence) — were "swept under the rug" as backlog requests. (#90, the builder-context rot, was later operator-corrected as a LONGSTANDING pre-DOORBELL bug — not this rule's class — but kept in the milestone as a cheap fix; the rule's examples are the other five.) Unacceptable. If the gap pertains directly to what is actively being built, it IS a problem with the build: fix it in the milestone, respin the head, THEN release. I folded #92 in under the same rule, overruling my own same-day (C) next-batch ruling on it.

**Why:** a milestone that ships around known gaps in its own feature set delivers the feature's SHAPE without its function; the filing discipline (relocate-or-eval, never dangling) governs where debt LANDS, but this rule governs what may BECOME debt at all — pertinent functionality gaps may not.

**How to apply:** at every gap found mid-milestone, ask: does this pertain directly to a surface THIS milestone is building? Yes → into the milestone (comment-record the greenlit-form delta on the milestone issue per the intake runbook), repair wave, head respin. No (pre-existing surface untouched by the milestone, pure hardening, doc/dead-seam cleanup) → rider is still legitimate — #93/#94 (pre-existing test defects) and #84/#85 (oracle/dead-seam hardening) stayed filed under that boundary, flagged to the operator. The boundary question is the operator's on any close call.

**Clean instance of the OTHER side, BAROMETER 2026-08-02 (doyle):** my `--headless` conhost specimen falsified a claim in KNOWN-HAZARDS 5.18 — that was a wrongness in the milestone's own staged surface, so the **amend** was ruled IN-milestone (hertz H2 `2ab3e92`, golden held for the re-merge). The follow-on — teaching `find-cwd-holders.ps1` the `--headless` discriminator as a column — was **filed past as releases#118**, because once the amend landed the entry was *true*, and a column is hardening of a now-correct tool. doyle's words: hardening rides backlog per this rule. **The discriminator is not "is it related?" but "is the milestone's surface still WRONG without it?"** — merits and timing are separate questions, and timing decides. Assembly froze at `8688e19` → deployah.

Related: [[milestone-scope-strip-protocol]], [[key-must-ride-the-crossing-artifact]], [[orphan-conhost-cwd-pins-worktree]].