PLANNING BUG — a container whose child's job is to FILE CARDS can never finish its own PR, and its title promised what the merge cannot deliver

Record card. Caught by Yue on 2026-08-10 — "2435 has unimplemented children" — after motir run MOTIR-2435 had already opened its parent→main PR. The correction is applied; there is no PR and no code change.

This is the second planning bug on MOTIR-2435 (MOTIR-2517 was the first, about a false premise). Different defect, and worth recording separately because nothing about the first would have caught it.

What was wrong — two faults, one root

MOTIR-2514, a child of the container, had this acceptance criterion:

Every lib/ group is filed as its own code work item under MOTIR-2435 …

So the run did exactly that, and filed MOTIR-2527 + MOTIR-2528 as new CHILDREN of the container it was in the middle of closing.

1. The container became un-completable by construction. A parent-run opens ONE PR, and only "when EVERY subtask is committed on the parent branch". A child whose deliverable is filing cards under the parent adds un-landed children faster than the run can close them. The PR was opened anyway, with two todo children — which is what Yue saw.
2. And the title promised what the merge cannot deliver. "Adopt the motir_app runtime role so workspace RLS actually executes" — after this PR merges, RLS still does not execute in production; that needs 2527, 2528 and the cutover 2515. The status sync flips a PR-linked card to done on merge, so the card would have closed green on work that had not happened.

The container's own body even said so — "This container is not finishable on today's tree, and deliberately so" — which is the tell. A sentence admitting a card cannot be finished is not a caveat to note; it is a card that needs re-slicing. It was written, read, and left in place through an entire run.

The check that would have caught it

A container's acceptance criteria must be discharge-able by its own PR. Concretely, at authoring time:

• No child may have "file a card under this parent" as a deliverable. Discovery work belongs to the parent's SUCCESSOR, or its output goes to a sibling of the parent — never to the parent's own child set, which the parent's PR must close over. motir run <parent> cannot converge otherwise.
• Read the container's TITLE as a claim about the merge. If the title names an outcome that needs a later card, the title is wrong, not the plan. Here the honest split is adoptABLE (this PR) vs adoptED (the chain).

This is gate 14's ORDERING axis one level up: that axis catches a CRITERION that reads on post-merge state; this is a whole CONTAINER whose completion does. Both are "the boundary ends at the PR", applied at different altitudes.

Fix applied — 2026-08-10

• MOTIR-2527 and MOTIR-2528 re-filed as tasks under Epic 8, out of the container.
• Edges lifted to a same-level chain: MOTIR-2435 → 2527 → 2528 → MOTIR-2515. The direct 2515→2435 edge was removed as transitively covered.
• MOTIR-2435 re-titled to "make the runtime role ADOPTABLE", its "plus every card 2514 files" criterion struck on the record, and PR #1990 re-titled to match.
• Nothing archived; no scope moved between cards, only containment.

Close-out condition

Verify the chain in the tenant and that PR #1990's title matches the re-scoped card. Nothing else gates this; do not wire it blocked_by its own subject.