ready_issues / blocked_issues resolve blockers only via depends_on_issue_id, so external refs never block (measured on 1.2.2; believed already fixed by #4753 — filing to confirm)

Read this first — we believe this is ALREADY FIXED on main

We are filing this knowing it appears resolved, for confirmation and to track our own upgrade. It is not a claim about current upstream.

• Issue #4769, "external dependencies are stored but ignored by ready, single dep list, and show", was closed by PR #4753, "fix: enforce external capability blockers", merged 2026-09-02.
• Our Homebrew beads 1.2.2 bottle was published 2026-08-15 — we measured a binary cut 18 days before that fix landed.

If #4753 covers what is described below, please close this as already fixed. The measurement is accurate for 1.2.2 and stale for main. We are filing it rather than withholding it at the explicit direction of the reporting operator; the maintainer cost of closing it should be near zero.

Companion to #6556 and to our #5272-adjacent report.

What we measured on 1.2.2

The help text promises external refs "block the issue until the capability is shipped". The view SQL cannot deliver that. From information_schema.views, ready_issues (and blocked_issues identically) resolves blockers solely through depends_on_issue_id:

AND EXISTS (
  SELECT 1 FROM issues blocker
  WHERE blocker.id = d.depends_on_issue_id
    AND blocker.status NOT IN ('closed','pinned')
    ...
)

depends_on_external appears nowhere in either definition. A row with depends_on_issue_id = NULL fails the EXISTS test, contributes 0 to blocked_by_count, and the issue is never blocked.

Measured end to end: after a cross-scope dep add, fac-q5b remained on bd ready.

Why we cared

This is a fail-open. The operator who typed the command walks away believing a gate exists, and the work stays dispatchable. We use these edges to serialize changes that corrupt each other if run concurrently, so a gate that silently is not a gate is the worst available failure mode — which is why we measured it, and why we would rather confirm the fix than assume it.