Planning bug: a new surface's SCOPE was settled from competitor precedent without reading the shell tier it was being placed in — and the card had to invent a duplicate nav row to make the mismatch fit

Type: chore (record card — the correction is applied by the time this is filed) · Parent: MOTIR-1465 (the planner-bug home) · Filed about: Story MOTIR-2649 / Subtask MOTIR-2651 · Product defect it produced: MOTIR-2761.

What the plan missed

MOTIR-2649 had to decide the SCOPE of a brand-new landing surface. It decided workspace-wide (cross-project), and argued it from a four-row table of external precedent — Jira "Your work", Linear Inbox, Plane Home, GitHub's 2026 home dashboard. The argument is careful, sourced, even cites a live Atlassian ticket. It is also answering the wrong question.

In all of those products the surface it cites sits ABOVE the project selector in the navigation. Its scope is cross-project because its placement is cross-project — the two are one decision, not two. Motir took the scope and left the placement to a different card, and MOTIR-2654 then put Home first in the project tier of the rail (SidebarNav.tsx:218, inside if (hasProject), above Dashboard / Issues / Ready / Boards / Backlog — every one of which resolves an active project), directly under the org › workspace › project switcher the shell renders on every authed page.

The shipped result: the project switcher does nothing on the page sign-in lands you on, and tests/e2e/home.spec.ts:229 asserts that as the contract.

The evidence was inside the plan's own output the whole time. MOTIR-2654 could not place the surface without inventing a second, duplicate Home nav row for the no-project state (SidebarNav.tsx:346-365), with a comment explaining that Home is exempt from the tier it was put in. And MOTIR-2653 could not render a row without reading a different workflow per project just to label its own statuses (app/(authed)/home/page.tsx:69-80). Two special cases, both authored without comment, both of them the surface paying rent on a boundary it should not have crossed. Neither fired a gate, because no gate reads a card's workarounds as evidence about its premise.

Why no existing gate caught it

• The precondition-verification rule fires on claims about shipped code ("X exists", "Y is unbuilt"). Every precondition MOTIR-2649 grepped was true and correctly cited. The false premise was not a fact about the repo — it was an inference from another product, and nothing in the corpus treats a competitor precedent as a claim requiring verification against our own surface.
• Gate 14 (AC satisfiable inside the boundary) reads criteria against the card's own exclusion list. The ACs here were internally consistent; the boundary itself was wrong.
• The design gate was satisfied — MOTIR-2650 drew the surface. But the asset drew the page, not the page in its rail, so it reproduced the scope claim rather than testing it.

This is the first occurrence of the class, so per plan-rules/CORPUS-MAINTENANCE.md it is captured as a LESSON (notes.html), not a RULES-tier change — which is also why this card has no SHARED_PLANNING_RULES mirror sibling ([[planning-rule-has-two-homes]] applies to rules, and no rule is being added). If the class recurs, the rule limb belongs in plan-rules/phase-skeleton.md beside the precondition-verification rule, and it will then owe two homes.

Fix applied / Resolution taken

• MOTIR-2761 filed against Epic 8 — the product defect, with the verified diagnosis, the fix direction (getActiveProject() at the page, projectId narrowing in homeService; the repositories already take projectIds), the tests to invert, and the two open decisions the fix owes Yue (the no-project state, and whether a cross-project "my work" survives at a different nav tier).
• No plan restructure: MOTIR-2649 and its six subtasks are done and shipped; the correction is a new fix card, not an archive-and-recreate.
• The lesson is this card's remaining deliverable — a notes.html entry, on a docs/ branch + PR per the motir-meta convention.

Acceptance criteria

• motir-meta/notes.html carries a new .mistake entry for this class — what the plan missed, the lesson, and the prompt-hint — with the entry count bumped to match.
• The entry names its warrant concretely: MOTIR-2649's precedent table, the placement in SidebarNav.tsx, and the two workarounds (the duplicate nav row, the per-project workflow read) as the observable tell.
• The entry is filed as a LESSON only; it adds no rule to plan-rules/ and therefore names no SHARED_PLANNING_RULES mirror.
• This card is closed out by hand (todo → in_progress → in_review → done) — a motir-meta PR carries no MOTIR id, so no status sync flips it.

Context refs

• MOTIR-2761 (the product defect) · MOTIR-2649 § Scope: cross-project, within the active workspace · MOTIR-2650 (design) · MOTIR-2654 (the door)
• motir-core: app/(authed)/_components/SidebarNav.tsx (both Home rows) · app/(authed)/_components/ProjectTier.tsx · app/(authed)/home/page.tsx · lib/services/homeService.ts · tests/e2e/home.spec.ts:229
• motir-meta: notes.html · prompts/plan-rules/CORPUS-MAINTENANCE.md (LESSON vs RULE) · prompts/plan-rules/phase-skeleton.md (where a rule limb would go on recurrence)