Motir

Found by · motir run MOTIR-4165, 2026-09-03. The correction is already applied — MOTIR-4165's description carries an amendment banner and the fixed numbers. This card is the telemetry, and it holds nothing up.

Neither error changed the fix or any acceptance criterion. MOTIR-4165 shipped as authored. Both are recorded because they are the same failure shape twice, and the second one nearly cost the card its whole point.

---

1. The COUNT was wrong when the card was written — 39, against 56

MOTIR-4165 said "carrying 39 authored summary lines" and "the file has thirty-nine." Measured at the card's own ref, the one it names as verified:

$ git show 8d80ac8db:lib/apiDocs/mcp.ts | grep -c 'descriptionFingerprint:'
56

So this is not drift between filing and claiming — it was false at the moment of writing, against the commit the card itself cites.

Where the 39 came from, and why that is the interesting part. It is in the file, in a doc comment the card had open:

"The first pass here derived them by parsing the registerTool(...) literals … and nine of thirty-nine came out wrong"

That is MOTIR-2325's number, correct as history and stale as a census. The card read a count out of prose instead of counting the map — which is exactly the failure the file's own docs/mcp.md guard was written to prevent: "the natural move for anyone adding a tool is to INCREMENT the number they read rather than count the registry, which propagates the error instead of fixing it." The card was about a deleted counting guard, and it inherited the defect that guard existed to stop.

2. A four-tool SAMPLE was reported as a census

The card's evidence table measures four plan tools and concludes "That is one day, one tool; the file has thirty-nine." The four were the neighbourhood the discovering run (MOTIR-4146) happened to be standing in — a sample selected by where the author was, not by the claim.

The restored gate's first whole-map run found two drifted pins:

add_plan_items:      stored ae3fc99f33f6, shipped d75174c32f83   (MOTIR-4153 / #2519)
submit_plan_session: stored 2191f35e198e, shipped da07e05ffb16   (MOTIR-4172 / #2526)

Two merged pull requests went green under the missing gate, not one. AC 4 is the only reason this surfaced — "Every OTHER stored fingerprint is verified rather than assumed" — and it is the criterion a runner is most tempted to discharge by asserting the sample. Had the card been built to its narrative rather than to that criterion, the gate would have shipped, submit_plan_session would have stayed silently mis-pinned, and the next divergence would have read as the first.

The takeaway

Both halves are one shape: a number in a defect card is a claim about a population, and the command that produced it belongs beside it. Neither error is caught by re-reading the card carefully — they are caught only by re-running the enumeration with the CLAIM's predicate. The card's ref was correct, its method was correct, its control was well designed, and its scope was wrong in a direction no re-reading reveals.

Fix — already applied, nothing outstanding

• MOTIR-4165's description carries an ⚠️ AMENDED ON THE RECORD banner naming both errors with the commands that produced the corrected numbers.
• Its evidence table is now labelled FOUR TOOLS OF FIFTY-SIX with the second divergence named.
• Fix-direction item 4's "39 hand-authored summaries" reads 56.
• The lesson A card's PROSPECTIVE half is disciplined by nothing — check its counted set and its named test home was reinforced against this occurrence; it already covers the shape and needed no widening.

No code change is owed by this card. It is closable on read.