Motir

Repo: motir-ai. One PR. The second home of the rule MOTIR-2975 lands in motir-meta (motir-meta PR #242), per the standing two-homes rule: a planning RULE lives in motir-meta/prompts/plan-rules/ for the manual planner AND in SHARED_PLANNING_RULES (src/llm/planningRulePacks.ts) for the shipped one. Precedent: MOTIR-1645 → MOTIR-1646, MOTIR-1773 → MOTIR-1774, MOTIR-1752.

Only ONE of MOTIR-2975's two halves is liftable — and that is the point of this card

MOTIR-2975 wrote a limb under gate 4 with two halves. They do not have the same observability in this home, so the mirror is deliberately NARROWER than the motir-meta wording. Verified on origin/main @ d8e90d8:

Why the gap is real and not already covered. VERIFY_EVERY_PRECONDITION already carries gate 4 in full — "THE COMMONEST CASE BY FAR IS NOT ABSENCE … THE EDGE IS blocked_by, NEVER relates_to", the mechanical discharge, and the acceptance-criterion sub-case. What it does not say is that a reference the author has ALREADY LINKED still owes that discharge. Its discharge reads "resolve every work-item reference in the body to its status before sealing", and a reference carrying a relates_to does not present itself to its own author as unresolved — it presents as a card they just wired. That suppression is the whole mechanism MOTIR-2975 found, and it is the half that survives the move into this home.

Acceptance criteria

1. PLANNING_RULE_VERIFY_EVERY_PRECONDITION in src/llm/planningRulePacks.ts gains a clause stating that an existing edge to a work item is not evidence that item's status was resolved — so the mechanical discharge runs over EVERY referenced key, including keys the proposal already links, and a relates_to already written is the case most likely to be skipped rather than the case least likely to need checking.
2. The clause names both edge kinds explicitly and says they are not degrees of one relation: relates_to is a note, blocked_by holds the item out of the ready set, and the graph can infer neither from the other. It does NOT restate the blocked_by-never-relates_to sentence already in the constant.
3. The clause carries neither excluded half — no notes.html #27 filing protocol, no worktree, no branch-vs-base measurement. A reader of this constant alone must not be told to check a thing this planner cannot observe (notes.html #166 — a rule is only a rule if its reader can observe its input at the moment it fires).
4. A test in the repo's existing planning-rule assertion suite pins the new clause by phrase, in the same shape as the phrase assertions already covering SHARED_PLANNING_RULES, so a silent re-wording of the shipped planner corpus is a red test.
5. ORDERING — this card runs AFTER motir-meta PR #242 merges (MOTIR-2975), because the mirror LIFTS that wording rather than re-deriving it; it is wired blocked_by that card. If the motir-meta wording changed in review, this card mirrors what actually merged, not what this description quotes.
6. MOTIR-2975's own motir-meta limb is NOT edited from here — one subtask, one repo, one PR.

Context refs

• MOTIR-2975 / motir-meta PR #242 — the motir-meta half; prompts/plan-rules/core.md's same-key limb under gate 4 is the text being lifted.
• src/llm/planningRulePacks.ts — PLANNING_RULE_VERIFY_EVERY_PRECONDITION (the gate-4 mirror this clause joins) and DEPENDENCY_GRAPH_IS_THE_BUILD_SEQUENCE (where the planner is told to author relates_to on the REUSE axis — the edge that does the suppressing).
• READ-ONLY: src/core/coreClient.ts CreateBugInput / createBug, and src/services/lessonService.ts — the evidence for excluding the #27 half; the shipped filer has no edge parameter.
• MOTIR-1646 / MOTIR-1774 / MOTIR-1752 — the three prior mirrors, for the shape of the edit and its test.