Motir

Repo: motir-meta. One PR. Filed by the motir run MOTIR-1465 sweep of the planner-bug home (2026-08-16), which triaged all 24 open captured planning bugs together and could therefore see across them. Every clause below is a WIDENING of an existing paragraph's trigger — no new gate is added, which is the cheaper and more defensible shape (CORPUS-MAINTENANCE.md: SHARPEN an existing rule before adding a new one).

The mirror half is MOTIR-2879 (motir-ai SHARED_PLANNING_RULES), which is blocked_by this card. W1 is run.md and has no mirror; W2–W4 are plan-rules/ and do.

Each widening is independently droppable. They are folded into one card because they land in two files that a second card would collide with, not because they stand or fall together.

W1 — run.md guard #4 reads the WHOLE advisories array, not one severity

Guard #4's advisory block says: "For every likely-missing-edge, git ls-tree / git grep origin/main for the file, symbol or test the criterion names." Followed literally, a plain advisory is never checked — and validate_work_item's shape family (likely-ordering-violation, likely-repo-straddle) is not mentioned by the guard at all.

Three instances, three different failure points in one family:

MOTIR-2877 is decisive because it indicts a sentence in the runbook rather than an author: MOTIR-2872's acceptance criteria named its two satisfied predecessors while the unmerged artifact it appends to was named in the description, so its true blocker was sorted into the lower bucket by the documented rule, working correctly.

The widening: read every entry, both families, all severities. likely-missing-edge raises the priority of a check; it does not define which references get one. A plain advisory naming a not-done card is exactly as unbuildable as a flagged one when the card's deliverable appends to that card's output.

And name the shape family in the guard. MOTIR-2779 asked for a new gate-1 corollary — a criterion naming a path is checked against the card's targetRepo — and it already ships as likely-repo-straddle, mechanised by MOTIR-2177. The gap was never the rule; it was that the guard tells the runner to skip the tier the answer arrives in. Writing a prose rule for a check that already runs in code is the exact inversion notes.html #219 records.

W2 — the dependency-arrow audit gains the MEASUREMENT limb

plan-rules/phase-skeleton.md's audit asks which sibling must ship before this card can be BUILT or CLICKED THROUGH. Both questions are about producing the thing the card edits. Neither reaches a card whose acceptance criterion is a measurement.

The widening: when a card's acceptance criterion is a measurement — a count, a verdict, a suite result, "reports", "shows none" — the blocked_by is owed to whatever makes that measurement TRUSTWORTHY, not only to whatever produces the thing being measured. Two cards can touch entirely disjoint files and still carry a hard ordering, because one builds the instrument the other reads.

Two independent instances, four days apart, both reaching this sentence unprompted: MOTIR-2791 (app-layer cards declared independent of the fixture batches their verification runs on — the suite was red on its own unmigrated fixtures, so it could not distinguish "the read is blind" from "the fixture died first") and MOTIR-2863 finding 3 (a card that flips a global DEFAULT is downstream of every card that makes the new default survivable, whether or not it touches their files).

The lexical tell: the word "independent" in a card whose criteria name a path, a suite or a fixture directory owned by another card.

W3 — the blocked_by boundary rule gains a NO-LEGAL-LIFT limb

plan-rules/phase-skeleton.md states, without qualification: "none crosses a PARENT (a subtask under story A never blocks a subtask under story B) … LIFT every cross-parent need to the level where the two nodes are siblings."

MOTIR-2848 was filed as a false belief about the tool — "it is in a different parent, so there is no blocked_by edge" — and diagnosed as the planner being wrong about link_work_items. Re-read during this sweep, that diagnosis is wrong: the planner was applying this rule. The cards were MOTIR-2768 (a subtask under story MOTIR-2765, itself under Epic 7) needing MOTIR-2764 (a bug under story MOTIR-1627, a different epic). Lifting to sibling level lands at the epic tier — one epic blocking another because one subtask needs one bug — and the rule's own worked form ("story blocks story (under the same epic)") does not even offer the story-tier hop.

So the rule had no legal move, and the run wired the forbidden leaf edge anyway (2768 blocked_by 2764) — correctly, and the card then blocked and the run continued on its other children.

The second instance is independent and states the problem in almost the same words. MOTIR-2831: "the honest blocked_by had to be wired at the card tier (2817 → 2784) — a story-tier edge would have been rejected as a cycle. The card model made the truthful edge unrepresentable at the tier where the dependency actually lives."

