labels-reconcile: the blind sweep on incubator survived the permissions fix — and the read swallows the reason

[dan-claude-bot]

Consumer-side report from heavy-duty/incubator, the family's only private consumer. Everything
below re-verified 2026-07-24 00:07–00:08Z.

#95 diagnosed incubator's permanently blank
state:* axis as the caller stub under-granting checks/statuses, and fixed the stub. The
consumer half landed as incubator#48 /
PR #49, merged 2026-07-23 23:42:39Z.
The symptom survived the fix, so the shared diagnosis was wrong — the stub really did
under-grant, but that is not what was blinding the sweep.

The falsification

Two post-merge runs, permissions visibly in effect in the runner, blind three seconds later:

##[group]GITHUB_TOKEN Permissions      ← 00:07:19Z
Checks: read
Contents: read
Issues: write
Metadata: read
PullRequests: write
Statuses: read
...
labels: #50: could not read mergeability/checks — left alone this pass    ← 00:07:24Z
labels: #46: could not read mergeability/checks — left alone this pass
labels: reconciled.

— incubator run 30055242702,
and identically in run 30055288837
(token block 00:08:10Z, both lines 00:08:15Z). Neither open PR has ever carried a state:* label.

Two things to look at, one of which blocks looking at the other

1. The read discards gh's error text.

GH_VIEW="$(gh pr view "$n" -R "$REPO" --json mergeable,statusCheckRollup 2>/dev/null || echo '{}')"

(L625 @ 5af1538, the current main;
L546 @ 0.1.0 — byte-identical between them.)

gh writes why it failed to stderr and 2>/dev/null drops it, so a permanent denial and a
network hiccup leave byte-identical evidence. The degrade itself is right and I am not arguing with
it — the PR must be left alone. But the reason it was left alone is knowable and is being thrown
away, and that is why #95 had to infer a cause from a control case instead of reading it off a run,
and why the inference could be wrong without anything looking wrong. #95's second half made a
wholly-blind sweep loud; it did not make it legible. One run with stderr captured (to the log,
or into the message) would have ended this in minutes rather than producing a merged fix for the
wrong defect.

2. The variable #95 and #48 both missed: the forks are private too.

Every PR on incubator is cross-repo — #50 from claude-bot-andresmgsl/incubator, #46 from
codex-bot-andresmgsl/incubator, likewise #34/#39/#40/#41/#47/#49 — and because the base repo is
private, every one of those forks is private as well. GITHUB_TOKEN is scoped to the base repo
and cannot read them.

The control case read as one difference and is actually two. box/rig/cast/ceremony are public, so
their forks are public, so a head-repo read costs nothing there. "Private repo ⇒ permissions not
implied" and "private repo ⇒ the head repo is unreadable at any permission" both fit the same
evidence, and #48 tested only the first. If it is the second, no caller-side permission can fix
it — the caller is not where a base-scoped token's reach is decided, and every consumer that goes
private will land here on adoption day.

Consistent-with, and its limit: the same query from a PAT that can read the fork returns both
fields for #50 (mergeable: "UNKNOWN" plus a full rollup), so the query shape is fine and the
fields exist. I cannot issue a GITHUB_TOKEN-scoped query from outside Actions to confirm the
denial — which is (1) again: the run already knows, and throws it away.

Why this is a discussion and not an issue

The fix has real latitude and I would be handing a builder my guess:

• If the head-repo read is the cause, the rollup has to come from the base repo — REST
  repos/{repo}/commits/{head_sha}/check-runs + /status reads PR head commits fine for fork PRs.
  But mergeable comes from the same call, and
  L618-L621 @ 5af1538
  documents a deliberate choice of gh pr view over the REST object because REST's mergeable
  is a lazily-computed tri-state boolean while gh returns the UI's string. Reversing that is a
  decision, not a patch — and it may mean two different sources for the two facts.
• It may not need reversing at all: if the cause is something else entirely, keeping gh and
  fixing the real thing is cheaper.
• Either way (1) is worth doing first and on its own merits, whatever (2) turns out to be. It
  is small, it is not blocked on knowing the answer, and it is what makes the answer readable —
  including for the next private consumer, who will otherwise repeat this exact round.

Suggested order: surface the error text, let one incubator sweep run, read the actual message, then
spec the fix against a fact instead of against my hypothesis. Happy to report that run back here.

cc @danmt — filed by triage, incubator-side trail on
incubator#48.

[dan-claude-bot]

Outcome: accept — #101 is minted for the half that had no open question.

Part (1) is now a work order: capture gh pr view's stderr, log it beside the counted degrade line, and stop blind_sweep_warning asserting a cause it never observed. Triage settled the four things that were latitude rather than design — the counted line stays byte-identical (grep -qxF at L639 drives the wholly-blind counter #96 just landed), the capture is a variable rather than an un-redirect, the reason is collapsed and bounded at 300 characters, and an empty stderr is reported as its own observation rather than as nothing. ready, unblocked, no dependency on knowing the answer to (2).

Part (2) stays open here, and this thread stays open with it. Nothing about the fork-visibility hypothesis has been minted, deliberately: "private repo ⇒ permissions not implied" and "private repo ⇒ the head repo is unreadable at any permission" still both fit the evidence, and #101 exists precisely so the next incubator sweep answers that off a run instead of off my inference. Minting a REST rewrite today would hand a builder the same guess that produced a merged fix for the wrong defect.

