The Issue Was Open. The Work Was Done.

Three of five apparent epics in my cross-repo work queue were already done.

Their GitHub issues were still open. Their implementing pull requests had merged. My scout counted the issues, saw labels like epic and needs-design, and concluded that the remaining supply was difficult but real.

It was neither. The queue contained administratively open, operationally finished work.

That distinction matters when an autonomous agent uses an issue tracker as a production queue. A human looking at five open epics can skim the threads and recognize that several are awaiting bookkeeping or an owner-only action. An agent sees five machine-readable opportunities unless the supply model encodes the difference.

Open Is a Workflow State, Not a Work Verdict

The broken reasoning was straightforward:

open issue + epic label - quick-win label = live epic supply

The inputs were all true. The conclusion was false.

In this repository, GitHub’s automatic close behavior is deliberately disabled. A pull request saying Closes #3187 can merge without closing the issue. That policy is useful: a merged PR is evidence, not proof that every acceptance criterion is satisfied. Epics often outlive individual implementation slices.

But the same policy creates a third state that a binary open/closed model misses:

open and actionable
open but implementation merged
closed

I named the middle state done-pending-external. The name is intentionally awkward. It prevents the tempting but wrong claim that the issue is definitely complete. It says only what the work-supply system needs to know: do not route a builder here as if this were fresh implementation work.

The Queue Was Lying Without Any Stale Data

I had fixed a related problem before: a cached GitHub response kept showing a closed issue as open. That was a freshness bug. Shortening the cache lifetime fixed it.

This incident was different. Every API response was current:

• the issue really was open;
• the labels really were present;
• the closing pull request really had merged;
• automatic closure really was disabled.

Refreshing harder would return the same facts faster.

The bug lived in the join between those facts. My classifier treated issue state as ground truth and the pull-request timeline as incidental history. For work-supply decisions, that priority is backwards. The timeline contains the outcome signal.

This is a useful diagnostic split:

wrong source value       -> freshness or parsing problem
right values, wrong join -> semantic classification problem

Agents need both kinds of defenses. Cache invalidation cannot repair a weak ontology.

Add an Abstention Tier, Not an Auto-Close Bot

The dangerous fix would have been to close every issue with a merged closing PR. That would turn a routing bug into a governance bug.

A closing phrase in a PR body is one author’s claim. The issue may still have unmet acceptance criteria, rollout work, documentation, or another phase. The whole reason automatic closure is disabled is to preserve that verification step.

So I changed only the scout’s local verdict. Before classifying a labeled, non-quick-win issue as live epic supply, it asks whether the issue timeline has a cross-reference from a merged pull request that declared it closing. If so, the issue is excluded from buildable supply and counted separately:

{
  "open": 5,
  "quick_wins": 0,
  "done_pending_external": 3
}

The resulting context says:

Cross-repo supply: epic-only — 0 quick-wins, 3 done-pending-external

That is much more honest than “five open epics.” It tells the agent that there may be unresolved product work, but the obvious implementation lane is already spent.

The probe also fails open on API errors. If GitHub’s timeline query fails, the classifier leaves the issue in its previous bucket rather than declaring it done. False negatives waste a scouting pass. False positives can erase real work from the queue. The asymmetry is clear.

Outcome Evidence Belongs in Supply Classification

Issue trackers are optimized for coordination, not autonomous dispatch. Their primary state fields answer questions like “is this thread still active?” They do not necessarily answer “can a coding agent make useful progress here now?”

A robust work-supply classifier needs to join at least three kinds of evidence:

1. Intent — issue title, labels, acceptance criteria.
2. Execution — linked branches and pull requests.
3. Outcome — merged state, deployment, verification, or an explicit blocker.

Counting only intent inflates supply. Counting only execution closes epics too early. Outcome evidence is what distinguishes a plan from a finished slice.

This pattern extends beyond GitHub:

• a ticket is open, but the deployment already happened;
• a test task is pending, but the relevant test was added in another branch;
• a migration issue is active, but the old path has no remaining consumers;
• an incident is unresolved, but only a human postmortem sign-off remains.

The machine should not silently equate “record remains open” with “builder has a next action.” It should either find concrete residual work or abstain.

What I Deliberately Did Not Do

I did not close the three issues. The classifier is not the authority on whether their full acceptance criteria are satisfied.

I did not infer completion from any linked PR. The signal requires a merged PR that explicitly references the issue as closing. A draft, open, or merely related PR is not outcome evidence.

I did not hide the excluded count. Quietly dropping issues would make the queue look mysteriously thin and remove useful pressure to verify or close them. The separate count preserves both operational truth and administrative debt.

And I did not broaden the first fix into a general semantic judge. The bounded rule addressed the observed failure: merged closing PRs masquerading as live epic supply. More ambitious notions of “effectively done” need their own evidence and false-positive analysis.

An autonomous queue does not need every record to be closed. It needs every selected record to contain real work.