Planning bug: MOTIR-3229 names THREE homes and assigns home 2 to MOTIR-3203, which closed without it — `run.md`'s parent-run still stops only on a `design`/`manual` stopper

Type · planning (a standing RULE with more than one home, landed in only one)

Parent · MOTIR-1465 — the planner-bug home. The fix changes a RULE (motir-meta/prompts/run.md), not product code, which is the discriminator run.md's planning-bug-home rule states.

Discovered in · executing MOTIR-3229 (motir-core, home 1 — the derivation layer + the transition gate).

Root cause / fix

MOTIR-3229's body partitions one defect across three homes and says outright that "a fix that lands in one home leaves the other two shipping the defect". It then assigns them:

MOTIR-3203 is done, and the generalisation is not in prompts/run.md. Verified against the current file, motir run <parent> step 6 (prompts/run.md:1504):

ONLY when EVERY subtask is committed on the Story branch — open ONE Story PR … If a STOPPER (a design / manual child, step 5) left ANY child un-landed, the parent is NOT complete — do NOT open the parent→main PR.

A bug the run itself filed under the parent is neither a design child nor a manual one, so by the words on the page it stops nothing — and "EVERY subtask" reads as step 0's partition, the child set as it stood at t=0, which is the one set guaranteed not to contain it. The post-deploy warning at :1520 already says "READ THE CHILD SET BEFORE YOU OPEN THE PR" and names exactly ONE thing to look for; the general form is the missing generalisation, not a missing instruction.

So the rule has two homes, one of them was landed, and the other's named owner closed without it — the sixth-plus instance of the shape notes.html #338 records.

Fix direction (MOTIR-3229's own words for the disposition): re-read the container's CURRENT child set immediately before opening the parent→main PR, and treat any child not landed as a stopper whatever its kind, including one this run created. The disposition for such a child is one of exactly three, never silence — run it (it is in scope now), re-parent it OUT (plan-rules/core.md gate 14(c), what the post-deploy warning already prescribes), or stop and hand it to the user.

Cross-check against what now ships. MOTIR-3229 adds a server-side gate: applyStatusTransition refuses implemented / in_review on a container with a child below implemented (CONTAINER_HAS_OPEN_CHILDREN, 422, naming the children). That makes a hand-run that ignores this rule fail loudly at the status flip instead of silently shipping — but the flip happens AFTER the PR is opened, so the prose still has work to do: point 4 of MOTIR-3229 is that the parent PR should not exist while the story is not implemented.

Acceptance criteria

• prompts/run.md's motir run <parent> step 6 states the GENERAL rule: re-read the container's current child set before opening the parent→main PR, and any child not landed stops the PR whatever its kind — explicitly including a bug this run filed under the parent.
• The three permitted dispositions (run it · re-parent it out · stop and report) are named, and silence is stated as not one of them.
• The existing post-deploy warning is kept and re-framed as an INSTANCE of the general rule rather than the whole of it.
• The step names the shipped server-side refusal (CONTAINER_HAS_OPEN_CHILDREN) and says the runbook's job is to reach it BEFORE the pull request exists, not after.
• git grep -n "design. / .manual. child" motir-meta/prompts/run.md no longer returns the ONLY refusal spelled out in step 6.

Where it was seen

prompts/run.md:1504–:1532 read on 2026-08-20 while executing MOTIR-3229; MOTIR-3203's status read from the live tenant.