Motir

Filed 2026-08-18 by the motir run MOTIR-2967 that executed MOTIR-2967, per run.md's planner-bug-home rule. The correction is already applied — to MOTIR-2967's descriptionMd (an amendment note plus a struck-through table, not a comment) and to the shipped comment block in tests/planningRulePacks.test.ts (PR moooon-B-V/motir-ai#243). Nothing here is scheduled work; this is the telemetry.

What happened

MOTIR-2967's whole subject is a coverage ratio: how much of SHARED_PLANNING_RULES the 57 toContain literals in tests/treeGeneration.test.ts actually pin. It set the result in a six-row table:

Five of six reproduce. The sixth is the denominator, and 143 079 is not a wrong reading of the constant — it is a correct reading of a different object:

SHARED_PLANNING_RULES.length                                    = 125 476
readFileSync('src/llm/planningRulePacks.ts', 'utf8').length     = 143 079   ← the card's figure
statSync('src/llm/planningRulePacks.ts').size                   = 145 363

The numerator was measured by parsing a test file; the denominator was measured by wc-ing the source file that declares the constant — so ~17 600 characters of TypeScript scaffolding (identifiers, backticks, the CORPUS_ORDER table, the selector functions) were counted as planner corpus.

The base is not in question. src/llm/planningRulePacks.ts last changed at b763dd8 (2026-08-17T20:27Z), before both the card (2026-08-18T01:22Z) and origin/main HEAD 034b22a (2026-08-17T22:17Z). git log b763dd8..034b22a -- src/llm/planningRulePacks.ts is empty, so the file is byte-identical to what the reporter read and "it was corrected in between" is excluded.

Why it survived

Because every input to the number was individually available and only their pairing was wrong, and a ratio does not announce that its two halves came from different objects. 143 079 is a real, current, reproducible measurement of a real file with the right name. Nothing about it reads as an error until somebody asks which thing it measures.

This is the same shape as notes.html #299 — "a bug card explained a MEASURED number by reading what had landed NEAR it, and set the result in a table" — one rung lower down. There the two commits were confusable; here the two objects are, and the confusable pair is the constant vs the file that declares the constant. The card also happens to be about a check whose entire failure mode is a measurement that reads as a verdict, which is where a wrong denominator costs the most.

The lesson

A ratio owes the PROVENANCE of both halves, not just of the interesting one. When a criterion turns on a percentage, the denominator is a measurement with a subject, and naming the subject (the exported constant, not the module) is what makes it checkable. A denominator sourced by wc -c on a file, against a numerator sourced by parsing that file's contents, is two different subjects wearing one ratio.

The mechanical form, cheap enough to run every time: derive both halves through the same interface. SHARED_PLANNING_RULES.length and the parsed literal count are both readings of the module's exports; wc -c is a reading of the disk. MOTIR-2967's PR pins this as an assertion — expect(BASELINE.length).toBe(SHARED_PLANNING_RULES.length) — so the distinction is now load-bearing in the repo rather than only in a lesson.

Acceptance criteria

1. notes.html carries the lesson as a .mistake entry (done as part of the MOTIR-2967 run; see the close-out comment on that card for the entry number).
2. No further build work. This card exists as the planner's record that the denominator of a coverage claim went unverified while its numerator was measured carefully.