Settled by Yue, 2026-08-17. There is NO special treatment for the planner-bug home. The general rule changes instead — for every parent in every project — and the home stops closing itself as a consequence, with nothing about it named anywhere in the code.
Implementing card: MOTIR-2888 (story, motir-core, six subtasks, ADR amendment first).
Upward derivation stops being a forward-only ratchet and becomes a RECOMPUTE: a parent's status is a function of its children's current statuses, applied whether that is forward or backward.
| # | Children's aggregate | Parent |
|---|---|---|
| 1 | every child is in a done-category status | done |
| 2 | ≥ 1 child in in_review, and every not-finished child is in in_review | in_review |
| 3 | ≥ 1 child in an in_progress-category status | in_progress |
| 4 | NEW — none of the above (≥ 1 child in a todo-category status, none started) | todo |
| — | no children at all | no derivation |
And the recompute must fire when the child set changes, not only when a child transitions — a created child, a re-parented child, an archived or deleted child. Adding a todo child to a done parent fires nothing at all today, which is why the home closed itself and stayed closed.
permanentContainer flag honoured by rollup — a schema field, a UI affordance and an admin story, to describe something the recompute makes moot.done, i.e. "no planning bugs", and leaves a manual revert owed after every sweep.All three answer "this one container should not close itself". The recompute answers the question actually underneath it — a parent's status should tell the truth about its children — and MOTIR-1465 needs no mention in the fix.
The ratchet is already producing incoherent state, not merely unhelpful state. MOTIR-1464 is done today while its own child MOTIR-1465 sits at todo: a finished parent with unfinished work under it. That answers this card's fourth acceptance criterion the same way — 1464 gets no exemption either; it recomputes with everything else.
During motir run MOTIR-1465 (2026-08-16/17), the rollup moved the home on its own:
| when | transition | trigger |
|---|---|---|
| 2026-08-16 | todo → in_progress → in_review | children moved to In Progress as the sweep ran |
| 2026-08-17 | → done | the last open children closed (34 done / 1 in review) |
Both were reverted by hand. done is terminal and user-visible, and a planner-bug home reading done says "no planning bugs" — the opposite of what the story exists to record. It recurs on every sweep that clears the backlog, which is what a working quality loop looks like.
origin/main at decision timeFiling works whatever the home's status. Re-checked at origin/main 1aa3e725 (2026-08-17), the whole chain reads no status:
lib/ai/plannerBugHome.ts — the marker resolves by TITLE, project-wide (MOTIR-2201); no status is read anywhere in the file.lib/services/aiWorkItemsService.ts:48 — on the marker it calls workItemsService.getWorkItemByProjectKindAndTitle(project.id, 'story', PLANNER_BUG_HOME_STORY_TITLE, ctx).lib/repositories/workItemRepository.ts:1533 — that query is where: { projectId, kind, title, archivedAt: null }. No status predicate.So a done home still receives auto-filed bugs: this was a legibility defect throughout, never an outage. (Had the resolver gained a status filter, the priority would have changed — it has not.)
The rollup is correct generic behaviour — all children done ⇒ parent done. What was wrong was the ratchet: a derivation that can only ever climb cannot describe a tree that grows new work. MOTIR-2756's discriminator, filed in this same story, applies exactly: when a correct mechanism produces a wrong outcome the two available conclusions are a capability is missing or the input is illegitimate, and the second is always cheaper to believe. The cheap read here was "the home shouldn't be a story" — it should. The missing capability is the downward half of the ladder.
The decision is recorded and MOTIR-2888 is filed with its repo pinned, which discharges every acceptance criterion this card carried. It rests at In Review until MOTIR-2888 lands, and is deliberately not closed: closing it would re-trigger the very defect it describes (all of MOTIR-1465's children done ⇒ the home closes itself again), and the fix is not shipped yet.
docs/decisions/status-derivation.md §3 (the ladder) and §5 (Forward-only) are what MOTIR-2888 amends.notes.html entry number. That gap was about the parent→child direction; this one is about the child→parent direction's polarity — the same mechanism's third missing half.notes.html #275 — the same shape one tier down: a container whose child's job is to FILE CARDS can never finish its own PR.