MOTIR-4262 · Planning bug: MOTIR-4258 asserted every action on the row survived elsewhere, and wrote an acceptance criterion requiring a door it never checked existed

MOTIR-4262To Do

Planning bug: MOTIR-4258 asserted every action on the row survived elsewhere, and wrote an acceptance criterion requiring a door it never checked existed — the ⋯'s Expand / Re-plan had none

Filed by the motir run of MOTIR-4258, against the card that same session had authored ~55 minutes earlier. The correction is already applied to the card; nothing is scheduled by this record.

The mistake

MOTIR-4258 was authored with a table headed "Why nothing is lost from the row" mapping each ⋯ action to where it survives. Five rows were verified by reading the surviving mount. The sixth — Expand / Re-plan — was written as "see below", and the section below said the capability survives through WorkItemPlanEntrance.

That is true of the CAPABILITY and false of the FLOW, and the card's own acceptance criterion depended on the false half. AC 5 read:

tests/e2e/cloud-augment-replan.spec.ts passes, and the PR body names which door it now opens the augment/re-plan flow through.

There is no such door. WorkItemPlanEntrance opens the universal planning workspace; the ⋯'s Expand / Re-plan opened the in-place plan-edits dock — a different flow, a different endpoint (POST /api/ai/expand|replan), a different review surface (PlanEditsReviewDock). No other mount of WorkItemActionsMenu passes planEdits, so removing the row's ⋯ leaves that flow with no entrance and the criterion unsatisfiable as written.

What the check would have cost

One command, and the card already knew to run it — it ran exactly this shape for PlanEditsTrigger and stopped one hop short of the client the trigger calls:

$ git grep -n "submitExpandJob\|submitReplanJob" origin/main -- app components lib
app/(authed)/ready/_components/ExpansionNudgeBanner.tsx:93   submitExpandJob
lib/hooks/usePlanEditsJob.ts:122   kind === 'expand' ? submitExpandJob : submitReplanJob

submitReplanJob: no caller but the orphaned hook. The card's own AC 4 ("never a definition with no call site") was the right instinct applied to one symbol, one level too shallow.

The takeaway — a REMOVAL card's survival table needs the FLOW, not the capability

The failure is specific and it is not carelessness: five of six rows were checked properly, and the sixth was the one where a related-but-different affordance existed on the surviving surface. A capability that has an answer somewhere reads as covered, and the prose that records it ("the capability survives; the in-place flavour does not") is accurate enough to pass its own re-reading while the acceptance criterion built on it is not satisfiable.

So the rule the card owed itself: for each affordance a removal card retires, name the ENDPOINT or the REVIEW SURFACE it drives, not the user-facing verb — then check that the named endpoint has another caller. Two affordances that both read "re-plan this item" and call different endpoints are two flows, and one of them can go dark while the sentence stays true.

Disposition

The card was amended on the record — the survival table, AC 4 and AC 5 now state that the in-place dock's entrance is being RETIRED here, not re-pointed; sizing re-run (3 → 5 points, 45 → 70 minutes).
The residue is its own card: MOTIR-4261 carries the orphaned usePlanEditsJob / submitReplanJob / streamReplanJob and the acceptance-coverage consequence for story MOTIR-811.
A lesson was written to the store — a removal card's referrer sweep terminates at the ENDPOINT, not at the affordance.

Acceptance criteria

This record is readable as a closed account: no fix is scheduled here, and both the amendment and MOTIR-4261 are linked from it.
If the same shape recurs on a third removal card, the takeaway is promoted from a lesson to a plan-rules/ gate rather than re-recorded.