The widening: lift first — but when lifting would create a cycle, or would block a container on work only one of its children needs, wire the LEAF edge and record the reason on the card. A dependency that cannot be lifted is still a dependency; the ready set must hold the card out.

This does not repeal the boundary rule and must not read as though it does. The default stays: cross-parent needs are usually a level-up dependency, and MOTIR-2280 (2026-08-06) correctly refused a widening on the adjacent axis — there the governing sentence covered the case and was simply not performed. That was a diligence miss; this is a totality failure, and the discriminator between them is whether a legal edge existed.

W4 — the story TITLE is a coverage checklist, at authoring time

plan-rules/op-replan.md already reads titles: "a title carrying the dead mechanism is an unswept card." The trigger is scoped to a re-plan, so nothing reads a title when it is written.

The widening: a container title carrying a comma-separated LIST of deliverables is a coverage claim — walk each clause against the child set and name the child that owns it, at authoring time as well as on every re-plan. A clause with no owner is the gap, and the verification_recipe will not catch it: a recipe written about one clause passes the journey audit while the others go unowned.

Instance: MOTIR-2755, "Adopt the motir_app non-bypass role — the tenant reads, the test fixtures, and the deployed runtime", 25 children, nothing binding the read surface (55 unbound reads across 20 services). Two clauses of three had owners. The story would have gone done with its first named deliverable undelivered, and the cutover card would then have switched production to a role under which most reporting surfaces return empty. The re-plan-side half already fired once on the same axis (MOTIR-2844: a title still promising 577 after the body was re-measured to 458).

W4b — the enumeration card's SIZE axis. This is the most droppable clause on this card and its honest family count is ONE. An enumeration card's acceptance criteria may describe the enumeration only — complete, evidence-backed, every entry disposed. The absence of the class belongs to the card that REPAIRS it; where no such card exists, filing it is the enumeration card's real deliverable. It is included because its tell is purely lexical: on a card whose verb is inventory / catalogue / adjudicate / audit / enumerate / survey / measure, any criterion containing "no remaining", "shows none", "is zero", "is empty" or "all … are fixed" is on the wrong card. Drop it if the register reads as narrative.

Acceptance criteria

1. prompts/run.md guard #4's advisory block carries W1: every advisory is read, both families named (reference and shape), and likely-repo-straddle named as the shipped mechanisation of the repo/path check — with the explicit note that a prose rule is NOT to be added for it.
2. prompts/plan-rules/phase-skeleton.md carries W2 and W3, each as a widening of the paragraph it belongs to rather than as a new bullet, with its lexical tell.
3. W3's text states the DEFAULT (lift) first and the limb second, and names the diligence-vs-totality discriminator so it cannot be read as repealing the boundary rule.
4. prompts/plan-rules/kind-container.md or kind-story.md — whichever holds the story-composition rules — carries W4, and W4b if kept.
5. Each clause carries its evidence tag in COMPRESSION.md § Decision 1's printed form, with its warrant fixture entry, and python3 prompts/plan-rules/COMPRESSION.conserve.py is run and its verdict quoted in the PR body. ⚠️ Expect [FAIL] on any pack this card adds a rule to — that is MOTIR-2773, a known defect in the checker (it has no verdict for added), not a defect in this PR. Quote the INSERT list and say so.
6. The PR body states, per clause, the instance count and whether the family is post-rule — no clause is defended by a count this card did not re-derive.
7. MOTIR-2879 carries the same W2/W3/W4 text into SHARED_PLANNING_RULES. W1 is run.md and has no mirror; say so on both cards so the next reader does not go looking for it.

Context refs

• prompts/run.md § guard #4 (the advisory block) — W1's edit site.
• prompts/plan-rules/phase-skeleton.md — the dependency-arrow audit and the boundary rule; W2 and W3's edit sites.
• prompts/plan-rules/core.md — gate 2's claim-vs-pointer limb. NOT edited here: the QUANTITY clause for that limb is MOTIR-2702 criterion 4, on evidence #257–#260. Coordinate; two cards editing core.md is what folding exists to prevent.
• MOTIR-2877 (W1) · MOTIR-2831, MOTIR-2848 (W1, W3) · MOTIR-2779 (W1, the mechanised half) · MOTIR-2791, MOTIR-2863 (W2) · MOTIR-2798, MOTIR-2844 (W4) — the records, all children of MOTIR-1465.
• notes.html #275–#282 (motir-meta PR #193) — the lessons these widenings are drawn from.