Motir

RECORD card — the correction is already applied by the 2026-08-07 re-plan of the story. No code ships from this card. It records what went wrong, so the corpus learns.

What happened

motir run MOTIR-2282 was dispatched against a story whose cards had been sealed on 2026-08-05/06. Its own design child MOTIR-2259 merged on 2026-08-07 as commit 1273ff32 — the tip of origin/main, i.e. the run's own branch base. That asset decided two things the cards had already decided differently, and not one card was amended. Every card still read ready: true with its design blocker done, which is exactly the state the design-allocation rule predicts.

The two contradictions, each read on origin/main at 1273ff32

1 · Structure — the cards described the layout the design says it REPLACED. MOTIR-2263 specified "the grid — one card per role, its permissions grouped by catalog domain" and made its first acceptance criterion "matching panel 1". design/projects/design-notes.md heads its structure section "The structure: a DRILL-DOWN, because a matrix capped the feature it exists to serve" and states "an earlier revision put permissions on ROWS and roles on COLUMNS. It read well at three roles and could not survive five, which is why it was replaced." Panel 1 is now the role LIST; a role's permission set is a second, nested DETAIL screen. Built to the card, the PR would have shipped the replaced structure — and MOTIR-2265's E2E would have asserted it, because its steps still described one screen.

2 · Premise — the story's shipping gate was unsatisfiable inside the story, and aimed at a question the design had closed. The story's criterion read "PLANNED_PERMISSIONS is empty — asserted by a test in this story." On origin/main, lib/permissions/catalog.ts holds 8 planned keys, and the array's own doc-comment says emptying it "takes BOTH MOTIR-2256 … and MOTIR-2291 … neither story empties it alone." MOTIR-2291 is todo, and the story's only link to it was relates_to — which carries no readiness semantics, so the story sat ready on a gate no work inside it could ever satisfy. Meanwhile the design had made the gate moot in the other direction: "a settings page describes the product, not its migration", so the screens draw the model as it will be.

3 · The design's own ratification dependency was recorded in prose and in no edge. The notes say "this asset draws MOTIR-2347's recommendation as settled, and that card has not run … it is a ratification these screens depend on." No edge existed anywhere. ROLE_GATED_PERMISSIONS holds 20 keys today; the design draws 28, with Admin 28 · Member 10 · Viewer 2 — the extra eight are decided by MOTIR-2347 and enter the role sets in MOTIR-2349. So the screens could not have been built as drawn, and the plan had no way to say so.

4 · The data seam the screens need did not exist and no card owned it. toPermissionDomainDTOs() returns all 31 catalog keys with no role-gated arm; RoleDTO carries no member count and projectMembershipRepository has no grouped-by-role read; nothing carries the M in the list row's N of M. Three values on the drawn screen with no producer.

Why no existing check caught it

The design-allocation rule (notes.html #214) puts the sweep on the DESIGNER: "grep the asset you just wrote for every MOTIR-<n> it names, and for each one state whether the design GIVES that card an element or TAKES one away." The asset names MOTIR-2263, MOTIR-2291, MOTIR-2347, MOTIR-2349, MOTIR-2294 and MOTIR-2257 — it TOOK the structure from 2263 and the premise from 2282 — and amended none. The run-time half of the same rule is what caught it: "at the design gate a done design blocker is a source of truth about SCOPE, not only about layout."

Note the aggravating shape, and it is the interesting one: the design was RIGHT every time. Every contradiction resolves in the design's favour on rung 2. The defect is not a bad decision, it is a good decision that reached the asset and never reached the cards — which is why nothing looked wrong from any single card.

Fix applied / Resolution taken

• Created MOTIR-2439 — the widened getRoleCatalog read (role-gated row set, per-role member count, the N of M total), blocked_by the design.
• Re-scoped MOTIR-2263 to the drill-down: list + detail, the nested route, an honest answer to the nav-totality test; 3→5 pts, 45→65 min; blocked_by 2439; re-titled off "the read-only grid".
• Re-scoped the story: struck the PLANNED_PERMISSIONS gate ON THE RECORD with its evidence, replaced it with a contract the page can be held to (rows = ROLE_GATED_PERMISSIONS, marks = BUILTIN_ROLE_PERMISSIONS[role], asserted against the constants), corrected 32→31/28, re-titled off "the grid", wired blocked_by MOTIR-2291 (the story-level lift of the cross-parent 2347/2349 need), status → blocked.
• Swept the test siblings: MOTIR-2265 re-scoped to the list → drill-down → return flow with a seeded member-count assertion (50→60 min); MOTIR-2264 re-pointed off the done model story's surface onto this story's, plus a role-gated row-set guard, blocked_by 2439.
• Nothing archived — all four original children survived as re-scopes, and no done node was touched.

Acceptance criteria

• The lesson is recorded in motir-meta/notes.html with the rung-2 evidence above, and this card cites it by CONTENT rather than by a number that a later collision can renumber.
• The correction above is verifiable in the tenant: 2439 exists and is blocked_by 2259; 2263 is blocked and blocked_by 2439; the story is blocked and blocked_by 2291.
• The promote question is SETTLED on evidence and written down: does this widen the design-allocation sweep (notes.html #214) — whose discharge is stated only for the design's own run — to cover the case where the design merges AFTER its consuming cards, or does it stay a lesson? Record the verdict and the grounds; do not leave it as a conditional.

Context refs

• design/projects/design-notes.md, the Roles & permissions section — the structure decision, the 28-row table, and the MOTIR-2347 ratification paragraph.
• lib/permissions/catalog.ts — PLANNED_PERMISSIONS and its two-story comment; lib/permissions/builtinRoles.ts — ROLE_GATED_PERMISSIONS.
• lib/mappers/permissionMappers.ts, lib/dto/permissions.ts — the unfiltered domain grouping and the count-less RoleDTO.
• The design that landed after the cards · the story re-planned · the new read.