Record card — the correction is already applied; this exists so the planner's own miss is triageable. Filed about: MOTIR-2649 (Home, done) · Product half: MOTIR-2758 · Lesson: notes.html #262 (authored in this pass; see Close condition).
MOTIR-2649's My work criterion reads "My work lists every item in the active workspace where the reader is the assignee OR the reporter, across every project the reader may browse, each item appearing exactly once, with its project identifiable on the row."
Three totalities — every item, every project, exactly once — and no bound on status. Nor did any of the story's other six criteria mention it, nor design/home/design-notes.md, whose "What this asset does NOT decide" section enumerates ordering, paging and the landing route and stops there. The build was faithful: workItemRepository.findByAssigneeOrReporterInWorkspace and watcherRepository.listByUser filter on workspace, browsable project, archivedAt, triagedAt and the person axis, and nothing else. The result is that Motir's post-auth landing page lists the reader's finished work — 87% of it, newest first, because the last thing that touches an item is its merge.
The card had the answer written on itself. Its own subtitle copy shipped as "Everything across {workspace} that is waiting on you" and its empty state as "Nothing is waiting on you", and its explanation opens "The first screen after signing in is the product's answer to what should I do now?". A done item is not waiting on anyone. The lifecycle predicate was stated in the card's prose and never reached its criteria.
And the product had already expressed it, twice. lib/savedFilters/builtins.ts compiles the built-in My open issues as assignee + status is_none_of <the project's done-category keys>, and workflowsService.getTerminalStatusKeysByProjects resolves that per project across many projects in one query — built for exactly the cross-project question Home is the first surface to ask. Neither was cited by any card in the story.
Every gate in the checklist that could have caught it is aimed at something else. Gate 2 verifies preconditions exist — they did; the reads are new, so there was no stale claim to catch. Gate 3 (CARDINALITY) asks how many of a thing the product will own, not which of them a list contains. Gate 12's journey audit asks whether each action in the verification recipe has an owning card — every one did. Nothing in the checklist reads an acceptance criterion of the form "lists every X where P" and asks which axes P names, and which it does not.
notes.html #212 (2026-08-04, eb9ca19) is the same axis: "Specified an action affordance by when it APPEARS and never by when it is ABSENT." Its lesson (a) names the three recurring axes explicitly — permission, lifecycle, terminal — and says "a criterion of the form 'X is present on both surfaces, for every kind' is a totality claim on ONE axis and reads as thoroughness while leaving the state axis unconsidered." That is this defect, stated seven days early. Its prompt hint even prescribes the exact remedy this fix needs: "Gate on the category (category = 'done'), never a hardcoded status key — projects define their own statuses."
It could not fire here because its trigger is lexically scoped to an ACTION AFFORDANCE — "When a card introduces a button, link, menu item, or any other affordance that starts an action". A card that specifies a read surface's membership introduces no affordance, so the lesson does not match, and it lives in the retrieved-lesson tier (notes.html / lessons.base.ts) rather than the always-injected rules — presence AND absence returns 0 hits across prompts/ on origin/main, so #212 was never promoted. The corpus knows the mechanism and has never turned it on a list.
Widen #212's trigger from an affordance that starts an action to any specification of a SET of items — a list, a count, a badge, a feed — or keep it a lesson? Evidence gathered at filing, for whoever closes it:
2026-08-04 10:40 -0700 (eb9ca19, notes.html only); MOTIR-2649 was created 2026-08-11 13:32Z. Seven days. Post-lesson recurrence on the axis: one.notes.html #212 in full before deciding, and check for a sibling record card already owning an amendment in the same region.notes.html #262 authored in this pass, cross-referencing #212.done and its subtasks shipped what they were asked for. Nothing is archived, re-scoped or re-parented.notes.html #262 is on origin/main, and the promote question above is answered on the card — with the widening filed as its own pair (plan-rules.md + the SHARED_PLANNING_RULES mirror) if the answer is SHARPEN. Nothing else gates it; there is no code to write and no PR carrying this card's id.
Resolution: open.