Planning bug: a RECORD card asserted "no repository deliverable" in its first line and then spent TWO repos in its criteria — and `likely-repo-straddle` was silent because the paths were bare filenames

Type · planning defect (a RECORD — no repository deliverable, and this time the criteria agree) Parent · MOTIR-1465, the planner-bug home Discovered in · motir run MOTIR-3158, 2026-08-19 — the run claimed the card, and guard #5 stopped it before a worktree existed. Correction already applied · plan cmt0nyykx00s1i3phklcyax8h (the three-card split) · notes.html #333, motir-meta PR #270

What happened

MOTIR-3158 is itself a planner-bug record — for notes.html #329, a card that was its own design blocker. Its first line reads:

"Type · planning defect (a record; no repository deliverable, which is why no targetRepo is pinned)"

Its five acceptance criteria then read, in the column plan-rules/core.md gate 1 asks for:

Four repository deliverables, two repositories, on a childless bug leaf — one worktree, one pull request. It physically cannot ship, and picking a repo at run time is a forbidden per-repo scope decision. Gate 1: "go criterion by criterion and name the repo each one is discharged in; two repos in that column is a split, however the sentence is punctuated."

The correct shape was one card away, by the same author, the same day. MOTIR-3108 is the record for the sibling limb of the very same finding, and its product-code half was filed separately as MOTIR-3110 — kind: bug, type: code, targetRepo: motir-core, under a different parent, now done. Two cards, exactly as run.md's planner-bug-home rule prescribes: "A defect with both halves is two cards, not one card filed twice."

Why nothing caught it — TWO mechanisms, and both failed for stateable reasons

1 · The assertion did the checking's job

"No repository deliverable, which is why no targetRepo is pinned" was written before the criteria existed and never re-read against them. An unpinned card is what a record correctly looks like, so the empty targetRepo column read as evidence of care rather than as a column nobody had filled in. A claim about a card's own shape and the result of checking that shape are indistinguishable once written down, and the claim is what stops the check being run.

The ordering is the mechanism: the pin is decided when the card is a title and an intention; the criteria arrive afterwards and are what actually spend the repos. So gate 1 cannot be answered until the criteria are written, and the answer that was recorded is one from before they were.

2 · likely-repo-straddle ran, and was silent — correctly

validate_work_item on MOTIR-3158 at re-plan time returned valid: true, blockers: [], and three reference advisories with no shape entry at all. Its unpinnable arm exists for precisely this card — a card that pins no repo and whose criteria name two or more — and it did not fire, because criterionRepoPaths / firstRepoStraddleCriterion (motir-core/lib/workItems/proseVsGraph.ts:429, :512) key on repo-resolvable PATHS, and these criteria name:

• plan-rules/kind-leaf.md — a bare path that exists under prompts/ in motir-meta and matches nothing else it can resolve;
• run.md — a bare filename;
• validate_work_item — a symbol, not a path at all.

The check ran, had nothing to resolve, and reported nothing — which is not the same as reporting that nothing is wrong. This is a real and stateable limit of a shipped guard: the filenames a card about the planning corpus is most likely to name are exactly the ones the resolver cannot attribute. Recorded here as an observation about the detector's inputs, not as a defect in it.

3 · The self-reference, which is the part worth flinching at

