Census: stale merged remote branch counts as in_flight — wedges advance and re-triggers stall/escalation

[robercano-ghbot]

What

loop-census.sh's in-flight check matches git branch -a --list "*feat/issue-N-*" — including REMOTE-TRACKING refs. After a PR merges, the remote branch (and the local remote-tracking ref) survives unless explicitly deleted, so a still-open issue with a merged partial PR is forever in_flight: advance_ready stays none, stall detection fires on it, and (until #154 lands) the no-op resume attempts burn straight to a needs-human re-escalation.

Observed (2026-07-17→18, issue #96)

PR #153 (part 1 of #96) merged at 07:52Z; local branch + worktree were cleaned up correctly, but origin/feat/issue-96-ci-fix remained. Census reported in_flight=96 / stalled=96 (age 1350min) all night, advance_ready=none (loop wedged with 1 planned issue), resume attempts 2/2 no-oped (#154), #96 re-labeled needs-human. Manual recovery: delete remote branch + git fetch --prune + clear resume state + remove label.

Fix sketch (either/both)

• merge-ready.sh: after a successful merge, delete the remote branch (bot-gh api DELETE git/refs/heads/) and prune local remote-tracking refs — mirrors GitHub's auto-delete-branch-on-merge behavior.
• loop-census.sh: when the matched branch is remote-only, treat it as in_flight ONLY if no MERGED PR exists for it (bot-gh pr list --state merged --head ); otherwise ignore.

Related: #154 (resume dispatch no-op) turned this from a wedge into a false escalation.

🤖 Generated with Claude Code

[robercano-ghbot]

Issue #158's feat/issue-158-* branch has stalled and already been resumed 2 times without landing a PR. The loop will not retry it automatically -- labeling needs-human. Address it by hand, then either close it out or clear its entry in .claude/state/loop-resume-attempts.json to let the loop resume.