Motir

Repo: motir-meta. One PR. The RULES-tier half of the promote verdict settled by MOTIR-2440 and recorded in the Promote verdict section of notes.html's entry "A design merged AFTER the cards that build to it, named six of them by key, replaced one card's layout and another's whole shipping premise — and amended neither." Its motir-ai mirror is a sibling card — see "Two homes" below.

This card does not re-litigate the verdict. The verdict is settled: the incident stays a LESSON and widens the existing design-allocation limb in place. This card lands that widening, which is three edits and no new rule.

The defect being fixed, in one sentence

The design-allocation limb states its discharge as "grep the asset you just wrote for every MOTIR-<n> it names" — and the card whose premise this design invalidated is not named in the asset, so a perfectly-executed discharge provably cannot reach it.

The rung-2 evidence (read on motir-core origin/main): the asset heads its section "Story MOTIR-2255 · Subtask MOTIR-2259 output", because it was authored before the 2026-08-06 re-slice moved the page out of MOTIR-2255 into MOTIR-2282. grep -c 'MOTIR-2282' over both design/projects/design-notes.md and design/projects/roles-permissions.mock.html returns 0. The keys the asset does name are 2255, 2256, 2257, 2258, 2259, 2263, 2277, 2291, 2294, 2347 — and 2255, the story it points at, is done with nothing to amend.

The three edits

(a) Clause (c), lifted onto the design limb from its twin. The DECISION limb of the SAME sweep-the-referrers corollary already carries it verbatim: "(c) The sweep is NOT bounded by the cards the decision names — in #196 the un-swept item was a sibling STORY the decision never mentioned. The grep is over the TREE; the decision's list only tells you where to START." The design limb has no equivalent sentence. Add one, and give it the reason clause (c) needs here that #196 did not need: a re-slice between a design's authoring and its merge relocates the affected card OUTSIDE the asset's key list, so the asset's keys say where to start and the subtree says where to stop.

(b) GIVES/TAKES widened past ELEMENTS. The question as written is whether the design gives card X an element or takes one away. This asset replaced a structure (matrix → drill-down) and invalidated a premise (a story's shipping gate), and an honest answer to the element question on either is "neither". The question must read on an element, a structure, or a premise.

(c) The run-time half re-homed off the UI-only gate. It currently lives at run.md guard #3, the DESIGN gate, which fires on UI-touching subtasks only. The two consumers that went stale here are a story's acceptance criteria and a DTO/service card (MOTIR-2439) — neither ever reaches guard #3. State it as a check that runs for any card whose design blocker merged after the card was authored, with the CALENDAR trigger the lesson's prompt-hint already gives: compare the design's merge date to the card's createdAt; if the design is younger, the asset outranks the card, whatever kind the card is.

Where the wording lives — THREE sites, all in motir-meta

The design limb has two homes in plan-rules.md and both state the asset-bounded discharge, so both need (a) and (b):

1. prompts/plan-rules.md, the gate 8 checklist bullet "A design ASSET'S ALLOCATION TABLE TAKES AS WELL AS GIVES".
2. prompts/plan-rules.md, the corollary prose — "The SECOND artifact that fires this corollary is a design asset, and it fires by ALLOCATION rather than by redefinition".
3. prompts/run.md — edit (c)'s re-homing of the run-time half. Guard #3 keeps its own sentence for UI cards; the general form must be reachable by a card that never opens a mockup.

Scope BOUNDARY

Markdown in motir-meta only — a docs-only diff. It does NOT touch motir-ai (that is the mirror card's PR, which is blocked_by this one), does NOT add a new numbered rule or a new gate, and does NOT edit the notes.html lesson entry, whose Promote verdict section is MOTIR-2440's deliverable and already merged.

Acceptance criteria

• Both plan-rules.md sites named above state that the sweep is over the TREE and that the asset's MOTIR-<n> list only says where to START, each giving the re-slice reason; grep -n 'MOTIR-2282' prompts/plan-rules.md finds the fixture cited at least once.
• Both plan-rules.md sites ask the GIVES/TAKES question over an element, a structure, or a premise — the word premise appears in the discharge sentence at each, not only in the fixture prose.
• prompts/run.md carries the run-time half in a form that a non-UI card reaches: the sentence does not sit inside guard #3's UI-touching condition, and it states the calendar comparison (design merge date vs card createdAt) as the trigger.
• The fixture is named at each site as this incident — the story MOTIR-2282, the asset design/projects/design-notes.md, and the grep -c returning 0 — cited by CONTENT, since the lesson entry's number shifts on append collisions.
• The wording added at sites 1 and 2 is liftable verbatim into SHARED_PLANNING_RULES — no run.md-only or motir-meta-only cross-reference inside it that the mirror would have to rewrite.
• Branch docs/<slug> with no MOTIR-<n> in the branch or the PR title (the motir-meta status-sync rule); the card reference goes in the PR body.

Context refs

• motir-meta/prompts/plan-rules.md — the gate 8 bullet (the design ASSET'S ALLOCATION TABLE bullet inside gate 8) and the corollary prose; the DECISION limb's clause (c) immediately above it, which is the text to lift.
• motir-meta/prompts/run.md — guard #3, the current home of the run-time half.
• motir-meta/notes.html — the lesson entry named above and its Promote verdict section, which carries the four grounds this card implements.
• motir-core design/projects/design-notes.md + roles-permissions.mock.html — the fixture asset; the grep -c 'MOTIR-2282' → 0 evidence.
• Precedent for the two-repo split: MOTIR-2100 (motir-meta) + MOTIR-2099 (the mirror); MOTIR-2446 + MOTIR-2448, the most recent pair.