ci(claude-security-review): merge-queue execution evidence — merge_group runs pass through without review

[kyle-sexton]

🤖 Agent-authored (autonomous babysit lane, fable-autopilot). Deferred carve-out recorded during #266 / #269, operator-ratified.

The gap

claude-security-review's required check asserts execution evidence — proof a security pass ran (ADR 0002's #509 addendum). Since #269 that claim is enforced by failing closed when an in-scope review could not run.

That enforcement is scoped to pull_request events only. A merge_group run passes through: it reports green without any review having happened.

Why it is deliberate, not an oversight

The pinned anthropics/claude-code-action cannot serve merge_group at all. At the pinned SHA 12531344451323133b0493233c759991ac61da12 (v1.0.174), merge_group appears in neither ENTITY_EVENT_NAMES nor AUTOMATION_EVENT_NAMES, so parseGitHubContext reaches:

throw new Error(`Unsupported event type: ${context.eventName}`);

— src/github/context.ts:251

Every merge_group invocation therefore throws, for a cause no head change can fix and no retry can clear. Failing closed there would pin a permanently red required check and wedge any adopting consumer's merge queue — with no explanatory PR comment, since the comment steps are PR-gated.

Separately, track_progress: true is hardcoded on this lane and its validator rejects every non-pull_request event (src/modes/detector.ts:84-98), so workflow_dispatch / schedule are in the same category.

Why it is low-urgency today

No org repo runs a merge queue. The gap is latent: it becomes real only when one is enabled. claude-code-plugins — the only consumer where this check is required — triggers on pull_request only.

Trigger to revisit

Any org repo adopting a merge queue on a branch protected by security-review-gate, or claude-code-action gaining merge_group support upstream — whichever comes first.

At that point the merge queue is the merge gate, so a green-without-review check there is exactly the silent-evidence failure #266 was filed to eliminate.

Acceptance criteria (when the trigger fires)

• A merge_group run whose security review could not execute does not produce a required-check state that permits the queued merge.
• The remedy does not reintroduce the permanent-wedge failure mode: whatever blocks must be clearable by an operator or by a completing review, not stuck on an event the action rejects.
• The merge_group caveat is removed from the reusable's CONSUMER CONTRACT and from the POSTURE carve-out once the gap is closed.

Where the carve-out is documented

• .github/workflows/claude-security-review.yml — POSTURE section (scope-of-claim paragraph) and the merge_group line of the CONSUMER CONTRACT.
• Adjudicated decision: ci(claude-security-review): infra-failed review reports success and satisfies a required context, authorizing merge without a security pass #266 (comment 5085597282). Implementation: fix(claude-security-review): fail the required check when an in-scope review could not run #269.

[kyle-sexton]

Cross-repo follow-up: ADR 0002 carries the opposite instruction

Recording this here so the carve-out's owner picks it up — it is out of scope for a ci-workflows PR.

melodic-software/claude-code-plugins, docs/adr/0002-default-on-ai-review-advisory-with-earned-promotion.md, revisit triggers:

A merge queue is enabled on the base → the security workflow must add the merge_group trigger, or its required check is never reported for queued PRs (a required check that never runs blocks the merge).

That was correct when written — before the check could fail closed, a reporting check was strictly better than a Pending one. It is now actively wrong: adding the trigger makes the check report green without reviewing, and on a merge queue that is the merge gate. Following the ADR's trigger would produce exactly the false-evidence state #266 was filed to eliminate.

The ADR needs amending to say that a merge queue on a protected base is blocked on this issue, not resolved by adding the trigger. Whoever closes this should amend it in the same change, or file it against claude-code-plugins first.

Documented on the ci-workflows side in #273 (CONSUMER CONTRACT no longer recommends the trigger; POSTURE carve-out cross-links here).

[kyle-sexton]

Documentation side landed: #273 merged as 1480abf. The reusable no longer recommends the merge_group trigger, the POSTURE carve-out cross-links here, and the dogfood caller says the same. This issue stays open — it tracks the underlying gap, not the documentation of it.

Remaining, for whoever picks this up: the ADR 0002 amendment described in the comment above, in melodic-software/claude-code-plugins. This comment was written by an AI agent (fable-autopilot lane).

[kyle-sexton]

This was generated by AI during triage.

Triage disposition: human-gated, priority: low. Already documented by its author as deliberate and operator-ratified (a scoped carve-out from #266/#269, not an oversight) — dormant until its own stated trigger (an org repo adopting a merge queue on a branch protected by security-review-gate, or upstream merge_group support landing in claude-code-action). No action needed now; normalizing off raw intake only.

[kyle-sexton]

Status (2026-08-12 drain): closing as deferred carve-out — trigger still unmet.

Live check: mergeQueue is null on ci-workflows / claude-code-plugins / medley / standards; no org repo runs a merge queue on a branch protected by security-review-gate. Upstream claude-code-action still cannot serve merge_group at the pinned lane SHA. Doc carve-out remains in the reusable POSTURE / CONSUMER CONTRACT (#273).

Reopen when any org repo adopts merge queue under that gate, or upstream adds merge_group support.

[kyle-sexton]

Closed: deferred until org adopts merge queue / upstream merge_group support (trigger unmet as of 2026-08-12).