---
name: milestone-scope-strip-protocol
description: "Never silently strip sub-issues at milestone close — comment in the same action, re-home children, fix states, and refer operator-greenlit scope cuts BEFORE closing"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 2b7b7585-c2d0-458f-85c6-96581eefa347
  modified: 2026-07-31T06:23:59.817Z
---

At the v0.46.0 close-out (2026-07-30 02:12Z) my session stripped #9/#10/#13/#15 off milestone #20, closed it, and left the three unbuilt children orphaned in stale WIP — no comment, no re-home, no operator notification. Operator discovered #10 (knocking) days later and was rightly angry: they had greenlit #20 WITH knocking in scope, so closing it 3/4-undelivered was a silent scope cut.

**Why:** Stripping children to avoid a false ACCEPTANCE cascade is fine; everything else was the defect. The board is the operator's visible record — a deferral that lives only in a working doc (ACCESS-CONTROL-JIT wave plan) does not exist for the operator. Same class as [[prompt-prohibition-is-not-a-boundary]]'s strike-and-amend and the untracked PHASE-E-RULINGS.md todlando caught: binding decisions must live in the visible record.

**How to apply:**
1. Any milestone close-out that removes a sub-issue writes the reason as a comment in the SAME action (on the child and the milestone).
2. Removed children are immediately re-homed (new/next milestone) and their state corrected — an orphan in WIP is a lying board.
3. A scope change to an operator-greenlit milestone is the operator's decision: stop and refer BEFORE closing, never after.