The blocked-issue sweep only checks issues that already carry the label, so 5 declared blockers are invisible to it

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

blocked-label-blocker-line.sh enumerates its population with

search/issues?q=org:${ORG}+is:issue+state:open+label:blocked+archived:false

so it can only ever check issues that already carry the label. It answers "does a
blocked-labelled issue have a conforming line?" and reports that as "all N open
blocked-labelled issue(s) carry a conforming **Blocker:** line" — which is true, and is not the
question a run needs answered. The question a run needs answered is "is this issue blocked?", and
the check is structurally blind to every issue that is blocked without carrying the label.

Measured 2026-09-01 over all 771 in-scope open issues, reading bodies directly rather than
through the label filter. The org-wide search returns 802; the 31-issue difference is
data-product (27 — archived, which AGENTS.md requires omitting from every census) plus
fleet-gitops (3) and maintenance (1), neither of which is in the Portfolio map. A per-repo REST
enumeration over the Portfolio map's repositories independently returns 772, agreeing within one
issue of the filtered search — the two enumerations differ in method, so their agreement is a real
control rather than the same query run twice. None of the five findings below is in an excluded
repository, so the correction moves the denominator and not the finding:

Class	Count	Visible to the sweep?
blocked label and a conforming line	32	yes — reports 32/32 CONFORMS
A real **Blocker:** line, no label	5	no
**Blocker:** none — agent-actionable, no label	2	n/a — correctly unlabelled
Blocked in fact, neither label nor line	≥2 known	no, and not mechanically detectable

The five: ksail#5150, platform#3251, platform#3252, platform#3253, platform#3381. Each names a real
blocker — homebrew/cask notability policy, a Cloudflare account action, two chained on those, and
a maintainer decision on a third-party upstream contribution.

