Motir

The record of the defect the 11.5 re-plan of 2026-08-07 corrected, filed as step 5 of THE REPLAN ACTION.

What was wrong

Story 11.5 sliced the CLI's port to /api/v1 by method group — reads (11.5.4), writes + orchestration (11.5.5) — and gave the read card the boundary "does NOT change … any command file" to protect render.ts's byte-identity.

That boundary cannot hold for a client port. A port changes VIEW MODELS, and every view-model field exists because a command reads it. So the boundary forbade exactly the edits the work requires, and each method whose shape moved had to be evicted:

1. nextReady → 11.5.5 (needs item.id / targetRepo / sessionBranch in auto.ts, batch.ts)
2. searchWorkItems → 11.5.17 (needs SearchPage.total in read.ts, doctor.ts, plan.ts)
3. getWorkItem → nowhere, because the work it needed was already inside 11.5.5 — a circular dependency between two subtasks of the same story.

Why the third one is the finding, not the third instance

The first two evictions each looked like a correct application of the boundary, and both were made by a run that had just re-read the card. Nothing in the plan can see that a boundary is systematically wrong: the ready set reads edges, validate_work_item reads edges, and each eviction produced a clean graph. The tell only became legible at the third, when the eviction had nowhere to go.

⚠️ CORRECTED at close-out, 2026-08-07 — this paragraph's second half was wrong. It read: "The rule that would have caught it earlier already exists — plan-rules.md's REPEAT-DEFECT TRIGGER … here the recurrence was a count of re-scopes forced by one boundary, which the trigger's own wording does not reach." The first clause holds and the second does not. A rule reaching this case exactly was already on main — not the repeat-defect trigger, but THE UNIT OF A MIGRATION IS THE SET OF CALLERS, NOT THE MECHANISM (plan-rules.md, promoted from notes.html #215): "when the card's verb is move / migrate / replace / route through / retire, grep for every caller of the mechanism being replaced BEFORE sizing it and list them in the card: each caller is in this card's scope or is a named sibling card, and there is no third option." The mechanism replaced is each read method's view model; its callers are the command files. The boundary is that whole caller list assigned to the third option the rule says does not exist — and it was performable at authoring time, with no eviction needed to reveal it.

The correction

11.5.19 — the exclusion list and the dispatch loop move to key on the CURRENT transport, which is what dissolves the cycle. The load-bearing observation is that selecting from a ranked ready set is transport-agnostic, so the migration never needed the port at all; every sequencing attempt had assumed it did.

The promote question — SETTLED: LESSON, not a rule (2026-08-07)

The candidate sharpening — give the REPEAT-DEFECT TRIGGER a second input, a count of forced re-scopes of one card — is NOT promoted. Settled, not deferred: the conditional form must not be restored (notes.html #221). Three grounds, strongest first:

1. The governing clause covers the case and predates the defect by 13 hours, in both homes. plan-rules.md's migration-callers rule landed on main 2026-08-05 01:28Z (motir-meta PR #115), mirrored verbatim in SHARED_PLANNING_RULES; MOTIR-2212 was authored 2026-08-05 14:22Z, same planner, same story. A rule whose governing clause covers the case and whose fixture does not is a diligence miss, not a trigger gap.
2. The proposed widening would break the trigger's one load-bearing property. It is firable only because its input is a read of the plan TREE, available to both homes (notes.html #166). A re-scope count is an activity-history read the shipped planner never receives — and of the three evictions, one moved into an EXISTING sibling and one went nowhere, so a tree-observable proxy counts one, not three.
3. The family is one. Counted by content, the neighbours (#206, #211) are a different check — a criterion unreachable from inside the card's own boundary — and the standing gate covers both as written. MOTIR-2212's criteria were each satisfiable inside its boundary, which is why that gate did not fire here either.

Acceptance criteria

• motir-meta/notes.html carries the mistake entry (count bumped, .mistake markup) recording: the boundary that could not hold, the three evictions, and that the cycle was only visible at the third.
• The entry states the transferable lesson: a card's scope boundary is a CLAIM about the work, and a boundary that forces a second eviction of the same shape is evidence the decomposition axis is wrong — not a rule to keep applying.
• It records the candidate sharpening for plan-rules.md's repeat-defect trigger — that its input should count forced re-scopes of one card, not only bug cards — and says explicitly whether that is being promoted to a RULE now or left as a LESSON (per the RULES-vs-LESSONS routing, the default is LESSON).
• Lands via a branch + PR against motir-meta, with NO MOTIR-<n> in the branch name or PR title.

Close-out verification (2026-08-07)

• AC 1–2 were already discharged by notes.html #233, merged as motir-meta#135 at 2026-08-07 00:52Z — nine minutes after this card was filed. Entry count and the "Across the N mistakes" line both read 234, consistent; no duplicate mistake-num, so #233 is genuinely #233 with no collision renumber.
• AC 3 was NOT discharged — #233 recorded the candidate and never stated a verdict. Settling it was this card's real deliverable, and it lands in motir-meta#137 as a Verdict section on #233, plus a correction to that entry's own diagnosis and a mechanical authoring-time check in its prompt hint. html.parser tag balance identical before/after.
• Citations re-verified, all exact — say so plainly rather than implying drift not found: 11.5.4's comment thread does carry the full diagnosis and the correction of its own false item.id claim (dispatch.ts:312); the three evictions and their destinations are as stated; plan-rules.md's REPEAT-DEFECT TRIGGER exists with the quoted wording and the bug-card input.
• The one drifted citation is the card's own reasoning, corrected above: the rule that should have fired is the migration-callers rule, not the repeat-defect trigger.
• No competing PR — gh pr list --repo moooon-B-V/motir-meta --state open was empty before this branch, so there is no sibling notes.html append to sequence against.
• Close condition: the merge of motir-meta#137. This card rests at In Review until then — a motir-meta PR carries no MOTIR-<n>, so the status sync cannot flip it.

Context refs

• motir-meta/prompts/plan-rules.md — the REPEAT-DEFECT TRIGGER, the migration-callers rule that actually covered this, and the RULES-vs-LESSONS routing.
• motir-meta/prompts/plan-procedure.md — THE REPLAN ACTION, step 4.
• 11.5.4 — its comment thread carries the full diagnosis and the correction of its own false item.id claim.
• Story: 11.5.