MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2925

Planning bug: MOTIR-2919 called MOTIR-2911's conversions "landed" two minutes before their PR existed, and wired the edge `relates_to` — its "0 failures" criterion is unreachable from `origin/main`

Done
Description

Filed by motir run MOTIR-2919 (2026-08-17), guard #4.

CORRECTION, same session. This card was written while motir-core#2089 was open. It merged at 18:55:45Z — 37 seconds before the blocked_by edge and the Blocked flip were written (18:56:22Z / 18:56:24Z). The gh pr view behind the verdict returned OPEN and was accurate when taken, about a minute earlier. So MOTIR-2919 was unblocked and run in this same session; the Blocked state lasted ~4 minutes. Everything below about the authoring defect stands — the false-readiness window was real and lasted 53 minutes (18:02:24Z–18:55:45Z), and it closed by a merge, not by design. What is corrected is only the consequence: no run was actually held up. The second lesson this produced — a guard verdict is a claim about the world at the instant it is WRITTEN, not when it was computed — is in notes.html #295 alongside the first.

What the card claimed

MOTIR-2919's opening line: "Its twelve conversions landed; this is the thirteenth failure." And its first acceptance criterion:

TEST_DB_APP_ROLE=1 pnpm vitest run tests/mcp/dependency-edges.test.ts reports 0 failures … (It reports 1 today — this failure — and 13 before MOTIR-2911.)

What is actually on origin/main

Nothing of MOTIR-2911. Its PR #2089 is OPEN (green, mergeStateStatus: CLEAN, awaiting Yue's merge), and it carries the twelve conversions to the very file the criterion measures:

$ git diff --stat origin/main...subtask/MOTIR-2911-test-side-unbound-clients \
    -- tests/mcp/dependency-edges.test.ts
 tests/mcp/dependency-edges.test.ts | 41 ++++++++++++++++++++++++++++++--------
 1 file changed, 33 insertions(+), 8 deletions(-)

So from origin/main the file reports 13 failures, not 1. A perfect MOTIR-2919 fix leaves the other twelve standing and the criterion reads red — satisfiable only by rebuilding MOTIR-2911's half on a second branch, which is the two-green-PRs-one-red-main shape guard #4 exists to refuse.

The timestamps are the sharp part. MOTIR-2919 was created at 2026-08-17T18:02:24.716Z. PR #2089 was opened at 2026-08-17T18:04:35Z — 2 min 11 s later. The word "landed" was written before the pull request that would land it existed.

A second overlap, independent of the criterion: tests/integration/work-items/link-repository.test.ts asserts CrossWorkspaceLinkError at :208 and is also in #2089's changed-file list, so MOTIR-2919's blast radius intersects the open PR in two files, not one.

The edge that was owed

blocked_by. What was wired was relates_to, which carries no readiness semantics — so the card read ready: true, openBlockers: [], validate_work_item → valid: true, and claim_next_ready would have dispatched it against a substrate that is not on main. This is the [[ac-needs-blocked-by]] family (notes.html #187/#189/#204; MOTIR-1826/1834/1806/1942/2011/2075/2397, and MOTIR-2877 / MOTIR-2848 / MOTIR-2905 / MOTIR-2831 in this home).

What is DIFFERENT about this instance — the detector's first clean stop

validate_work_item MOTIR-2919 returned exactly one advisory:

{"item":"MOTIR-2919","referenced":"MOTIR-2911",
 "referencedStatus":"in_review","severity":"likely-missing-edge"}

Right tier, right blocker, right severity. And this time a step read it. MOTIR-2075 is the fixture where the advisory fired and the card dispatched anyway because nothing consumed the verdict; MOTIR-2397 is where it was consumed at the wrong tier. Here run.md guard #4's advisory block was executed as written — grep origin/main for the substrate, find it only on an open PR, wire the edge, Blocked, stop. The RUN-side half of this family now works. What remains open is the AUTHORING side: nothing at plan time stops a card from asserting a sibling's work "landed" and wiring relates_to.

Correction applied

  • link_work_items MOTIR-2919 blocked_by MOTIR-2911 (the relates_to is left in place — it is also true).
  • transition_status MOTIR-2919 → Blocked.
  • The block was lifted the same session once #2089 was confirmed merged: blocked → todo → in_progress, worktree subtask/MOTIR-2919-cross-tenant-link-error off 95361d3a.
  • The blocked_by edge is KEPT. It is a true dependency and a satisfied one gates nothing; removing it would erase the only record that the card consumed MOTIR-2911.

The block cleared when #2089 merged; MOTIR-2919 needs no re-scoping, only a base that contains its sibling.

Acceptance criteria

  • get_work_item MOTIR-2919 shows a blocked_by edge to MOTIR-2911 (Done at filing. The blocked STATUS was correct for ~4 minutes and has since been lifted — see the correction above; the edge is the durable half.)
  • The notes.html entry for this instance exists and names the two-minute timestamp gap, the fact that the advisory was consumed correctly, AND the 37-second staleness of the verdict. (#295, motir-meta#213 — open; merges after #211.)
  • No card in this home is opened to "fix" MOTIR-2919 — the card is correct; only its base was wrong.

Context refs

  • MOTIR-2919 — the card that was blocked.
  • MOTIR-2911 — the blocker; PR moooon-B-V/motir-core#2089.
  • motir-meta/prompts/run.md — guard #4's advisory block (the step that fired).