Motir

Found in · the run of MOTIR-3949, 2026-08-30 · Repos · motir-meta (primary) + motir-ai — a standing planning RULE has two homes.

What happened

MOTIR-3949 is a model citizen of the ENUMERATION limb. Its body names the ref it measured at (origin/main 2fc5d6016), states the population ("40 hits in en.json, 15 in zh.json"), and — going one better than the rule asks — publishes the exact python3 walk that produced them, under the heading "The reproduction is the walk itself".

Running that walk, unmodified, at the card's own named ref returns 39 and 14.

$ git show 2fc5d6016:messages/en.json > /tmp/en.json   # the card's own ref
$ python3 -c "…the card's walk, verbatim…"             # matching 'card', case-insensitive
39
$ …the same walk over zh.json, matching 卡片…
14
$ # and at origin/main 0068da2f4, unchanged: 39 / 14
$ git diff 2fc5d6016..origin/main -- messages/en.json messages/zh.json | grep -iE '^[+-].*(card|卡片)'
(no output — one commit touched the catalogs, and it moved no card-bearing line)

So the number was wrong when it was written, not drifted since — the --diff-filter direction (run.md's reproduce-at-the-reporter's-base, step 3) is settled by that empty grep, not assumed.

Why this is a PLANNING bug and not a typo

The harm is small here — off by one in each catalog, no member of the enumerated SET missing, no scope change; the fix shipped unaffected and the card is amended on the record. The mechanism is not small.

1. The existing rule was FOLLOWED and did not catch it. plan-rules/phase-deepen.md's ENUMERATION limb asks a counting card for the REF its count was taken on, so the reader can re-measure. This card supplied the ref and the command. The limb secures checkability; it says nothing about correctness, and the two are being conflated at the point of authoring.
2. The published command makes it WORSE, not better. A bare number invites "is that right?". A number with its command beside it reads as a transcript — as if the figure were pasted out of the terminal — so the reader's suspicion drops exactly where it should not. Every downstream reader of this card, including its own run, believed 40/15 until the command was actually executed.
3. It is unfalsifiable by review. No gate runs a card's own commands. validate_work_item returned valid: true with a clean advisory array; readiness read ready: true; the sizing gate saw nothing. The only reader who can catch it is the run that executes the card, and only if the corpus tells that run to re-run the number rather than to re-derive the ref.

The fix — a rule change, in both homes

The ENUMERATION limb currently secures the REF. It should also secure the ACT:

A card that publishes the command that produced its number must have RUN that command and pasted its output. A command a card quotes is a claim about a transcript, and it is read as one. If the command was reconstructed after the fact, or adapted from another card, say so and give the number without it — an unadorned figure is honestly weaker and reads that way, which is the point.

And the run-time half, in run.md's A bug card's FIRST deliverable is the REPRODUCTION, which already sends a run to re-measure a count on a ref:

Where the card publishes a COMMAND, run THAT command first, before any re-derivation of your own. A number that disagrees with the card's own published command is the strongest form of a falsified count and needs no interpretation — and it is the one case where re-measuring is one paste rather than a reconstruction.

Acceptance criteria

1. motir-meta/prompts/plan-rules/phase-deepen.md's ENUMERATION limb gains the ran-it-or-say-you-didn't clause, ADDED beside the existing ref requirement rather than re-wording it.
2. SHARED_PLANNING_RULES in motir-ai/src/llm/planningRulePacks.ts carries the same clause, so the shipped planner authors under it too — a rule in one home only teaches one of the two planners.
3. motir-meta/prompts/run.md's reproduce-at-the-reporter's-base rule gains the run-the-card's-own-command step, cited from this card.
4. Whatever guard the motir-ai rule corpus already runs over SHARED_PLANNING_RULES (the rule-corpus mirror suites) is green, and the pull request says which suite it ran.
5. ORDERING — every criterion reads on this card's own two branches and on each repo's origin/main. Nothing reads on MOTIR-3949's branch: that pull request ships product copy in motir-core and touches neither repo named here.
6. TWO pull requests, one per repository, both linked to this card — the completion gate holds it until both merge.

Context refs

• MOTIR-3949 — the card whose count this is about; amended on the record, scope unchanged.
• motir-meta/prompts/plan-rules/phase-deepen.md — the ENUMERATION limb (and its NEGATIVE twin).
• motir-meta/prompts/run.md — A bug card's FIRST deliverable is the REPRODUCTION, steps 2–4.
• motir-ai/src/llm/planningRulePacks.ts — SHARED_PLANNING_RULES, the shipped mirror.

Resolution: open.