Impact
A run can pass every gate, file a correct pull request, and still be closed for
nothing, because the maintainer fixed the issue himself while our run was in
flight. No duplicate search can catch this: there is no competing pull request
to find, only a commit that did not exist when we checked.
Nothing screens for how likely that is. prescreen, screen-target,
check-target, duplicate-search and prior-art all ask whether the work is
already done or already claimed. None asks the cheaper question first: is this
the kind of fix a maintainer would just do in thirty seconds rather than
review a stranger's pull request for?
Evidence
pdm-project/pdm#3884 (run 20260907T173348Z-003915). One documentation line in
docs/reference/pep621.md plus a news fragment, closing issue #3877. Filed
2026-09-08T20:43Z, both checks green, no review, no comment. Frost Ming
closed it 2026-09-09T07:06:29Z after fixing #3877 directly on main in
dc4e314, which carries the same documentation change. No pull request
carried that commit.
Every gate was right at the time. The whole run was spent on a change small
enough that reviewing it cost the maintainer more than writing it.
Related but distinct: #75 (dead targets per live one) counts targets rejected
before a run starts. This one is about a target that is accepted, worked, filed
and then wasted.
Next action
Score the change, not just the issue, and make triviality a recorded screening
signal rather than a thing an agent notices or does not:
- Estimate the size of the fix at screening time from the issue itself: a
documentation typo, a one-line message change, a version-pin bump. Prescreen
records the estimate and its reason.
- Refuse, or demand an explicit acknowledgement, when a candidate is both
trivial to write and lives in a repository whose maintainer pushes directly
to the default branch. Read that second half from the target's recent
history, which target-intel already fetches: what fraction of commits on
the default branch arrived outside a pull request.
- Record the closure reason when a filed pull request dies this way, so
"maintainer fixed it directly" becomes countable rather than anecdotal. One
instance is a race. Three is a targeting rule.
The pull request standard already asks for a change worth a maintainer's
review. This makes the harness check it before the run is spent, not after.
Impact
A run can pass every gate, file a correct pull request, and still be closed for
nothing, because the maintainer fixed the issue himself while our run was in
flight. No duplicate search can catch this: there is no competing pull request
to find, only a commit that did not exist when we checked.
Nothing screens for how likely that is.
prescreen,screen-target,check-target,duplicate-searchandprior-artall ask whether the work isalready done or already claimed. None asks the cheaper question first: is this
the kind of fix a maintainer would just do in thirty seconds rather than
review a stranger's pull request for?
Evidence
pdm-project/pdm#3884 (run
20260907T173348Z-003915). One documentation line indocs/reference/pep621.mdplus a news fragment, closing issue #3877. Filed2026-09-08T20:43Z, both checks green, no review, no comment. Frost Mingclosed it
2026-09-09T07:06:29Zafter fixing #3877 directly onmainindc4e314, which carries the same documentation change. No pull requestcarried that commit.
Every gate was right at the time. The whole run was spent on a change small
enough that reviewing it cost the maintainer more than writing it.
Related but distinct: #75 (dead targets per live one) counts targets rejected
before a run starts. This one is about a target that is accepted, worked, filed
and then wasted.
Next action
Score the change, not just the issue, and make triviality a recorded screening
signal rather than a thing an agent notices or does not:
documentation typo, a one-line message change, a version-pin bump. Prescreen
records the estimate and its reason.
trivial to write and lives in a repository whose maintainer pushes directly
to the default branch. Read that second half from the target's recent
history, which
target-intelalready fetches: what fraction of commits onthe default branch arrived outside a pull request.
"maintainer fixed it directly" becomes countable rather than anecdotal. One
instance is a race. Three is a targeting rule.
The pull request standard already asks for a change worth a maintainer's
review. This makes the harness check it before the run is spent, not after.