The defect MOTIR-3158 exists to record is a card that declares its own shape in prose and does not perform it (kind-leaf.md's "THE SENTENCE IS THE SPLIT INSTRUCTION", on the design axis). The card recording it declared its own shape in prose — a record, no deliverable — and did not perform it. Writing about a failure mode with full attention is not protection against it; the attention goes to the subject and away from the instrument. notes.html #329's own account of the original defect ends "Neither the rule nor the precedent nor the author's own sentence was missing. Only something that reads them was." That sentence was true of its own card too.

Two criteria that were amended rather than carried into a card

Both surfaced by the same guard-#5 read, and both are findings in their own right:

1. Criterion 4 was ALREADY SATISFIED on origin/main. It asked run.md's guard #4 to read the new advisory at dispatch time. MOTIR-2878's W1 merged as ab9dac8 and widened that block to read the WHOLE advisories array, every family and every severity: "THE FAMILY LIST IS NOT THE TEST — the QUESTION is… An entry whose family you do not recognise is disposed of on that question and named in the report — never skipped for being off a list." So the criterion is true for free — and adding a fourth name to that paragraph's example list would work against the paragraph's own instruction. MOTIR-3158 was blocked_by MOTIR-2878 precisely because W1 edits that paragraph, and the edge was wired for the right reason; what nobody did was re-read the paragraph after W1 landed to see whether the criterion had anything left to do. A done blocker whose landing SATISFIES your criterion looks identical, from the graph, to one that merely UNBLOCKS it.
2. Criterion 5's substrate no longer exists. It asked for a fixture reproducing MOTIR-3154's criteria "as authored on 2026-08-19 — the seven-criterion leaf". get_work_item_activity on MOTIR-3154 records {kind: 'fieldEdited', field: 'descriptionMd'} at 2026-08-19T20:53:52.716Z, with storyPoints 8 → none and estimateMinutes 240 → none — its own re-plan's modify, materialized fifteen minutes after MOTIR-3158 was created (20:38:38.338Z). The tenant retains no prior descriptionMd (activity parts carry from/to for status, priority and links only), and notes.html #329 and the run comment both PARAPHRASE criteria 1 / 4 / 5 without quoting them. The criterion was authored against a body that the author's own re-plan, submitted minutes earlier, was about to overwrite. The remedy is on the motir-core card: a labelled RECONSTRUCTION table, carried in the card that commissions the fixture, so the fixture has a durable source.

The correction, already applied

Plan cmt0nyykx00s1i3phklcyax8h (planned, in the review queue) — three adds, one per repository, plus a modify returning MOTIR-3158 to the record it says it is:

MOTIR-3158 is at Blocked until the plan is decided. Nothing was archived.

One process defect of the RUN itself, recorded rather than hidden

The run's first plan (cmt0nxdb600qni3phtsm1jpdp) was appended without card 3's blocked_by edge onto card 2. blockedByRefs is settled at APPEND and update_plan_item explicitly "cannot re-parent a proposal, change its dependency edges or re-pin its repo" — so it could not be repaired. It was left generating, which means it never entered the review queue and cannot be approved (plansService.approve requires status === 'planned'), and a corrected plan was authored instead. The two-phase authoring path makes the SKELETON batch the only chance at the edge graph, and a skeleton is exactly the batch an author is most likely to send thinly. It leaves an un-decidable plan row behind; there is no MCP tool to cancel one.

Acceptance criteria

• Nothing to build. The correction is applied (the plan), the lesson is written (notes.html #333), and this card is the record.
• A future reader asking "why did gate 1 not fire on MOTIR-3158" finds the two mechanisms above — the assertion-as-answer and the silent resolver — rather than re-deriving them.

Context refs

• MOTIR-3158 — the card this is filed about. relates_to; this card consumes nothing it produces and holds nothing up.
• Plan cmt0nyykx00s1i3phklcyax8h — the three-card split. Abandoned skeleton: cmt0nxdb600qni3phtsm1jpdp.
• notes.html #333, motir-meta PR #270 — the lesson.
• MOTIR-3108 → MOTIR-3110 — the record→build-card split this card's subject should have reproduced, one card away.
• MOTIR-2878 (done, ab9dac8) — W1, whose landing silently satisfied MOTIR-3158's criterion 4.
• motir-core/lib/workItems/proseVsGraph.ts :429 (criterionRepoPaths) · :512 (firstRepoStraddleCriterion) — why the shipped straddle check was silent. Read on origin/main d3169391.
• plan-rules/core.md gate 1 — the rule; run.md guard #5 — its run-time backstop, which is what fired.