Motir

A RECORD card — the correction is already applied. No code, no PR of its own; its lesson rides on MOTIR-2700's notes.html entry.

The mistake

On 2026-08-11 MOTIR-2664 closed with two children unwritten: it had a child in a second repository, that PR merged first, and countOtherOpenByWorkItem could not count a PR nobody had opened. Every mechanism behaved correctly.

From that I concluded the structure was illegitimate — that a story must never span repositories — and filed three cards to spread the prohibition: MOTIR-2700 (the motir-meta rule), MOTIR-2703 (the SHARED_PLANNING_RULES mirror) and MOTIR-2704 (a CLI refusal). All three were internally coherent, correctly one-repo-per-card, and pointed the wrong way. The right conclusion was the other one: the product could not represent a shape the plan legitimately needed. Settled 2026-08-12 by MOTIR-2725.

Why the wrong conclusion was attractive

When a correct mechanism produces a wrong outcome there are exactly two available conclusions — a capability is missing or the input was illegitimate — and the second is always cheaper to believe. A prohibition costs a paragraph; supporting the shape costs a schema, a completion gate, two surfaces, a CLI and a planner. Cheapness reads as parsimony. It is not evidence.

Two tells that were available and missed

1. The corpus already contradicted the rule I was adding. plan-rules/kind-story.md says "A Story spanning two repos gets one gate card per repo" — a sentence that cannot be parsed under a one-repo-per-story rule. And core.md's cardinality standing instance says a project's repository split comes from its ARCHITECTURE, "never from a default of one". A new rule that contradicts the corpus it is joining is a symptom, not a sharpening — and the check is free: grep the packs for the noun before writing the rule about it.
2. The prohibition was being written on the strength of ONE incident. CORPUS-MAINTENANCE.md's default is LESSON, and promotion needs recurrence. Two prior instances existed (MOTIR-1627/MOTIR-1941, and MOTIR-1958) — but they had all shipped cleanly, which is evidence the shape works, not evidence it recurs as a defect. I counted them as violations because the rule I had already decided on made them look like violations.

Fix applied / Resolution taken

• MOTIR-2700 re-planned into the reversed rule (a STORY may span repositories; ONE SUBTASK = ONE REPO = ONE PR untouched), bug → subtask, moved from MOTIR-1465 to MOTIR-2725, blocked_by MOTIR-2726.
• MOTIR-2703 and MOTIR-2704 archived with forward-pointer comments; their surviving obligations folded into MOTIR-2732 and MOTIR-2731, which had both already flagged the conflict as their blocking question.
• MOTIR-2725, MOTIR-2731 and MOTIR-2732 swept: the "premise contested, do not expand" paragraphs replaced with the settled answer.
• The auto-memory one-story-one-repo rewritten to the reversed rule.

Close-out

Verify in the tenant that the four cards above read as described and that MOTIR-2703 / MOTIR-2704 are archived, then confirm MOTIR-2700's notes.html entry is on origin/main — locate it by content, not by number — and close. If that entry does not yet exist, this card rests at In Review until MOTIR-2700's PR merges.

Lesson-vs-rule

Default LESSON — one incident, and the draft needs the incident to make sense. Both tells above are already covered by existing rules (the cardinality standing instance; the RULES-vs-LESSONS promotion bar); nothing here is a missing rule, only a missing performance of two that exist. Do not promote without a second occurrence.