What happened
Issue #94 is labeled both planned and needs-human (escalated 2026-07-20T21:27 via the resume-stall mechanism — .claude/state/loop-resume-attempts.json shows "94": {"count":2,"escalated":true}). Its own escalation comment says the loop will not retry it automatically until a human clears that entry.
Despite this, the 2026-07-21T08:48:19Z tick emitted action=advance issue=94 and the ADVANCE driver would have spawned a fresh orchestrator run on it had it not manually checked GitHub state first (see comment on #94).
Root cause
loop-census.sh's advance_ready candidate loop (the eligible=1 check, around the branch="none" && open_prs==0 && !driver_unit_active condition) only:
- checks for an existing
feat/issue-$num-* branch (local or remote), and
- checks
open_prs/driver_unit_active.
It never checks the issue's own labels for needs-human. Two prior stalled attempts on #94 left local branches named work/issue-94-fix / work/issue-94-unicode-fix — a naming convention that doesn't match feat/issue-$num-* — so census sees branch=none for #94 and treats it as a fresh, eligible advance candidate, completely independent of the resume-escalation state tracked in loop-resume-attempts.json.
Suggested fix
In the planned candidate loop, skip (treat as ineligible, not just non-advance_ready) any issue whose labels include needs-human — mirroring the existing plan_state = "awaiting-owner" treatment a few lines below, which already sets eligible=0 for a comparable "blocked on a human" state. This closes the gap for both label directions (resume-stall escalation, attempt-budget escalation, and the plan-gate's reuse of the same label).
Why this matters
Without the fix, a needs-human-labeled issue can be re-selected by advance_ready as soon as its old branch name doesn't match the feat/issue-N-* pattern (e.g. legacy work/issue-N-* branches, or any branch an implementer named unconventionally), silently defeating the escalation safety net and risking a repeat of the exact stall/wedge cycle that triggered the original escalation.
🤖 Filed by the ADVANCE driver for issue #94, 2026-07-21.
What happened
Issue #94 is labeled both
plannedandneeds-human(escalated 2026-07-20T21:27 via the resume-stall mechanism —.claude/state/loop-resume-attempts.jsonshows"94": {"count":2,"escalated":true}). Its own escalation comment says the loop will not retry it automatically until a human clears that entry.Despite this, the 2026-07-21T08:48:19Z tick emitted
action=advance issue=94and the ADVANCE driver would have spawned a fresh orchestrator run on it had it not manually checked GitHub state first (see comment on #94).Root cause
loop-census.sh'sadvance_readycandidate loop (theeligible=1check, around thebranch="none" && open_prs==0 && !driver_unit_activecondition) only:feat/issue-$num-*branch (local or remote), andopen_prs/driver_unit_active.It never checks the issue's own labels for
needs-human. Two prior stalled attempts on #94 left local branches namedwork/issue-94-fix/work/issue-94-unicode-fix— a naming convention that doesn't matchfeat/issue-$num-*— so census seesbranch=nonefor #94 and treats it as a fresh, eligible advance candidate, completely independent of the resume-escalation state tracked inloop-resume-attempts.json.Suggested fix
In the
plannedcandidate loop, skip (treat as ineligible, not just non-advance_ready) any issue whose labels includeneeds-human— mirroring the existingplan_state = "awaiting-owner"treatment a few lines below, which already setseligible=0for a comparable "blocked on a human" state. This closes the gap for both label directions (resume-stall escalation, attempt-budget escalation, and the plan-gate's reuse of the same label).Why this matters
Without the fix, a
needs-human-labeled issue can be re-selected by advance_ready as soon as its old branch name doesn't match thefeat/issue-N-*pattern (e.g. legacywork/issue-N-*branches, or any branch an implementer named unconventionally), silently defeating the escalation safety net and risking a repeat of the exact stall/wedge cycle that triggered the original escalation.🤖 Filed by the ADVANCE driver for issue #94, 2026-07-21.