Sequence from here: #101 lands and releases → incubator's caller picks it up → one sweep → triage reports the actual stderr back into this thread → (2) converges on a fact.

@danmt — nothing needed from you on this one unless you disagree with the order.

[dan-claude-bot]

Status, not a new outcome — part (1) has landed and part (2)'s wait now has a
number.

#101 is closed (PR #106, merged 08:24Z). labels-reconcile now captures
gh pr view's stderr, logs the reason beside the counted degrade line, bounded
at 300 characters, and reports an empty stderr as its own observation rather
than as nothing.

Part (2) still waits on a fact, and the fact still has to come off an
incubator run. What changed is what stands between here and that run:
incubator executes ceremony's reconcile at its pinned ref, so the first sweep
that can print the reason is the first one after incubator bumps its pin. That
bump is now scheduled work — incubator#51, blocked on the 0.2.0 release (#118),
both children of the changelog.d epic (#112).

So the sequence in my accept comment above reads, concretely:

1. Release 0.2.0 — the first tag carrying fragment mode, and the first section the assembler wrote #118 ships 0.2.0 (behind lib/changelog.sh + bin/changelog-assemble — read the fragments, assemble one section, consume them #114 → actions/changelog-armed — fragment mode: the directory is the arming, and a bad entry fails on its own PR #115/actions/changelog-assembled — the release PR's section must be exactly the fragments it consumed #116 → ceremony adopts changelog.d — convert the Unreleased entries, delete the heading, rewrite the doctrine that describes it #117);
2. incubator#51 bumps the pin and re-syncs;
3. one scheduled sweep on incubator;
4. I paste the actual stderr into this thread;
5. (2) converges on what the run says instead of on my inference.

Nothing to do today, and nothing new is owed by anyone — the thread simply
stopped waiting on an unnamed release.

[dan-claude-bot]

The fact arrived, and it converges part (2). The five-step sequence above completed this evening, faster than the comment that wrote it expected:

1. ✅ 0.2.0 shipped (12:36Z), and 0.3.0 behind it (17:39Z);
2. ✅ incubator#51 closed — incubator#52 merged 18:36Z, pin at 0.3.0;
3. ✅ the 18:55Z scheduled sweep ran at the new pin;
4. the paste, verbatim from that run's log:

labels: #54: could not read mergeability/checks — left alone this pass
labels: #54: read failed: GraphQL: Resource not accessible by integration (repository.pullRequest.statusCheckRollup.nodes.0.commit.statusCheckRollup.contexts.nodes.0.checkSuite.workflowRun), Resource not accessible by integration (repository.pullRequest.statusCheckRollup.nodes.0.commit.statusCheckRollup.contexts.nodes.1.chec…
##[warning]labels: every open PR was unreadable; sampled reason: GraphQL: Resource not accessible by integration (…checkSuite.workflowRun), … — one candidate is missing checks: read and statuses: read in the caller (private repos do not imply them)

5. And the convergence, on what the run says rather than my earlier inference: the reason names the exact node — checkSuite.workflowRun — and it acquits both suspects the hint offers. Incubator's caller has carried checks: read and statuses: read since the permissions fix, the two scopes the sampled-reason hint (and CONSUMERS.md's private-repo paragraph) name. What reading a workflow run on a private repository needs is actions: read — a scope neither names. The blind sweep survived the permissions fix because the fix was complete against the documented contract and the contract was incomplete against GitHub; only a private consumer could ever show it, and incubator is the family's only one.

Minted from the paste: incubator#60 — actions: read in the caller (plus the unrelated triage-actors= regression that turned these runs red, and the 0.3.0 stub triggers). Its post-merge acceptance criterion is the confirming sweep: green end-to-end, zero degrade lines.

Deliberately not minted yet, on this repo: the hint text in labels-reconcile.sh and CONSUMERS.md's private-repo paragraph both name an incomplete scope set. One small docs/hint issue — once incubator's confirming sweep proves actions: read was the whole gap. If the degrade survives that merge instead, the diagnosis comes back here and the docs stay untouched. Minting the doc change tonight would write my hypothesis into the contract a few hours before the family's only private consumer tests it.

This thread has done what it exists for — part (1) shipped the reason-printing, part (2) got a reason precise enough to mint from on first read. I close it out when incubator#60's post-merge sweep lands, with the ceremony docs issue or the reopened read question, whichever the log says.

[dan-claude-bot]

Closing as resolved — the confirming sweep landed, the log said "fixed", and the ceremony issue it gated is minted.

The close-out condition from my 19:16Z comment is met:

• incubator#60 closed 20:20Z (PR incubator#62). The first post-merge labels run — 30123731319, 20:20:51Z at 90b527a — is green end-to-end with zero could not read mergeability/checks lines, and it wrote the state axis (labels: #61: state -> state:building), the exact checkSuite.workflowRun read that failed on every open PR before the merge. actions: read was the whole gap; the read question stays closed and no REST rewrite of the gh pr view read is needed.
• Minted from that fact: #173 — the hint text at blind_sweep_warning() and CONSUMERS.md's private-repo scope guidance catch up to the proven three-scope set (checks, statuses, actions), test and fragment included. ready.

The thread's full arc, for the record: part (1) shipped as #101 / PR #106 (the reason-printing that made part (2) answerable), part (2) converged on the run's own words rather than an inference, and the doc fix waited for the confirming sweep exactly so it would write a proven contract instead of a hypothesis. Nothing further is owed here.