Planning bug: a card's method clause was written in the semantics of an UNMERGED branch, and its criterion named a card archived 13 minutes after authoring

Filed by the motir run of MOTIR-2862 on 2026-08-15. Neither defect blocked the run or changed its deliverable; both are defects in the plan record, so they are filed here rather than against the story.

Defect 1 — the method clause described a world that exists only on an unmerged branch

MOTIR-2862 step 1 reads:

"Re-run pnpm vitest run with no environment variable, on main with MOTIR-2861 merged."

and its opening paragraph glosses that as "with no environment variable — i.e. with @/lib/db connected as the non-bypass role".

Those two clauses are not equivalent on main. tests/helpers/parallelDb.ts:133 still reads

return isAppRoleTestMode() ? withAppRoleCredentials(url) : url;

so with no environment variable set, @/lib/db connects as the bypass OWNER role — the opposite of what the card describes. The equivalence holds only on subtask/MOTIR-2734-retire-test-db-app-role, which deletes isAppRoleTestMode() and returns the app-role URL unconditionally. That is where the card's own 759-failure baseline was taken, and the branch semantics travelled into the card as if they were main's.

The card is internally contradictory as a result: run it literally on main, as it instructs, and you measure the bypass role and get a nearly green suite — the exact opposite of the card's purpose. The run resolved it from the title ("Re-measure the suite as motir_app") and used TEST_DB_APP_ROLE=1.

Defect 2 — an acceptance criterion named a card archived after authoring

AC 1 reads "gives the post-MOTIR-2860 totals". MOTIR-2860 was archived as a duplicate at 2026-08-15T21:52Z — thirteen minutes after MOTIR-2862 was created at 21:39Z. It is not a blocker of anything, MOTIR-2734's own 2026-08-15 amendment already owns the defect it described, and the card's real gate is MOTIR-2861 (the blocked_by edge it actually carries). A criterion phrased against an archived card cannot be checked as written.

Why this is a planning bug and not a card to build

The correction is already applied — the doc section and PR body for MOTIR-2862 record both readings with their evidence. Nothing in a repo changes. What is worth keeping is the shape, because it recurs in this exact chain: MOTIR-2859 is a criterion quoting a stale COUNT, and this is a criterion quoting stale ENVIRONMENT SEMANTICS and a stale KEY. Both come from authoring a card against work that is in flight.

The rule this suggests

A card that quotes a measurement must name the ref the measurement was taken on, and any instruction whose meaning depends on unmerged code must say so. MOTIR-2862's baseline is a number from a branch, restated as an instruction for main; one clause — "(this figure was measured on subtask/MOTIR-2734-…, where the flag is already retired; on main the equivalent is TEST_DB_APP_ROLE=1)" — would have removed the contradiction entirely. Same family as the precondition-verification rule, applied to the card's own METHOD rather than to its dependencies.

Acceptance criteria

• A notes.html mistake entry records both defects, with the parallelDb.ts:133 evidence and the archive timestamp, and its lesson is the rule above.
• The entry cross-references MOTIR-2859 as the sibling instance in the same chain.
• No card body is edited by this bug — MOTIR-2862's corrections already live in its PR and its doc section.