Planning bug: MOTIR-3274 closed `done` on criteria written over ONE project while its own Context refs named a SECOND consumer — the credential meant to unblock MOTIR-3264 cannot reach the gateway

Planner telemetry, filed into the planner-bug home. It blocks nothing and is in no sprint. The correction to the tree was submitted as plan cmt5j2uz900dei3phybrnq52g at the time of filing.

Discovered in

motir run MOTIR-3264 (2026-08-23), which halted at run.md guard #4 before creating a worktree. Full evidence table in the run comment on MOTIR-3264.

The defect

MOTIR-3274 exists to make a Neon control-plane credential reachable from a run session. Its Context refs name two consumers: MOTIR-2853 (motir-core) and, in plain language, "MOTIR-3264 — the motir-gateway half of the same measurement, still open, which will need the same credential."

Its four acceptance criteria were then written entirely over motir-core's project:

1. GET /api/v2/projects/{id} returns 200 — satisfied against snowy-truth-13928044.
2. the key's scope is stated — stated, and stated correctly: project-scoped.
3. the project id owning ep-billowing-wildflower-au5s16ri is recorded — motir-core's endpoint.
4. no Neon credential in any Fly app's secrets.

Every one of them is true. The card closed done on honest evidence. And the second consumer it names is exactly as blocked as before: the key is scoped to snowy-truth-13928044, the boundary is enforced server-side (GET /api/v2/projects → 404 subject_project_id:"snowy-truth-13928044"), and motir-gateway's database is ep-crimson-dew-ai3vmlx0 in a different Neon project.

The shape, stated generically: a prerequisite card's acceptance criteria named ONE consumer's need while its prose promised TWO. Criterion 2 even asked for the scope to be stated — and stating it was enough to pass, because no criterion asked whether that scope covered the consumers the card had named. Nothing downstream could catch it either: readiness.ready was true, openBlockers empty, validate_work_item valid: true, and the one advisory on MOTIR-3264 pointed at an unrelated merged PR. The blocker was not a work item failing to reach done — it was a done work item whose deliverable did not cover the consumer, and no edge can hold that.

How this differs from the two neighbouring records

• MOTIR-3275 covers a precondition that was never planned at all (an external credential; notes.html #30) and a soak window no edge can express. This is the next state along: the credential card was planned, was built, and was closed correctly. Its criteria simply did not reach one of its own named consumers.
• run.md's artifact-obtainable check — pull it from where its CONSUMER will obtain it — is the closest existing rule and is the right instinct, but it is written for one consumer and one artifact. MOTIR-3274's filer did pull, as the consumer, from where that consumer reads. There were two consumers and only one was standing there.

Acceptance criteria

1. plan-rules/ gains, or sharpens, a rule for a card whose DELIVERABLE is consumed by more than one other card: every consumer the card names — in its criteria or in its prose — appears in an acceptance criterion as a check performed against that consumer's own target, not against the first one. A manual credential/provisioning card is the canonical carrier, and the rule states that naming a consumer in Context refs creates a criterion, not a note.
2. The notes.html mistake #30 family is extended, not duplicated. #30 says every external prerequisite is its own planned subtask. The addition is that such a subtask's criteria must be written over the SET of consumers it serves; whether that is a new lesson or a sharpening of the existing one is decided here.
3. The lesson is recorded in the lesson STORE, not in notes.html (frozen since MOTIR-3296) — a row in motir-ai src/seed/lessons.base.ts plus its generated migration, written generically, with sourceRef naming this card. (Written by the filing run; this criterion records that it is owed and closes on the row being present.)
4. The rule change names this card, MOTIR-3274 and MOTIR-3264 as its fixture, so the next reader sees the shape rather than only the rule.

Context refs

• MOTIR-3264 — the blocked card, and the run comment on it carrying the full probe table.
• MOTIR-3274 — the prerequisite card whose criteria under-covered its own named consumers.
• MOTIR-3275 — the neighbouring planning bug from the same family, filed by motir run MOTIR-2853.
• Plan cmt5j2uz900dei3phybrnq52g — the submitted correction (the widened-credential card + the blockedByAdd edge on MOTIR-3264).
• ⚠️ Plan cmt5j15z500d4i3phegz52470 — abandoned unclosed by the same run (a modify appended with a placeholder temp-ref, and a proposal cannot be withdrawn). Cancel it. That a mis-ordered append is unrecoverable is itself worth a corpus line: append the add, read its id back, and only then append the modify that references it.