MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2863

Planning bug: a document said "a separate surface with no card in this story" and no card was filed anywhere — while a downstream criterion read "the full suite passes"

Done
Description

Filed by the motir run MOTIR-2734 of 2026-08-15. The correction is already appliedMOTIR-2861 and MOTIR-2862 exist, MOTIR-2734 is blocked_by them and moved to Blocked. This card is telemetry, not scheduled work.

Defect A — a deferral written in prose, and filed nowhere

MOTIR-2796's closing section in docs/rls-runtime-role-inventory.md is titled "Out of scope, and still open: the WRITE surface" and reads:

Binding the reads does not bind the writes, and the flag-on suite still shows INSERTs refused by policy (new row violates row-level security policy for table "import" in tests/import…). Those are a separate surface with no card in this story.

There was no card in any other story either. Accurate, prominent, terminal — and invisible to every readiness computation, because those run over the tracker and this is prose in a document.

Defect B — the criterion that inherited it

MOTIR-2734's second acceptance criterion:

pnpm vitest run — with no environment variable set — passes on the full suite.

Making motir_app the default connection is exactly what puts the unbound write surface on every run, so this cannot hold until that surface is bound. No edge recorded it: MOTIR-2734.blockedBy held the twenty batches plus the two application-layer cards, all done, and readiness.ready was true.

The measurement

origin/main @ c99efdc7, PG 15, migrated DB, no environment variable:

759 failed / 13 695 passed / 1 skipped1 018 files, 118 red
does not exist lines4 — a clean run, not a trampled one
prior reading (on MOTIR-2796's branch, under the flag)1 146 failed / 13 390 passed

The twenty batches and the two binding stories moved it 1 146 → 759, not to zero.

And the residual is not only the write surface. 158 of the 759 are ten test files issuing db.$executeRawUnsafe('TRUNCATE …') on the @/lib/db singleton — 42501 permission denied for table, because TRUNCATE needs OWNERSHIP. That is the fixture-migration class the twenty batches existed to remove: the partition was cut over Prisma-model fixture calls, and raw SQL does not look like one. tests/helpers/db.ts states the rule correctly in its own header (import { adminDb as db }), so the pattern to copy was present the whole time.

The rules this argues for

  1. A deferral is a card at the moment the words are written. "Out of scope", "still open", "a separate surface", "no card"create_work_item before the document is committed, and cite the key in the sentence. plan-rules/core.md already says a deferral is a card; the addition is the TIMING, because the authoring pass is the only moment anyone knows the population exists.

  2. "The full suite passes" is not a scoped criterion. It is an unbounded claim on every population anyone has ever deferred: unsizable, unreviewable against the card's own diff, and it makes the card the involuntary owner of unassigned work. A card that flips a global default should name the DELTA it owns ("no failure attributable to the flag's removal") and take a blocked_by on a card owning "the suite is green". That the criterion had nowhere to point is the tell that it was inherited rather than authored.

  3. A card that flips a DEFAULT is downstream of every card that makes the new default survivable — whether or not it touches their files. The dependency-arrow audit compares deliverables and file sets; by that test MOTIR-2734 (eight test files) is independent of the write surface (lib/). It is not. Same family as MOTIR-2791: the arrow is owed to whatever makes the criterion TRUE, not to whatever produces the thing being edited.

  4. Do not partition a red suite before lifting its mask. Ten of the 118 red files die in beforeEach, so their remaining assertions never ran and count as nothing (notes.html #249). Hence the ordering MOTIR-2861MOTIR-2862 rather than one classification card today.

Logged as notes.html #271.