Filed by the MOTIR-2725 re-plan, which archived MOTIR-2412 and rebuilt its five subtasks around a repository SET.
plan-rules/core.md's gate 3 asks, of every THING a card says the product will own or resolve for a user, "how many can there be, and what decides that?" — and it carries an explicit standing instance:
The specific standing instance — repositories: a project's repo COUNT and SPLIT come from its ARCHITECTURE, never from a default of one.
MOTIR-2412 was a story whose entire subject was the repository field, and it planned it as the pin — singular, throughout: "pinned to a NAME", "three states", "the field". Five subtasks were authored on that model. The rule fired on nothing, on the card it was written for.
Why the existing gate did not catch it, and this is the interesting part: gate 3 is stated as a question about a thing the card says the product will CREATE or RESOLVE. This card's subject was a field that already existed as a scalar column, so the count was not being decided — it was being INHERITED from prisma/schema.prisma. Reading the shipped schema (rung 2, which the card did diligently, and its notes are unusually good) returns one, and rung 2 is normally the authority that ends the question. A cardinality inherited from shipped code reads as a verified fact rather than as an assumption, which is exactly the reading gate 3 has no defence against.
That is a candidate sharpening rather than a re-wording: when a card's SUBJECT is an existing field, gate 3 asks whether the SHIPPED cardinality is still right — not what it is. Whether that earns a rule change or stays a lesson is for the corpus maintainer to decide (plan-rules/CORPUS-MAINTENANCE.md's RULES-vs-LESSONS split); the safe default is a notes.html lesson.
MOTIR-2412 had five subtasks: two design, two code, one story gate (MOTIR-2417, a vitest gate). plan-rules/kind-story.md's canonical composition makes both story-level test subtasks mandatory — an integration vitest and a Playwright E2E — and adds the acceptance video for a story with a user-observable surface. This story had a user-observable surface on two pages and neither the E2E nor the video. The re-plan filed MOTIR-2730 to close it.
This is a plain miss against a written, unambiguous rule, so it needs no sharpening — only the lesson entry, and a note that "the story gate" reading as the test card is the shape that hides it.
MOTIR-2415 cited app/(authed)/issues/[key] as the detail page. There is no issues route segment on origin/main — it is app/(authed)/items/[key]/. This is the claim-vs-pointer gate in miniature: a file:path in Context refs is what a VERIFIED precondition looks like, so a remembered one inherits that credibility. Corrected in the re-plan.
motir-meta/notes.html carries a numbered entry for defect 1 — the cardinality rule missing its own standing instance because the count was inherited from shipped code rather than decided — with the rung-2 evidence and the lesson, matching the existing .mistake markup and bumping the count.plan-rules/ or left as a lesson, and why — per plan-rules/CORPUS-MAINTENANCE.md's RULES-vs-LESSONS split. Grep plan-rules/core.md's gate 3 before asserting the sharpening is absent; if a form of it is already written, the entry records that instead.motir-meta — never a direct commit to main.motir-meta/prompts/plan-rules/core.md — gate 3 (cardinality) and its repositories standing instance.motir-meta/prompts/plan-rules/kind-story.md — the canonical story composition and its two mandatory test subtasks.motir-meta/prompts/plan-rules/phase-deepen.md — the claim-vs-pointer gate (defect 3).motir-meta/prompts/plan-rules/CORPUS-MAINTENANCE.md — RULES vs LESSONS.motir-meta/notes.html — the target.