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-3220

Planning bug: a card's own detection query prescribed `gh pr view --json files`, which caps at 100 — and the cap became a finding in the card's evidence table

Done
Description

Found by motir run MOTIR-3215 on 2026-08-20, while executing the card this defect is in.

⚠️ THE notes.html HALF IS ALREADY DONE — motir-meta PR #283, entry #344, opened 2026-08-20 by the run that found this. The corpus rule is that a run logs its lesson before it reports, so the entry did not wait for this card. What remains is the second criterion only: the plan-rules decision. The description below is unchanged so the reasoning stays readable; the acceptance criteria at the foot record what is discharged.

What happened

MOTIR-3215 was authored by motir run MOTIR-3213. Its Finding 1 carries two evidence tables: four confirmed stray design results, and one over-publish — MOTIR-3122 / PR #2161, reported as "100 design files in the PR, 138 assets published".

The four strays re-measured exactly. The over-publish did not exist.

The card's own Detection query section prescribes the instrument that produced it:

gh api /repos/{owner}/{repo}/actions/runs/{id} → head_branch → gh pr view --json files

gh pr view --json files caps its file list at 100 entries, silently — no warning, no truncation marker, no non-zero exit. So for any pull request with more than 100 files it reports exactly 100, and a comparison against an asset count reads as an over-publish of precisely assets − 100. The reported "100 design files" is the cap.

Reproduction (2026-08-20, on origin/main, against the live repository)

$ gh api --paginate "/repos/moooon-B-V/motir-core/pulls/2161/files" --jq '.[].filename' | wc -l
140
$ gh api --paginate "/repos/moooon-B-V/motir-core/pulls/2161/files" --jq '.[].filename' | grep -c '^design/'
138
$ gh pr view 2161 --repo moooon-B-V/motir-core --json files --jq '.files[].path' | grep -c '^design/'
100

138 design files against 138 published assets. PR #2161 published exactly what it authored.

Why this is a PLANNING bug and not a product one

The fix changes the PLAN and the procedure, not any shipped behaviour. upload-design-assets.mjs never used gh pr view; nothing in lib/ or app/ does. What used it was a card's evidence-gathering method, written into that card as a reproducible recipe for whoever picked it up — so the wrong number would have been re-derived identically by the next reader, which is exactly what a documented detection query is for.

The near-miss is the point: acting on that row would have withdrawn a legitimate design result from MOTIR-3122 — 138 real assets for a card that really did author them — turning a card that was correctly designed into one that reads as never designed. The reverse of the harm MOTIR-3215 exists to repair.

The general shape

A gh convenience view is a CAPPED read; the REST endpoint behind it is the measurement. This is the same family already logged for gh run list hiding earlier attempts and gh pr checks having no --json: the porcelain answers a question adjacent to the one asked, and its answer looks like a number rather than like a page. A count taken from one of them is a claim about the first page, and nothing marks it as such.

The corollary for card authoring: when a criterion or an evidence table states a COUNT, name the command that produced it, and prefer the paginated API over the porcelain. A count with no command beside it cannot be re-measured; a count from a capped command cannot be trusted even when it can.

What was already done during the run

  • motir-meta PR #283 — notes.html entry #344, with the reproduction, the near-miss, and the prompt-engineering hint. Cross-cutting count bumped 343 → 344.
  • MOTIR-3215's over-publish table is struck through, not deleted, with the falsifying commands inline, and its Detection query now prescribes gh api --paginate.
  • The exclusion is stated in prisma/migrations/20260820140100_withdraw_stray_design_results/migration.sql and asserted by name in its test, so a future reader can see MOTIR-3122 was excluded on measurement rather than overlooked.
  • scripts/detect-stray-design-results.mjs (PR #2210) implements the detection with paginated counting and a header saying why.

Acceptance criteria

  • motir-meta/notes.html carries a mistake entry for the class, with the reproduction and the prompt-hint. DISCHARGED 2026-08-20 by motir-meta PR #283 (entry #344). Left visible rather than deleted so the pairing of lesson and card stays legible: the corpus holds the LESSON, this home holds the CARD, and neither substitutes for the other.
  • The takeaway is checked against plan-rules/phase-deepen.md's NEGATIVE limb, which already requires a card explaining something by absence to carry the grep rather than the verdict. If this is the same rule applied to a COUNT, it is sharpened there rather than duplicated; if it is genuinely a second situation, it is written where the packs' MANIFEST.md routes it. One of the two, decided and stated — not both. Entry #344 poses this question and deliberately does not answer it; answering it is this card's remaining work.
  • No change to any repository's runtime code: this is corpus work. The one shipped consumer of the corrected method (scripts/detect-stray-design-results.mjs) already landed with MOTIR-3215.