The reviewer cuts scope in one action

[sameera]

As a delivery lead at the approval digest, I want to approve a reduced version of the draft in one choice, so that removing scope is cheaper than accepting it.

Acceptance Criteria

• Given a rendered approval digest, when the reviewer reads it, then one numbered cut list holds every inferred item and every story the necessity answer leaves outside the smallest usable version, each naming the story it belongs to, and each asked-for story rendered as asked-for rather than as an addition.
• Given the cut list, when the reviewer chooses to approve with cuts and names the numbers to remove, then the named items are removed from the draft before any issue is created.
• Given cuts that remove one or more whole stories, when filing proceeds, then the epic complexity is derived again from the reduced story set, the design-warrant that follows from complexity is derived again from that new value, and any risk or scope banner quoting the pre-cut assessment is re-derived or removed.
• Given cuts that remove a story other stories named as a blocker, when the digest asks the reviewer to confirm, then it states which surviving stories are re-parented onto which of the removed story's own blockers.
• Given the reviewer chooses to approve with cuts and names nothing, when filing proceeds, then the outcome matches a plain approval.

Notes

Without this story the labels are decoration. The only route to less scope today is to revise, hand-edit the draft in session scratch, and re-run the command, which is expensive enough that approving as drafted is always the cheaper action. This story is what makes the labelling a forcing function rather than a report.

The cut list is numbered prose grouped by story and the selection is a list of those numbers, not one control per item. Five stories can easily yield twenty cuttable items, and paginating them into batches that fit an interactive choice surface would turn one action into several rounds — which is no longer cheaper than approving as drafted.

An asked-for story is offered here on necessity grounds only, never as an inferred addition, which is why it is rendered as asked-for: cutting it removes something the lead requested. At least one story must survive; an all-stories cut is a revise, not an approval. A cut naming a story a prior partial run already filed is refused with the reason rather than silently ignored.

The decision record flags this story as widened beyond its recorded M by the necessity-grounds decision above, and leaves the re-size as a decision to take before implementation starts.

Size: M. Story type: user.