The two Blocker: none cases (actions#1025, actions#1028) are the reason this needs the body read
rather than a bare "line without label" match: they declare no blocker and are correctly
unlabelled. A naive check would report 7 and be wrong about 2 of them.

Who this affects and what it costs

Every run, in every lane, and the cost compounds because the two failure directions are both bad:

• Unlabelled but blocked — the issue reads as ordinary actionable work. AGENTS.md's skip test
  keys clause (b) on a named, live-verified dependency, so a run must re-derive the blocker from the
  body or from live state before it can pass over the issue. With three lanes on an hourly cadence
  that is the same derivation repeatedly, for issues whose status has not changed in weeks.
• The reported number is reassuring and incomplete. 32/32 CONFORMS is what a run sees, and it
  reads as the blocked set is in good order when 5 members of that set were never examined.

This is the Epic's pattern exactly: a measurement counting something other than what it claims to,
in the direction that corrupts a decision.

Two live cases found while working the Security queue today

Both were at the top of rung 2, both cost a full derivation, and neither was detectable by the sweep:

• platform#3255 — every acceptance criterion had been met by #3264 twelve days earlier, which
  closed its duplicate #3258 and left this one open. Verified and closed today.
• platform#3263 — substantively delivered by #3267 (which used Part of, not Fixes), with its
  three remaining criteria blocked on #3269. It carried neither label nor line. Repaired today,
  which is what moved the sweep from 31 to 32.

Expected behaviour

The check answers "is this issue's blocked-ness recorded consistently?", in both directions — a
label without a conforming line (today's finding), and a declared blocker without the label.

Acceptance criteria

• The check enumerates open issues independently of the blocked label, and reports a
  declared blocker carrying no label as its own finding class, distinct from MISSING/MALFORMED.
• **Blocker:** none is not reported — the two actions cases above are the fixture, and a
  RED ablation proves the check would otherwise flag them.
• The wider enumeration keeps the existing UNKNOWN discipline: a failed or truncated read exits
  2, never a clean report. An empty result stays a claim about the query.
• The five listed issues are labelled, each after its blocker is re-verified — a stale line
  whose dependency has shipped must be unblocked, not labelled. Adding the label to an issue
  that is no longer blocked is the more expensive error, since a label never expires.
• The existing 32/32 behaviour is unchanged for issues that already carry both.

Not in scope

The "neither label nor line" class (platform#3196, platform#3223) cannot be detected from issue
content — nothing distinguishes it from an ordinary open issue. It is named here so the residue is
recorded rather than implied to be covered.

Rough size: small — one enumeration change plus a finding class, against a script that already
has the body-parsing, soft-wrap joining and UNKNOWN handling this needs.

[devantler]

🤖 Generated by the Agentic Engineer

Correction to the denominator, made before anyone acts on this. I first wrote 802 open
issues. That is the raw org-wide search count and it is not the in-scope population: it includes 27
issues from data-product, which is archived — AGENTS.md requires omitting archived
repositories from every census — plus fleet-gitops (3) and maintenance (1), neither of which is
in the Portfolio map.

The in-scope figure is 771. Body updated.

Found by running a second enumeration that varies the method rather than the filter: a per-repo
REST walk over the Portfolio map returned 772, and reconciling the 30-issue gap against the
search set is what surfaced the three out-of-scope repositories. The one remaining issue of
difference is a read race between the two passes.

The finding is unchanged. All five gap issues — ksail#5150, platform#3251, platform#3252,
platform#3253, platform#3381 — are in in-scope repositories, so only the denominator moved. The
acceptance criteria stand as written.

[devantler]

🤖 Generated by the Agentic Engineer

Fresh measurement 2026-09-01, and it cost this run three selections

This issue records that the sweep enumerates label:blocked only. Measured again today, org-wide,
the gap splits into two sub-classes that fail differently — and the second is the expensive one.

A. Conforming blocker line, no blocked label — 7 issues

open issues                                   803
  with `blocked` label                         34
  candidates (body mentions "Blocker", no label) 46
  → of those, a CONFORMING `**Blocker:**` line   7

Issue
platform#3251 #3252 #3253	the wedding-backup R2 chain
platform#3381	vendored gitops-skill review routing
actions#1025 #1028	credential-boundary / input-gate guards
ksail#5150	official homebrew cask publication

These are documented correctly and are simply invisible to a label:blocked enumeration, so
blocked-label-blocker-line.sh reports a clean sweep over them.

B. Genuinely blocked, neither line nor label — the costly one

Class A at least renders its blocker to a human reading the issue. Class B renders nothing, so
oldest-first selects it, and the run discovers the blocker only after doing the investigation. Three
hit this run, all while walking the Security rung oldest-first:

• platform#3223 — selected as the oldest actionable Security issue and claimed before the
  block surfaced. It is blocked on #3480, a fact stated only in a manifest comment
  (pod-security-mutations-unscoped.yaml), plus a native blocked-by dependency that renders a badge
  on the board but is not what either the sweep or the skip test reads. Repaired this run.
• platform#3261 — carried the prose Blocked by #3260, and #3260 is CLOSED. A reader
  checking that reference concludes it is unblocked; the live blocker is actually #3274. This is the
  "blocker citing a closed issue reads as UNBLOCKED" trap, and prose is what let it rot. Repaired.
• platform#3196 — the parent epic, unlabelled, whose every remaining child is blocked. Repaired.

What the measurement suggests about the fix

The two sub-classes want different remedies, and only the first is a change to the existing script:

1. Widen the enumeration past label:blocked — a conforming line without the label is already
   machine-detectable, as the query above shows, so class A is closeable now.
2. Read the native blocked-by dependency, which is structured, unambiguous, and was already
   present on #3223 while every text surface was silent. This is the highest-signal input available
   and nothing currently consumes it.
3. Treat a blocker naming a CLOSED issue as a finding, not as a pass. #3261 shows a stale
   reference is worse than a missing one: it actively argues the wrong way.

⚠️ Repairing class A is not mechanical, and the labels should not be bulk-applied. Adding
blocked to an issue whose dependency has already shipped makes the skip look more legitimate on
every future tick — the failure this issue's own sweep exists to catch. Each of the 7 needs its
blocker re-verified live first, exactly as the three above were.

[devantler]

🤖 Generated by the Agentic Engineer

Correction to the comment above — the count is 4, not 7, and the difference is the design lesson

I read the presence of a conforming **Blocker:** line as meaning blocked. Reading the values
shows three of the seven are correctly unlabelled:

Issue	Blocker value	Verdict
actions#1025	**Blocker:** none — agent-actionable	not blocked — label correctly absent
actions#1028	**Blocker:** none — agent-actionable	not blocked — label correctly absent
ksail#5150	homebrew/cask notability policy … premise needs re-framing, **not a wait**	not a wait — needs re-scoping, not a label
platform#3251	maintainer authority (Cloudflare account action)	blocked
platform#3252	#3251 — re-read live, still OPEN	blocked
platform#3253	#3252 — re-read live, still OPEN	blocked
platform#3381	maintainer decision, third-party upstream contribution	blocked

So 4 need the label, and I have applied it to those 4 only.

This is worth more than the arithmetic. A widened enumeration must parse the blocker line's value,
not its presence — **Blocker:** none is a conforming line asserting the opposite of blocked, and a
presence-based check would have labelled two agent-actionable issues as blocked. That is strictly worse
than the gap this issue reports: an unlabelled blocked issue wastes one selection, whereas a wrongly
labelled actionable one is skipped by every lane, every tick, with a conforming line making the skip
look justified. It is the same asymmetry the "verify before repairing" warning already draws, reached
from the other direction — and I walked into it in the previous comment, which is the evidence that a
presence check is the natural thing to build.

Sequencing side-finding: actions#1025 and #1028 both say "Land after actions#1022, which
introduces the file". actions#1022 is MERGED, so both are now unblocked and their stated
precondition is satisfied — they are ready to pick up, not merely unlabelled.