merge gate: mergeStateStatus stuck BLOCKED/UNKNOWN despite all checks SUCCESS, 0 threads, no approval requirement

[kyle-sexton]

lane: merge-drive
category: operational (blocks this lane's own merge readiness read on affected PRs, not a code defect)

observed vs expected: For two separate PRs this session, mergeStateStatus never settled to CLEAN/HAS_HOOKS even though every other signal says the PR is ready:

• docs(planning): reframe interview session-config framing #848: re-checked across 3+ cycles over ~2 hours (statusCheckRollup pulled fresh each time). mergeable=MERGEABLE, all 25 checks SUCCESS (confirmed via gh pr view --json statusCheckRollup, not just the cached merge-gate script output), reviewDecision="" with requiredApprovingReviews=0 (no approval needed), unresolvedThreadCount=0 after this lane resolved the last open thread, no do-not-merge label. mergeStateStatus flickered BLOCKED -> UNKNOWN -> BLOCKED across checks but never reached CLEAN.
• feat(repo-hygiene): fleet batch mode for the caches/build/git/all tiers #1064: same signature — all 25 checks SUCCESS, not a draft, empty reviewDecision — but mergeable/mergeStateStatus have both sat at UNKNOWN for 3 consecutive ~30min cycles (~1.5h) with no change.

Both PRs share the identical 25-check set (hygiene/review/security-review/do-not-merge/pr-issue-linkage/pr-title/zizmor/-sync/-gate/plugin-gate/miro-plugin/youtube-extraction/skill-quality-gate/portability-lint/Runner policy/ci-status/GitGuardian), all reporting SUCCESS in statusCheckRollup — this repo's specific check bundle may be relevant if it's a fan-out size or count GitHub's merge-state computation struggles with.

This is NOT #374's failure mode (that issue is a check that never settles, degrading to UNSTABLE) — here every check IS settled and green; it's mergeStateStatus itself that won't compute to an actionable state. An update-branch recompute nudge (tried once on #848 earlier this session) only produced a fresh unrelated merge commit without fixing the underlying stuck state.

Impact: this lane's merge gate correctly refuses to merge (fail-safe, working as designed) but can never prove readiness on affected PRs, so they sit indefinitely with nothing left to fix. Worth a human/GitHub-support-level look at whether this is a GitHub-side computation limit, a ruleset interaction (this repo uses rulesets, not classic branch protection — required_status_checks split across 2 separate rulesets, deletion/non_fast_forward/required_linear_history/pull_request/required_signatures also configured) or something else entirely.

Related: #374 (same symptom family — merge-state stuck — different, already-closed root cause).

[kyle-sexton]

This was generated by AI during triage.

Live re-check (2026-07-22)

The two PRs are not the same failure mode — re-checking each live disentangles them:

PR	Live state now	Was
#1064	MERGED (2026-07-22T21:30:14Z, squash, by the PR author) — resolved, gone	mergeable=UNKNOWN / mergeStateStatus=UNKNOWN
#848	Still OPEN, mergeable=MERGEABLE, mergeStateStatus=BLOCKED, mergeable_state=blocked	flickered BLOCKED/UNKNOWN, now settled firmly on BLOCKED

BLOCKED and UNKNOWN are different states: BLOCKED = mergeability is computed and a required rule blocks; UNKNOWN = mergeability is not yet computed (GitHub's async state). The report bundled them, but they have different root causes.

#848 — root cause found, and it is NOT a platform/compute limit

The block is a real, in-repo, fixable rule violation the merge-gate script structurally cannot see.

Elimination (all verified live):

• All 25 status checks SUCCESS (confirmed via statusCheckRollup).
• pull_request ruleset rule: required_approving_review_count=0, required_review_thread_resolution=true — and live review threads = 2 total, 0 unresolved. Satisfied.
• required_linear_history — squash merge (the only method this repo allows) produces linear history. Satisfied.
• The one rule left: required_signatures (the signing ruleset). Not satisfied.

The unsigned commit: #848's branch carries f0aff60a (Merge branch 'main' into docs/822-...) with verification.verified = false, reason = no_user — no GitHub user is associated with that commit's committer email (REST commits verification reasons, about commit signature verification). With required_signatures active (available-rules-for-rulesets), one unsigned commit on the head branch is sufficient to hold mergeStateStatus=BLOCKED even with everything else green (about-protected-branches).

Why the merge-gate script never surfaced it: the readiness read consumes statusCheckRollup + reviewDecision + thread counts. required_signatures is a ruleset rule fed directly into mergeStateStatus, not a status check — it is absent from every field the script reads, so the gate sees "all green" yet mergeStateStatus stays BLOCKED. That is the actual gap, and it is distinct from #374's UNSTABLE-stuck-check mode and from this repo's own stuck-checks.md (which only covers UNSTABLE).

This is not #35251. That community thread is the opposite case — commits all verified yet UI says blocked (a spurious display bug). #848 has a genuinely unsigned commit; the block is legitimate rule enforcement, not a bug.

#1064 — a genuine UNKNOWN, already resolved

#1064's pre-merge branch was fully signed (all 19 commits verified=true) — no signature problem at all. Its UNKNOWN was exactly what UNKNOWN means: GitHub had not finished computing mergeability (the async state). This is the only place the report's "computation didn't settle" framing had a basis — but it is not a check-count/ruleset-fan-out limit, it is ordinary async mergeability compute. It cleared the moment the author squash-merged (a merge attempt forces GitHub to finalize the computation); the resulting squash commit cc5a208f is verified/valid. Nothing to fix; if an UNKNOWN recurs, poll/retry or attempt the merge — it is not a permanent state.

Ruleset config — no misconfiguration

required_status_checks split across two rulesets is clean, not pathological:

• ci-gate → pr-title / pr-title, ci-status
• security-review-gate → security-review / security-review

No overlapping/duplicate contexts, no phantom context absent from the check-run set; all three required contexts exist and are green. required_signatures is deliberate policy, not a bug. No github-iac / Pulumi ruleset change is warranted (and per this repo's conventions, ruleset changes route to the github-iac repo and are never auto-applied regardless).

Actionable fix — where it belongs

1. docs(planning): reframe interview session-config framing #848 (branch-owned, do now): the author can squash-merge — squash condenses the branch, unsigned commit included, into one GitHub-signed commit, which satisfies required_signatures (this is exactly how feat(repo-hygiene): fleet batch mode for the caches/build/git/all tiers #1064 cleared). Alternatively, rebase the branch to drop the unsigned merge commit f0aff60a and force-push signed so mergeStateStatus clears to CLEAN and the automated gate reads ready. The rebase is secondary: f0aff60a is one of ~9 Merge branch 'main' commits, and a local rebase still requires the author to sign the rebuilt commits. The merge-gate correctly refusing to auto-bypass BLOCKED is working as designed — the remediation is an author/maintainer action, not a gate bypass.
2. Optional durable follow-up (source-control plugin, tooling-owned): when mergeStateStatus is BLOCKED with required checks green, 0 unresolved threads, and 0 required approvals, probe pulls/{n}/commits for verification.verified=false and surface "unsigned commit → required_signatures block" as a material finding with the author-squash remediation. This closes the blind spot that made docs(planning): reframe interview session-config framing #848 look like an inexplicable stuck state.

No GitHub support ticket needed — #848 is a legitimate branch-content block with a known fix; #1064 was ordinary async compute that already resolved.

Decision defaulted: close #1087 as diagnosed — two distinct causes, neither a platform bug: #848 = unsigned commit f0aff60a tripping required_signatures (fix by author squash-merge or rebase-and-force-push signed), #1064 = ordinary async UNKNOWN that already merged; no github-iac ruleset change, optional source-control tooling follow-up to detect signature-blocks — veto before merge

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave (frontier consensus).

Dual-panel drain ruling: advisory, superseded, folded into a program umbrella, or blocked on a host/design carrier without an actionable in-repo slice this session. Re-open with a concrete acceptance brief if a consumer needs the work.

KEEP set for this wave: standing telemetry; host-physical Class C (#631 family); program umbrellas #530/#531/#532/#535; live design carriers #1500/#1553/#1668/#1695/#1716/#1681/#1718; #1360.