Auto-merge feature

[danmt]

What's the itch?

We just introduced an auto-merge feature. But there doesn't seem be a way to scope it only for releases.

What would "done" feel like?

There should be either an auto_merge_release toggle or simply limiting auto-merge for non releases. I'm leaning to an additional option

[dan-claude-bot]

🧭 needs-ruling — Should a consumer be able to auto-merge its own release PRs? Half of what you ask for shipped two minutes before you filed, and that turns the other half around: with releases already refused unconditionally, an auto_merge_release toggle can only be an opt-in to shipping without a human.

Options:
A — No new toggle; the unconditional refusal stands. Nothing is built. Your second remedy — "simply limiting auto-merge for non releases" — is what main does today, so this converges as answered and the arc (#460 → #461 → #462) is untouched.
B — Add auto_merge_release, closed by default, as a fifth child of #458: a second input that, only where auto_merge is already on, lets a release-labelled PR through the same five gates. A repository that sets it publishes a tag with nobody at the button.
C — Invert the gate: auto-merge release PRs and nothing else — the literal reading of your first sentence, if that is the one you meant.

Recommend: A. Both remedies you named protect releases, and the one you wrote as the simpler of the two is already shipped, unconditional, and landed ahead of the button that would need it. Your lean to the toggle was formed against a feature that does not behave the way the sentence assumes, so I am not reading it as a decision. Nothing forecloses B — it stays one word away: reply B and I mint it in the same tick.

Blocked:
Stops — nothing. #460 is claimed by @cndgrr (claimed labelled 2026-08-17T07:00:57Z, assigned 07:00:58Z, read from the timeline rather than the thread) and no option here touches its fence: its D2 makes auto_merge_verdict "$desired" = MERGE the entire gate and says "#459 owns the refusal set; this issue owns the act", so B only adds a branch to a function #460 calls. #461 and #462 are blocked, and a DRY_RUN issue-flow pass just now agrees with both declarations (#461 → {#460}, #462 → {#456, #461}). #423 is post-merge on an unrelated wake.
Continues degraded — nothing. Under A the shipped refusal is already right; under B and C it is right until the new child lands. There is no window in which the reconciler merges a release PR, because at 663ba83 it merges nothing at all.

Default: none — hard block, and it can never fire — whether a published artifact ships with no human is yours by construction (LABELS.md:124-125). Saying out loud what inaction selects, so waiting does not read as free: the shipped behaviour is option A, in force since 663ba83 and unrecorded as a decision — inaction is A running unruled, not a neutral pause. No needs-ruling label is set anywhere, because no issue on any board is held behind this; and with no board item, no ladder anchors, so this ask has no timer.

Analysis

The two minutes

when	what
2026-08-17T06:57:11Z	PR #463 merged at 663ba83, closing #459 — the arc's first child
06:57:44Z	the sweep flipped #460 blocked → ready
06:59:20Z	you filed this — 2 min 9 s after the merge
07:00:58Z	@cndgrr claimed #460, the merge itself

So "we just introduced an auto-merge feature" is #463, and it is the only thing that has landed.

What #463 actually shipped — the refusal is in the same commit as the verdict

labels-reconcile.sh:300-307, on main right now:

auto_merge_verdict() { # $1 = this pass's decide_state conclusion (#459)
  [ "$AUTO_MERGE" != off ] || { echo SKIP:off; return; }
  [ "$1" = state:needs-human ] || { echo SKIP:state; return; }
  ! has_label release || { echo SKIP:release; return; }
  is_fleet_login "$AUTHOR" || { echo SKIP:author; return; }
  [ "$MERGEABLE" = MERGEABLE ] || { echo SKIP:mergeable; return; }
  echo MERGE
}

Line 303 is your second remedy, already built: a release-labelled PR returns SKIP:release under every value of auto_merge — merge, squash and rebase alike. It is not reachable-but-unlikely and it is not a default; there is no input that turns it off.

And it is inert, so the refusal landed before the thing it refuses

The one call site, :1139-1141, logs:

if [ "$AUTO_MERGE" != off ]; then
  log "#$n: auto-merge: $(auto_merge_verdict "$desired")"
fi

grep over the whole script at 663ba83 finds no gh pr merge, no pulls/*/merge, no --method PUT — nothing in it merges anything. Shadow mode is the whole of #459: a consumer can switch the toggle on with contents: read still in force and read what it would do. The button is #460, claimed 3 minutes ago.

This was decided once already, and the door was deliberately left open

#458 E4 states it as an epic-wide constraint — "release PRs are never auto-merged, under any value of the input" — resting on README.md:68, "A release is a PR, and merging it ships it".

It got there because the ruling ask on #450 put your own AUTO_MERGE_RELEASE line to you and refused to hold a second ask in reserve over it:

if you want the release toggle in scope, say so in your reply and it is in scope. Left unsaid, it is out.

Your reply was B and nothing else, so it went out of the arc — with E4 recording that "it is one line to ask for and no child forecloses it." This discussion is that line arriving. That is the intended path, not a gap.

Why the correction changes what the toggle would mean

Written against a feature that auto-merged releases, auto_merge_release is a guard: it holds the release back unless you say otherwise. Written against main as it stands, the same name can only be an escape hatch: it lets a release through that is otherwise refused. Same identifier, opposite direction — and the second one is the one that would exist. Your two remedies both point the first way, which is why I am asking rather than minting.

Priced, if you want it anyway: B is cheap to build, and its whole cost is in what it permits. A repo that sets it ships a tag on the reconciler's verdict — state:needs-human, meaning the whole panel approved the current head and no blocker stands — and on nothing else.

And that floor is thinner than the label table makes it look. I checked rather than assumed: blocker:drill-pending — the label for a release PR whose version has no drills/X.Y.Z.md record — is not in BLOCKERS at :49 and is never emitted by blockers(), which computes exactly blocker:conflict, blocker:ci-red and blocker:unrequested. It is maintainer-created and hand-set, and decide_state never reads it. So a correct-but-unevidenced release would not be held off state:needs-human by it. Under B, the last thing standing between a green release PR and a published tag is the panel's approvals — bench minus the author, whatever that comes to on the day.

Where a B child would land on the board

It edits auto_merge_verdict, so its deliverable is actions/labels-reconcile/labels-reconcile.sh — the file #460 is rewriting and #461 extends. Under the collision contract that is an unconditional edge: the child is minted blocked behind the newest open carrier and becomes one more serial link at the end of the chain. No label on #460 moves, nothing rebases, and #462's doctrine sweep would grow one sentence rather than change shape. It is additive after the arc, not a re-plan of it.

One bound worth naming, under any option

The gate is has_label release, and that label is hand-set intent, not a derived fact — release.yml says it plainly: "The label is the intent, the version transition is the interlock." So the refusal is exactly as good as the label being on the PR — which is the same thing the release door itself depends on, and the interlock refuses a half-ceremony loudly either way. I mention it because under B it is the surface that decides whether a tag ships unattended, and it is worth knowing it is one label.

Not asked here

Whether to adopt auto-merge in any repository — #458 E14 turns it on nowhere, including here, and adoption is your act per repository once the arc releases. Anything about merge-next, branch protection, or allow_auto_merge; all three are out of the arc by E1/E11 and unchanged by any option above.

@danmt — one word does it: A, B, or C.

[danmt]

@dan-claude-bot let's go B. If I understand correctly the current auto_merge doesn't allow auto merge of releases, this would be a secondary toggle closed by default. I want to have two separate toggles, one that auto merges needs human PRs that are not release, and a second toggle for PRs that are release. Both closed by default.

[dan-claude-bot]

Yes, your reading of main is right — labels-reconcile.sh:303 refuses a release-labelled PR under every value of auto_merge, with no input that turns it off. And your shape is a sharper B than the one I offered: I offered a release flag nested under auto_merge; you want two independent inputs over disjoint sets, each closed by default. Your sentence governs, not my option text — that is the spec, and it is written out below.

I said I would mint in the same tick. I am not, and this is why: I priced B without checking whether an auto-merged release actually ships. It does not.

🧭 needs-ruling — An auto-merged release PR merges but never publishes. May the release door learn a second, dispatch-driven entrance?

Options:
A — Drop the release half. The unconditional refusal stands and gets recorded as a decision. Nothing is built; the arc (#460 → #461 → #462) is untouched.
B — Two children: the second toggle, and a dispatch entrance on release.yml's merge door, so the reconciler wakes the door with the merged SHA and the release tags, publishes and re-arms as it does today.
C — The second toggle alone. An auto-merged release merges without shipping, and you finish each one by hand: push the tag, then re-arm main.

Recommend: B. It is the only option that delivers the thing you ruled for. C is strictly worse than pressing the button yourself — it replaces one act with two, and leaves a window in between where the next fragment-carrying PR reds. A is not a rebuttal of your ruling, it is what happens if the price of B is one you would not have paid. That price, stated plainly: the family's ship door gains a second live entrance in all three repositories, and a tag can be published with nobody at the button. Every interlock still holds — the 5-state table, the release label, the version transition — but the door stops being reachable only by a human's merge.

Blocked:
Stops — only the mint of the release toggle. Nothing else, and nothing on the board.
Continues — the entire arc, untouched. #460 is claimed by @cndgrr (claimed labelled 2026-08-17T07:00:57Z, assigned 07:00:58Z, read from the timeline) carrying PR #465 at head 652a5bd, state:bots-reviewing, no verdicts in yet. #461 and #462 are blocked behind it. All three build the non-release path, which no option here touches — E4 stands until you reverse it, and I reverse it on the epic only when you answer. #423 is post-merge on an unrelated wake.

Default: none — hard block, and it can never fire — the decision is a published artifact (LABELS.md:124-125), and under B it is the door that publishes them. Saying out loud what inaction selects: the shipped behaviour is the unconditional refusal, in force since 663ba83 and still unrecorded as a decision — inaction is A running unruled, not a neutral pause. No needs-ruling label is set anywhere, because no board item is held behind this; with no board item no ladder anchors, so this ask has no timer.

Analysis

The fact I missed, in three measured steps

1. A GITHUB_TOKEN merge raises a push that starts no workflow run. This is #458 E10, and it is the repo's own doctrine: release.yml:69-70 — "the anti-recursion property is unchanged: tags and pushes created with GITHUB_TOKEN fire no workflows."

2. The merge door is gated on the push event, deliberately. release.yml:146-149:

  release-on-merge:
    # The merge door. Gated on the push EVENT as well as the ref (rig's
    # form): a workflow_dispatch of a caller sitting on main — this repo's
    # own release-exercise.yml — must stay dry wiring, never a live door.
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

The tag door is gated the same way (:326-330), "Event-gated like the merge door: dispatch runs stay dry."

3. Therefore an auto-merged release PR runs no door at all. The version bump lands on main; no tag is created, no release is published, and the re-arm step — :281-316, which lives inside that same job — never runs.

E10 said the ship path was untouched. It said so because E4 excluded release PRs. Reverse E4 and E10's own reasoning turns on itself. That is the whole of my error, and it was mine to catch before I put the option to you.

The second consequence: main sits disarmed, and it is not quiet

main is left at a bare X.Y.Z with every fragment consumed. That state is legal at rest — but the next PR that adds a changelog.d/<N>.md fragment goes red on changelog-armed (:128-133):

changelog-armed: these fragments were not consumed: <…> — re-run 'changelog-assemble X.Y.Z'

and BUILDER.md:161 makes every behavior change write one. The guard is a step of ci.yml's self-guards job (:86), so it runs on every PR in every governed repo. The guard's own header (:46-52) names this exact hazard — "it refuses to let main SIT disarmed" — and explicitly rests on the assumption that breaks here: "the '-dev' bump … which the release workflow does automatically in the same job as the publish."

So the failure is not "the tag is late". It is: nothing published, and the repository's PR flow stops at the next behavior change until a human re-arms by hand. By TRIAGE.md's own precedence bar that is front-row breadth — which is why it is a hard block rather than something I route around.

Why #461 does not already fix this

#461 is the post-merge wake, and it exists for exactly this class of loss. But its post_merge_workflow dispatch is a workflow_dispatch, and the merge door refuses every event that is not push — by the comment quoted above, on purpose, so that release-exercise.yml stays dry wiring. #461 restores the consumer's push CI. It cannot restore the door.

Considered and rejected without asking you, because it is an engineering call

The reconciler doing the release act itself — tag, publish, re-arm, inline. That is a second implementation of the single most incident-bought workflow in the family (release.yml's header essay is condensed from box#83/#96, rig#32/#47, cast#96/#111), and the two copies would drift. Rejected. A write-capable PAT, which would make the merge raise real events, is org policy and was never granted — spent in E10 and not revived here.

That leaves waking the existing door as the only mechanism, which is what makes this a clean three-way question rather than an open design.

What B would take

Two children, in order, minted the moment you say the word:

1. The second toggle — the spec below, and it is complete.
2. The dispatch entrance — release-on-merge learns a second, explicitly-distinguished live form that carries the merged SHA as an input (so release-exercise.yml, which passes none, stays dry by construction rather than by event name), plus the checkout of that SHA with fetch-depth: 2 for the base-version arithmetic, plus actions: write on the sweep caller and the reconciler's dispatch after a successful release merge. It is the more consequential of the two by a wide margin, and it would carry the drill rehearsal criterion to match.

Ordering: the toggle cannot ship first, or turning it on half-ships a release. The entrance lands first, or they land together.

What C actually costs, since it is the tempting one

Merge lands automatically. Then you push the bare tag (the documented fallback — release-on-tag publishes), and then you re-arm main yourself, because the tag door does no bump — "no bump (cast's precedent: the fallback does not rewrite main)". Two hand acts replacing one, plus a window in which a builder's PR reds for a reason that is not theirs.

The spec that is ready, so B or a plain "toggle only" is one word

Recorded here so nothing is lost if you pick B — this is child 1, verbatim:

• Two inputs, independent, each carrying its own method. auto_merge_release, accepted off | merge | squash | rebase, default off, validated at all three boundaries exactly as auto_merge is (reusable workflow, composite action, direct script). Independent because you wrote "two separate toggles" over disjoint sets; each carries its own method for Epic: auto-merge as a consumer's own toggle — the reconciler's verdict presses the button, closed by default #458 E3's reason — a repository may have merge commits disabled, and a two-value feature would then be unusable with no way to say so.
• The release label becomes a selector, not a refusal. Governing toggle = auto_merge_release when the PR carries release, else auto_merge. The merge method is the governing toggle's value.
• SKIP:release is retired, and the refusal set drops to four: SKIP:off (the governing toggle is off), SKIP:state, SKIP:author, SKIP:mergeable. The diagnostic moves into the log line — #<n>: auto-merge[release]: SKIP:off — so a repo running auto_merge=merge, auto_merge_release=off can still read why its release PR was left alone. Three assertions in test/labels-reconcile.test.sh change their expectations ("the state refusal precedes the release refusal", "a release PR is refused", and the shadow probe's log string); each change is defended by a new case, because a suite cannot prove its own expectations.
• actions/labels-reconcile — the merge itself: head-pinned, confirmed, and through run() #460's confirmation read gains a symmetric clause. Its D3 refuses when release appeared since the grading; with a selector it must refuse when the label's presence differs in either direction from what the pass graded — the label moving means the governing toggle moved, and merging would ship a head under a toggle this pass never consulted. Refuse, never re-select.
• The call-site gate widens to [ "$AUTO_MERGE" != off ] || [ "$AUTO_MERGE_RELEASE" != off ], or the single-toggle gate hides the verdict from a consumer that set only the second one.
• auto_merge=off, auto_merge_release=merge is reachable and auto-merges only releases — my option C from the last ask, now a configuration rather than a design. Named so nobody reads it as an accident.
• Doctrine follows, in the same PR, because AGENTS.md + REVIEWER.md + LABELS.md + FLEET.md + CONTRIBUTING.md + docs/CONSUMERS.md — "only humans merge" becomes "unless this repo opted in" #462 lands first: every Markdown site that names auto_merge gains the second toggle, censused at claim time rather than listed now. Three of those files are vendored, so consumers see none of it until their own pin bump.
• Adoption still happens nowhere — Epic: auto-merge as a consumer's own toggle — the reconciler's verdict presses the button, closed by default #458 E14 is unchanged, and neither input is set in any caller in this repository.

One thing that does not change under any option, and is worth re-reading before you answer

Under B or C, the last thing between a green release PR and a merged release is the panel's approvals. blocker:drill-pending — the label for a release whose version has no drills/X.Y.Z.md record — is not in BLOCKERS and is never emitted by blockers(); it is hand-set and decide_state never reads it. A correct-but-unrehearsed release would not be held off state:needs-human by it. I am not proposing to change that inside this arc — it is its own issue and its own ask — but it is the floor B would be built on, so it should be in front of you at the moment you answer rather than after.

@danmt — one word: A, B, or C.

[danmt]

B @dan-claude-bot

[dan-claude-bot]

Ruled B, recorded as a decision, and minted — triage, 2026-08-17

The decision, in the form it now binds: a consumer may auto-merge its own release PRs, behind a second input closed by default — and because an auto-merged release publishes nothing on its own, ceremony's merge door learns a second, dispatched entrance so the thing you ruled for actually ships. A (drop the release half) and C (merge without shipping, finish by hand) are spent; no minted issue re-opens either. The hard-block default never fired and no rung was taken: you answered 20 minutes after the ask, and the pick is yours, not mine.

Your shape governs, not my option text. From your first reply — "two separate toggles, one that auto merges needs human PRs that are not release, and a second toggle for PRs that are release. Both closed by default." Two independent inputs over disjoint sets, not a release flag nested under auto_merge. That is what #468 specifies.

No flag to clear. No needs-ruling label was ever set for this ask on any board — nothing was held behind it — re-verified at this write across ceremony, crew and incubator. The one open flag in the family, incubator#248, is a different ask and is untouched.

What was minted

Two children of #458, in the order the ask stated — the entrance first, or they land together:

	issue	queue	what it is
5	#467	ready	release.yml's release-on-merge learns a second live form, distinguished by a new merged-sha input rather than by an event. The shipped head is read from exactly one place; release-exercise.yml stays dry by construction rather than by event name; a dispatched head that is not a 40-hex SHA is refused before anything is checked out. Lands inert — nothing dispatches it yet.
6	#468	blocked behind #467 and #462	auto_merge_release at all three boundaries, the release label turned from a refusal into a selector, SKIP:release retired, the confirmation read made symmetric, a release_workflow input, and the dispatch that wakes the door with the head the merge was pinned to. Plus the doctrine clause for both toggles.

On the epic: E4 is superseded by E19, E17's "No AUTO_MERGE_RELEASE" clause is struck, and E19–E22 record the ruling, its unpriced precondition, why the toggle and the dispatch cannot be split, and what the release half still does not do.

Two places I deviated from the ask, both mine and both disclosed

1. The reconciler's dispatch moved from child 1 into child 2. The ask put it in the entrance child. It cannot live there: the dispatch fires only after a release PR merges, and until auto_merge_release exists no fixture can make a release PR merge — so the branch would ship with an unreachable failing case and an unwritable test, which is the shape Epic: auto-merge as a consumer's own toggle — the reconciler's verdict presses the button, closed by default #458 E7 exists to refuse. The entrance child is now purely the door's side, and it is fully testable on its own.
2. actions/labels-reconcile — auto_merge_release: the second toggle, and the dispatch that ships what it merges #468 adds a refusal you did not ask for. With the second toggle set and release_workflow unset, the verdict refuses (SKIP:no-release-dispatch) rather than merging. That configuration is the one that silently produces exactly the state this ruling exists to avoid — merged, unpublished, main disarmed, and the next builder's PR red for a reason that is not theirs. It is a reachable refusal with a writable test, so it is not the door-already-closed shape the epic forbids. If you would rather that configuration merge anyway, say so and it comes out.

What this costs, restated now that it is real

The family's ship door gains a second live entrance in all three repositories. Every interlock still holds — the 5-state table, the release label, the version transition, the nothing may exist yet assert, and facts.sh's demand for a merged release-labelled PR behind the dispatched SHA — but the door stops being reachable only by a human's merge. And the floor that was in front of you when you answered has not moved: blocker:drill-pending is still not in BLOCKERS, still never emitted, and still never read by decide_state, so under this toggle the last thing between a green release PR and a published tag is the panel's approvals. That is its own issue and its own ask; #468 records it and does not repair it.

Nothing is owed by you now

Adoption is your act, per repository, and this arc turns nothing on anywhere — including here. self-release.yml gains no workflow_dispatch:, no caller gains actions: write, and both new inputs ship off and empty. When the arc releases, opting in is: auto_merge_release on the labels caller, release_workflow naming your release caller, actions: write on the labels caller, and workflow_dispatch: with a merged-sha input on the release caller — four lines, documented by #468's doctrine half before any of them is worth writing.

Closing this as resolved; the record lives on #458.