MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2707

Planning bug: a card's acceptance number was inherited from an automated projection whose detector counts the rule's own heading as removable evidence

Done
Description

Filed by the motir run MOTIR-2660 that hit it. The correction is already applied — MOTIR-2660's AC 4 is amended on the record and the cap amendment is MOTIR-2706. This card is the telemetry.

What happened

MOTIR-2660's AC 4 said "reports core.md at or under 520 lines". 520 came from COMPRESSION.md § Decision 3, which took it from COMPRESSION.measure.py's projection of 501. The run compressed honestly to 598 and could go no further without cutting triggers, tell-lists or the index — which the same card's AC 3 forbids.

The defect in the plan

A number produced by a script was written into a card's acceptance criteria as a target, without anyone asking what the script actually measures. COMPRESSION.measure.py classifies a span as warrant if it matches a regex for citation markers. That is a reasonable proxy for sizing the problem and a wrong one for setting a floor, because a rule's TRIGGER routinely cites the incident it came from:

  • Of the 22 marker-bearing sentences left in core.md outside the evidence tags, none survives § Decision 1's deletion test as warrant — 9 are rule headings, 6 are tells, 7 are directives with a pointer.
  • The projection also counts the evidence tags a compression inserts, so it drifts upward as warrant is removed: 501 → 542 → 546.

The record knew. § Decision 1 names exactly this material — "Both cite incidents; neither is warrant. An editor optimising for length removes exactly these first." — three paragraphs above the projection it then set the cap from. The measurement and the caveat sat in one document and were never read against each other.

The generalisable shape

A METRIC IS A CLAIM ABOUT WHAT IT COUNTS. When a card's acceptance criterion is a number a tool prints, the gate is not "is the number right?" but "does the tool's definition equal the card's definition?" — read the classifier, not the output. The tell is a card whose AC quotes a projected figure from a sibling decision record without restating the definition behind it. Here the two definitions differed by a factor of three, and the difference was one regex.

Two rules in the corpus already point at this from other angles and neither reaches it: gate 2's precondition-verification treats a cited number as a pointer to verify, not as a definition to open; and the claim-vs-pointer limb asks whether a line POINTS at a file or EXPLAINS it, which a printed metric passes cleanly while still being wrong.

Acceptance criteria

  1. A notes.html mistake entry is added for the shape above, in the existing .mistake markup with the count bumped: what was assumed (the projection measures warrant), the rung-2 evidence it was false (the 22-sentence enumeration and the self-reference), and the lesson.
  2. The entry names MOTIR-2660 as the run and MOTIR-2706 as the amendment, and states the discriminator: a projection sizes a problem; it does not set a floor.
  3. Whether the shape is a LESSON only, or has recurred often enough to earn a standing RULE, is decided against plan-rules/CORPUS-MAINTENANCE.md's RULES-vs-LESSONS contract and the answer is recorded in the entry. Default: LESSON.
  4. No plan-rules/ pack is edited by this card — if the answer to 3 is a rule, it is filed as its own card with the two homes named.

Context refs

  • prompts/plan-rules/COMPRESSION.md — § Decision 1 (the deletion test, and the paragraph that names the hazard), § Decision 3 (the cap), § Decision 4 ("the target gives way, not the rule").
  • prompts/plan-rules/COMPRESSION.measure.pyMARKER, and the proj line that builds the projection.
  • prompts/plan-rules/CORPUS-MAINTENANCE.md — RULES vs LESSONS.