Planning bug: MOTIR-3440 NAMED `PageSkeleton` as unowned and created no card, so MOTIR-3443 shipped `ready` with an acceptance criterion nothing could satisfy

Type: bug (planning) · Home: MOTIR-1465 · Found by: motir run MOTIR-3440, guard #4, 2026-08-26 · Card it was found on: MOTIR-3443 · Correction submitted as: plan cmt9dlzvg00c1i1n83d0fc9zd

What the plan did

MOTIR-3440's amendment names three things the story needs that no card owns — the PageSkeleton primitive, the shell's window-1 pending mark, and /items/[key]'s own frame — all reverted with MOTIR-3433/MOTIR-3435 — and closes with:

"Naming them here rather than adding cards: the shape of that fix is a planning decision, not this run's."

MOTIR-3443's own amendment repeats it as a labelled heading: "Prerequisite this card cannot supply for itself: PageSkeleton … does not exist on main."

So the prerequisite was identified, verified, written down twice — and given no owner.

Why that is a defect and not a deferral

A deferral has a card, a place in the order, and a blocked_by edge that keeps the consumer out of the ready set. This had none of the three. What it produced instead:

• MOTIR-3443's amended AC 1 requires the settings frame module to compose PageSkeleton — a criterion nothing on the board could satisfy.
• The card nevertheless read todo · ready: true · openBlockers: [], and validate_work_item on the parent returned valid: true with no blocker naming it. Every automated signal said startable.
• MOTIR-3448, MOTIR-3449 and MOTIR-3450 sit behind it, so the orphan holds four of the story's ten children.

The advisory tier could not have caught it either, and that is worth recording: likely-missing-edge scans a card's description for work items it references without an edge. PageSkeleton is a module, not a work item — there was no key to key on. The detector was working correctly and had nothing to see.

Evidence — measured on origin/main 052965b3

git ls-tree -r origin/main --name-only | grep -i PageSkeleton         → (nothing)
git grep -l PageSkeleton origin/main -- app components packages lib   → (nothing)
git grep -c PageSkeleton origin/main -- design                        → design/settings/design-notes.md:5
                                                                        design/shell/design-notes.md:4
                                                                        design/work-items/design-notes.md:2

No file; no reference in any code tree; eleven references across three merged design assets, two of which this run itself shipped (MOTIR-3441, MOTIR-3442).

The fix, already applied

Plan cmt9dlzvg00c1i1n83d0fc9zd proposes the PageSkeleton card as a sibling under MOTIR-3440 and wires MOTIR-3443 blocked_by it. MOTIR-3443 is at Blocked with the finding on it.

A second plan, cmt9dk0bs00a2i2phxl2xb5x1, must be DECLINED — a superseded first attempt whose modify carries an unresolvable planItem:PLACEHOLDER ref, because both proposals were sent in one batch and the add's id did not exist yet. That is a separate, smaller finding about how this run authored the plan, not about MOTIR-3440.

Acceptance criteria

1. Plan cmt9dlzvg00c1i1n83d0fc9zd is approved or declined on its merits, and plan cmt9dk0bs00a2i2phxl2xb5x1 is declined.
2. The other two orphans MOTIR-3440 names — the shell's window-1 pending mark (useLinkStatus, which git grep -l useLinkStatus origin/main finds only in design/shell/), and /items/[key]'s reverted frame — are each given an owner or an explicit written decision that they are out of scope, on the record. Naming them a second time without a card is the same defect repeated.
3. The lesson is recorded in the lesson corpus (see below), so the next planner meets the rule before it drafts the same shape.

Resolution

Open. The lesson is a GLOBAL row — the takeaway survives stripping every repository name, key, path and surface — so it is authored in motir-ai src/seed/lessons.base.ts with its generated migration rather than through add_lesson.