Filed unassigned by the domain:ui seat, recording only — not graded, no domain:*, no type. Surfaced by the dev on objectui#6522 (PR #6543) while running the gates before staging; it is not that card's face, so it is filed rather than folded.
What was measured
Both gates enumerate tracked files. Run before git add, a brand-new file is outside their population and they print green without having opened it.
The dev caught it because the gates report their own counts, and the counts moved after staging:
check:control-bytes scanned 5397 -> 5399 tracked text file(s)
check:vi-mock-specifiers 3835 -> 3836 tracked source file(s), 455 -> 456 carry a mock
The first run's green was true of the population it scanned and said nothing at all about the new file. Only the delta in the gate's own count proves the file was seen on the second run.
Why this is worth a card rather than a habit
This is the failure mode the lane keeps filing: an instrument that cannot see the thing you are asking it about, returning a pass. Here it is worse than usual in one respect — the natural workflow invites it. A dev writes a new test file, runs the repo's gates to check their work, gets green, and stages afterwards. The gates were never wrong; they were answering a different question than the one being asked.
The blast radius is any newly-added file in any PR whose author runs these gates locally before staging. CI is unaffected — it operates on a committed tree, where every file is tracked. So the defect is invisible from CI and only bites the local pre-flight, which is exactly where a dev is trying to avoid a red push.
Suggested handling (for whoever grades this)
Not fixed here, and the right shape is a judgement call:
- Make the population explicit in the output. These gates already print their counts; the cheap fix is for them to say tracked out loud, so a green reads as "green over N tracked files" rather than "green".
- Or widen the population to include untracked, non-ignored files. That changes what the gate means and could surprise someone with scratch files in their worktree, which is why it is a decision rather than a patch.
- Or refuse to run cleanly when the worktree has untracked, non-ignored files matching the gate's own glob — loudest, and possibly too loud.
The first option is the one that cannot make anything worse.
Whether other scripts/ gates share the enumeration is not measured here — this was found on two of them and the population question likely applies more widely. A census across scripts/ is the natural first step for whoever takes it.
Refs: objectui#6522 · PR #6543 (where the counts were observed).
Filed unassigned by the
domain:uiseat, recording only — not graded, nodomain:*, no type. Surfaced by the dev on objectui#6522 (PR #6543) while running the gates before staging; it is not that card's face, so it is filed rather than folded.What was measured
Both gates enumerate tracked files. Run before
git add, a brand-new file is outside their population and they print green without having opened it.The dev caught it because the gates report their own counts, and the counts moved after staging:
The first run's green was true of the population it scanned and said nothing at all about the new file. Only the delta in the gate's own count proves the file was seen on the second run.
Why this is worth a card rather than a habit
This is the failure mode the lane keeps filing: an instrument that cannot see the thing you are asking it about, returning a pass. Here it is worse than usual in one respect — the natural workflow invites it. A dev writes a new test file, runs the repo's gates to check their work, gets green, and stages afterwards. The gates were never wrong; they were answering a different question than the one being asked.
The blast radius is any newly-added file in any PR whose author runs these gates locally before staging. CI is unaffected — it operates on a committed tree, where every file is tracked. So the defect is invisible from CI and only bites the local pre-flight, which is exactly where a dev is trying to avoid a red push.
Suggested handling (for whoever grades this)
Not fixed here, and the right shape is a judgement call:
The first option is the one that cannot make anything worse.
Whether other
scripts/gates share the enumeration is not measured here — this was found on two of them and the population question likely applies more widely. A census acrossscripts/is the natural first step for whoever takes it.Refs: objectui#6522 · PR #6543 (where the counts were observed).