This is not "the user changed their mind, therefore the plan was wrong." A product reversal is legitimate and costs what it costs. The defect is narrower and it is mine: two items in one prompt were the same KIND of question, and I gave only one of them a gate.
The prompt that opened MOTIR-2542 contained three items:
I planned (1) with a type: decision card that had to check the mirror, record the evidence and name a reversal condition — correctly, because "is this needed?" is a product question. I planned (3) straight into a design card and three code cards, because it arrived as a feature request.
But (1) and (3) are the same question about the same page: does Motir want this thing at all? One of them was asked in the grammar of a question and one in the grammar of an instruction, and I let the grammar decide whether it got a gate. Nine days of plan and three commits of backend later (Organization.image, its migration, the blob prefix and gate, an upload route, a service with GC, 13 tests, plus a shared-component extraction justified solely by that second caller), Yue answered the ungated question in one sentence — no, and take the project's icon out too.
Nothing shipped: the commits sat on an unpushed parent branch and were dropped by a git reset + two cherry-picks. What was actually spent is the authoring of four cards and one run's build time. The reversal also produced value that survives — the AvatarUploadField extraction proved behaviour-neutral in both directions, and the run surfaced the meta-org paywall defect and the Organization URL finding, both of which still ship.
A "build X" instruction and a "should we have X?" question are the same planning input when X is a user-visible capability the product does not have yet. The tell is not the verb; it is whether the card's premise is "the product wants this". When that premise has never been recorded anywhere, the card is resting on it — and the decision-authority ladder says a premise is an assumption until checked, whatever mood the sentence was written in.
Cheap discharge, and it is the one already in the runbook for the sibling item: a type: decision card, ahead of the design, that checks the mirror and records the stance. Here it would have cost ~35 minutes and would have surfaced "do we want per-entity marks at all?" before the migration rather than after it.
The design that the org avatar would have collided with — MOTIR-2555's context row — had not been written yet when the avatar cards were authored, and landed three hours later. So even a perfect precondition check at authoring time would not have caught the collision. What DID catch it was the calendar rule (a done design blocker younger than the card outranks the card), fired on resume. That rule worked exactly as designed and is not implicated here — worth recording, because a planning-bug card that blames everything in sight teaches nothing.
motir-meta/notes.html as a numbered .mistake entry matching the existing markup, with the count bumped: what was assumed, that the grammar of the ask decided whether a premise got a gate, and the discharge.MOTIR-2555 collision was caught by the calendar rule working correctly, and does not attribute it to this defect.motir-meta's convention the change lands via a branch + PR — never a direct commit to main — with the branch named docs/<slug> carrying no MOTIR-<n> (an id in a motir-meta branch or title drives the status sync against a card whose work ships elsewhere); this card's key goes in the PR body.motir-meta/prompts/plan-rules.md — the decision-authority ladder and the precondition-verification rule the discharge comes from.motir-meta/prompts/run.md § a done design blocker that merged AFTER the card — the rule that DID fire, correctly.