Loop: dependency-aware issue selection — census must consult the blocking graph it already parses

[robercano]

Context (from the orchestrator landscape comparison)

The blocking-edge parser already exists — cockpit.sh --parse-blocking extracts Blocked by #N / Blocks #N / task-list edges from issue bodies and the cockpit renders the graph — but the loop's selector ignores it: loop-census.sh picks the lowest-numbered planned + module:* issue with no branch. So the loop will happily start an issue whose declared blocker is still open, producing either wasted work or a PR that lands out of order.

The comparison makes this look like a category error. Beads (Steve Yegge's agent-native issue tracker, 25k stars — more adopted than Gas Town itself) is built on exactly this: typed dependencies (blocks, parent-child, discovered-from) and a topological bd ready query that surfaces only unblocked work — "the agent's what-next question" (Beads, write-up). We don't need a new substrate (GitHub Issues as the source of truth is a deliberate reCode choice that Looper's ADRs independently validate) — we need the selector to respect the graph we already have.

Proposal

1. In the census ADVANCE step, for each candidate issue, run its body through the existing --parse-blocking seam; skip candidates with any OPEN blockedBy issue, and emit them as blocked=N by=M lines so the tick/cockpit can show why they were passed over.
2. Keep exactly ONE parser implementation (the --parse-blocking seam exists precisely for this — shell out, don't reimplement).
3. Document the convention in USAGE.md's backlog-hygiene section: "Blocked by #N" in the body is now load-bearing for the loop, not just cosmetic for the cockpit.
4. (Optional extension, could be split off) discovered-from hygiene: agents already file follow-up issues to backlog; add a convention that mid-task discoveries include "Discovered from #N" so provenance is queryable — Beads' discovered-from edge is its most-praised feature for preventing scope creep AND lost findings.

Acceptance criteria

• An issue with an open blocker is never selected for ADVANCE; the skip and its reason appear in census output and events.
• When the blocker closes, the blocked issue becomes eligible with no human action.
• Cycle in the graph (A blocks B blocks A) doesn't wedge the loop — log and fall back to lowest-number.
• Covered in loop-census.test.sh with fixtures.

Decision points for you

• Should parent-child (task-list - [ ] #N) edges also gate selection, or only explicit Blocked by? (Recommend: only Blocked by — task lists on tracking issues are already handled by keeping trackers in backlog.)

🤖 Generated with Claude Code

https://claude.ai/code/session_014Gu82LWNkdzhrDFSQ7EZmB

[robercano]

only explicit Blocked by will gate selection

[robercano-ghbot]

This issue has ping-ponged through 5 advance/feedback dispatches for issue #97 without landing (budget.per_issue_attempts=5). 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-issue-attempts.json to let the loop resume.