scripts/check-copilot-instructions.sh reads each checkout's working-tree file and reports a size, but never says which version of the file that was. A repo whose default branch has been under cap for weeks still reports OVER CAP if any local checkout is parked on an older branch, and nothing in the output distinguishes that from a genuinely over-cap repo.
This is not hypothetical — it sent #77 chasing a phantom. That issue carried houseofjawn-dashboard: 5170 (+1170) as one of three repos to trim. Measured today:
origin/main is 3630, comfortably under cap — the trim already landed.- The 5170 comes from a local checkout sitting on
remove-docker-status-command, a branch with no open PR whose copy of the file predates main's trim.
So a third of that issue's scope was a stale checkout, and the guard's FAIL line actively supported the wrong conclusion.
It is the same false-alarm family #90 just fixed from the other direction. #90 corrected how many rows (nine ccm checkouts folding into one repo). This is which ref each row is about.
Suggested fix
Report the ref alongside the size, and make the default-branch state visible:
- Print the branch (or short SHA) each measured file came from, so a row reading
remove-docker-status-command is self-evidently not a statement about main.
- When a checkout is not on the repo's default branch, either also measure the default branch's committed copy (
git show <default>:.github/copilot-instructions.md | wc -c) or mark the row as off-default so the summary is not read as a verdict on the repo.
- Consider making the folded-group representative prefer a default-branch checkout when the group has one, rather than only the largest file. The largest-file rule exists so a stale small sibling cannot hide a truncating one; it currently also lets a stale large sibling invent one.
Worth a test per case, in the style of the existing fixture tests: a repo whose default branch is under cap but which has an over-cap checkout on a feature branch should not be reported as an over-cap repo without qualification.
Follows #59, #76, #90. Found while closing out #77.
Receipt token: wake-20260724T1905-0e4ce1
scripts/check-copilot-instructions.shreads each checkout's working-tree file and reports a size, but never says which version of the file that was. A repo whose default branch has been under cap for weeks still reportsOVER CAPif any local checkout is parked on an older branch, and nothing in the output distinguishes that from a genuinely over-cap repo.This is not hypothetical — it sent #77 chasing a phantom. That issue carried
houseofjawn-dashboard: 5170 (+1170)as one of three repos to trim. Measured today:origin/mainis 3630, comfortably under cap — the trim already landed.remove-docker-status-command, a branch with no open PR whose copy of the file predates main's trim.So a third of that issue's scope was a stale checkout, and the guard's
FAILline actively supported the wrong conclusion.It is the same false-alarm family #90 just fixed from the other direction. #90 corrected how many rows (nine ccm checkouts folding into one repo). This is which ref each row is about.
Suggested fix
Report the ref alongside the size, and make the default-branch state visible:
remove-docker-status-commandis self-evidently not a statement aboutmain.git show <default>:.github/copilot-instructions.md | wc -c) or mark the row as off-default so the summary is not read as a verdict on the repo.Worth a test per case, in the style of the existing fixture tests: a repo whose default branch is under cap but which has an over-cap checkout on a feature branch should not be reported as an over-cap repo without qualification.
Follows #59, #76, #90. Found while closing out #77.
Receipt token: wake-20260724T1905-0e4ce1