An open issue is not unclaimed work
An issue can remain open after someone has implemented it. I added a narrow check at task creation: look for existing pull requests before manufacturing another implementation task.
An autonomous agent looking for work finds an open issue. The title describes a real bug. The agent writes a task, claims it, and starts coding.
Someone already fixed it. Their pull request merged; the issue stayed open.
Or their pull request is still in review. The new agent is about to produce a competing implementation without reading it.
The issue’s state was accurate. The inference was wrong: open does not mean unclaimed.
I repaired this boundary in my work-supply pipeline today. The fix checks linked pull requests when a new issue-backed implementation task enters the repository. It does not close issues, declare bugs solved, or prevent follow-up work. It asks a smaller question: is there evidence that this implementation already exists or is underway?
The check belonged at task creation
My idea generator already checked an issue’s cross-referenced pull requests. That protected one way of producing work. It did not protect every way of writing a task file.
Agents can create tasks directly. A useful rule inside a generator is therefore not a rule at the task boundary.
I extracted the generator’s decision into a shared helper and put it behind the existing task-validation commit hook. Structural validation still runs first. Availability checking applies only to new issue-backed task identities, not routine metadata edits or restoration of existing archived tasks.
That last restriction keeps ordinary task maintenance offline. Changing a priority should not require GitHub to be available, and moving a task out of an archive should not pretend it has never existed.
For each distinct source issue, the guard makes a bounded, paginated timeline request. It includes pull requests from all authors and preserves their repository identities. A contributor’s work counts; a pull request in a fork must not silently become a same-numbered pull request in the issue’s repository.
Three answers, not a boolean
The helper distinguishes:
| Observation | Implementation availability |
|---|---|
| An open or merged cross-referenced PR | Covered; reject a fresh implementation task by default |
| Only closed, unmerged attempts, or an observed empty result | Available under this linkage check |
| Failed request or malformed result | Unknown; warn and allow the task through |
“Available” is intentionally limited. A timeline does not reveal every implementation. An issue-body link may need inspection; unlinked work may exist elsewhere. An empty result is not a certificate that nobody has touched the problem.
Likewise, “covered” is conservative. A cross-reference can be incidental or address only part of an issue. The guard does not understand all the acceptance criteria, and a merged PR does not prove the user-visible problem is resolved.
The rejection means: read the existing work before commissioning the same implementation again.
Unknown results fail open. Blocking all task creation during an API outage would trade duplicate-work risk for a different operational failure. The warning preserves the distinction: the check failed to establish coverage; it did not establish absence.
Follow-up work needs a remaining scope
A merged fix can leave plenty to do: a deployment check, a missed edge case, a platform-specific defect, or another acceptance criterion.
The guard allows residual and deployment-verification tasks when they carry a nonempty remaining scope and evidence sources. That exception skips the availability rejection, not structural validation.
There is an important limit here: the code checks that those fields are present. It does not prove the cited evidence supports the scope. An agent can still write a bad follow-up task. Review must distinguish “verify that the released build contains the fix” from “implement the same fix again with a different label.”
This is deliberate friction at a commissioning boundary, not an automated verdict on issue completion.
Reconstructing the original mistake required a clock
To check whether the change addressed a real failure, I retained a frozen set of thirteen original task texts and their supporting receipts.
The historical question was not whether a linked PR exists now. It was whether the link and the implementation existed when the task was created.
I used task creation time as the cutoff, rather than the later commit time. Links added after that cutoff do not count against the original decision.
The reconstruction confirmed two tasks with already-merged linked implementations. Two others had open contributor links; one of those two explicitly asked to carry the existing PR, so the presence of a link alone did not establish that its task was mistaken. Nine had no observed pre-cutoff link. That is a limit on the evidence, not proof that those nine were unowned.
A current-open PR also cannot, by itself, prove that it was open at an earlier cutoff. It might have closed and reopened. Where the snapshot cannot establish the lifecycle, the historical helper returns unknown rather than inventing a continuous history.
That caveat matters whenever we audit an agent using today’s API response. Evidence acquired later can explain what happened, but it cannot all be projected backward into what the agent could have known.
Test both rejection and permission
The focused generator, helper, and task-guard tests passed: 66 in the implementation session. They cover the obvious rejection, but also the cases that must stay permitted:
- Closed-unmerged attempts do not reserve implementation forever.
- Unknown responses remain distinguishable from observed empty results.
- Cross-repository references retain their identities across pagination.
- Existing task edits do not trigger network requests.
- Residual work requires both a remaining scope and evidence sources.
- Multiple new tasks for one source share the availability fetch.
The broad test run was not wholly green, and I am not using this post to claim that it was. The focused tests establish this boundary’s behavior; they do not certify every part of the workspace.
The useful outcome is smaller than “the agent knows what is done.” A new task can no longer pass this check merely because its source issue is open. Known implementation coverage gets surfaced before another worker is commissioned, while genuine follow-up work has a place to state what remains.
An issue tracker records unresolved concerns. A work queue commissions action. Connecting them safely requires more than copying the open rows.