mberman84 · Jun 21, 2026 · Jun 21, 2026 · Jun 21, 2026
diff --git a/.mergequeue.example.toml b/.mergequeue.example.toml
@@ -45,6 +45,8 @@ thread_active_hours = 72
 ci_workflows = ["CI"]
 deploy_workflows = ["Deploy"]
 repair_hold_minutes = 60
+hold_merges_while_releasing = true
+repair_branch_prefix = "deploybot/repair"
 ready_to_merge_target_minutes = 15
 merge_to_live_target_minutes = 10
 auto_promote = true
@@ -63,3 +65,5 @@ pause_on_failure = true
 mode = "manual"
 branch_prefix = "deploybot/integration"
 title_prefix = "DeployBot integration"
+max_batch_size = 3
+require_non_actions_author = false
diff --git a/README.md b/README.md
@@ -11,11 +11,11 @@ integration PRs, follows `main` through production, and pauses after failures.
 
 ## Install
 
-Install the reviewed `v0.2.11` source commit directly from GitHub:
+Install the reviewed `v0.2.12` source commit directly from GitHub:
 
 ```bash
 python3 -m pip install \
-  'deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@bf1ccadb3a4110dd29b70efe4f621f822110bfcc'
+  'deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@01c8c6e48c3a92155803cd4232b56b0c1d3363c2'
 deploybot init
 ```
 
@@ -95,7 +95,7 @@ worker can dispatch deployment when GitHub suppresses the `workflow_run` event
 for token-dispatched CI. Pin the Action to the full reviewed release commit:
 
 ```yaml
-- uses: Forward-Future/DeployBot@bf1ccadb3a4110dd29b70efe4f621f822110bfcc
+- uses: Forward-Future/DeployBot@01c8c6e48c3a92155803cd4232b56b0c1d3363c2
 ```
 
 The Action uses GitHub's built-in workflow token. GitHub intentionally does not
@@ -111,6 +111,13 @@ from pull-request CI are ignored. Set Action input `dispatch_ci: "false"` only
 when a caller supplies a different merge identity that already triggers push
 CI.
 
+When integration PR checks depend on normal PR-authored events, mint a GitHub
+App installation token in an earlier workflow step and pass it as the Action's
+`token` input. Set `integration.require_non_actions_author = true` so a missing
+App token fails before it freezes or creates an unusable integration PR. Add
+the App's exact bot login (for example, `deploybot-app[bot]`) to
+`queue.coordinator_actors` so its integration records are trusted.
+
 The deployment workflow keeps its normal `workflow_run` trigger for push CI
 and adds this exact-input recovery path for DeployBot-dispatched CI:
 
@@ -158,7 +165,13 @@ ready-to-merge target and names the current gate. It never stores prompts,
 transcripts, source, or credentials.
 
 `deploybot react` promotes ready intent, skips blockers, drains independent
-work, and creates integration PRs when configured. Draft status and incomplete
+work, and creates integration PRs when configured. New batches contain at most
+`integration.max_batch_size` entries; later FIFO work remains in the next batch.
+A larger indivisible source-overlap or dependency closure is the sole exception:
+it ships alone, never mixed with unrelated work.
+After any merge, admission stays closed until the cumulative exact-main release
+is verified live, preventing newer merges from starving an older deployment.
+Draft status and incomplete
 checks or reviews remain waiting states; they do not create a repair latch. A
 conflict, failed gate, unresolved review, manual block, or stale authorized head
 produces a repair handoff containing the source thread, base/head SHAs, source
@@ -178,6 +191,11 @@ and emits a new wake-up event. `follow` tracks newer cumulative `main` revisions
 until exact CI, deployment, and optional HTTP checks pass. A CI or deploy failure
 can pause further merges until `deploybot unpause`.
 
+Before starting an exact-main recovery, an agent runs
+`deploybot claim-release-repair --provider CLIENT --thread-id ID`. A
+deterministic branch ref elects exactly one repair owner for that failed SHA;
+other threads receive the recorded owner instead of creating duplicate PRs.
+
 At merge time, DeployBot records a non-expiring notification obligation. At
 exact-main verification, it promotes every contained obligation to `pending`,
 moves the matching source thread to `deployed` when that thread has not moved
@@ -212,6 +230,8 @@ deploy_workflows = ["Deploy"]
 batch_settle_seconds = 15
 ci_failure_grace_seconds = 90
 promotion_workers = 4
+hold_merges_while_releasing = true
+repair_branch_prefix = "deploybot/repair"
 ready_to_merge_target_minutes = 15
 merge_to_live_target_minutes = 10
 auto_promote = true
@@ -226,6 +246,8 @@ expected_status = 200
 [integration]
 # manual, overlap, or all (one cumulative pre-merge validation PR)
 mode = "overlap"
+max_batch_size = 3
+# require_non_actions_author = true
 ```
 
 For `overlap` or `all` mode with the hosted coordinator, enable **Allow GitHub

diff --git a/action.yml b/action.yml
@@ -17,6 +17,10 @@ inputs:
     description: Maximum release-follow time in seconds
     required: false
     default: "1800"
+  token:
+    description: GitHub App installation token used to author integration PRs
+    required: false
+    default: ""
 runs:
   using: composite
   steps:
@@ -28,7 +32,7 @@ runs:
     - shell: bash
       env:
         DEPLOYBOT_CONFIG: ${{ inputs.config }}
-        GH_TOKEN: ${{ github.token }}
+        GH_TOKEN: ${{ inputs.token || github.token }}
         DEPLOYBOT_FOLLOW: ${{ inputs.follow }}
         DEPLOYBOT_DISPATCH_CI: ${{ inputs.dispatch_ci }}
         DEPLOYBOT_TIMEOUT: ${{ inputs.timeout }}

diff --git a/adapters/claude-code/.claude-plugin/plugin.json b/adapters/claude-code/.claude-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "deploybot",
-  "version": "0.2.11",
+  "version": "0.2.12",
   "description": "DeployBot: a provider-neutral GitHub merge queue for coding agents",
   "author": {
     "name": "DeployBot contributors"

diff --git a/adapters/claude-code/.mcp.json b/adapters/claude-code/.mcp.json
@@ -4,7 +4,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@bf1ccadb3a4110dd29b70efe4f621f822110bfcc",
+        "deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@01c8c6e48c3a92155803cd4232b56b0c1d3363c2",
         "deploybot-mcp"
       ]
     }

diff --git a/adapters/claude-code/skills/deploybot/SKILL.md b/adapters/claude-code/skills/deploybot/SKILL.md
@@ -79,6 +79,22 @@ Use `diagnose`/`deploybot doctor` for setup drift and `delivery_metrics` for p50
 p95, and slow-stage evidence. A failed cumulative CI or deployment pauses the
 controller; only a designated coordinator may unpause after recovery.
 
+Before opening or editing an exact-main recovery PR, call
+`claim_release_repair` with the native provider and thread ID. Work only when it
+returns `owned`, using its deterministic branch. If it returns `claimed`, the
+named thread already owns that failed SHA; wait for that repair and never create
+a competing PR. The owner is encoded in the atomic branch ref, so a registry
+write failure is recovered by calling the same tool again.
+
+New batches are FIFO-bounded by `integration.max_batch_size`, and a merged batch
+closes admission until its cumulative main revision is verified live. Do not
+override either boundary for later work. Never execute merged PR code inside
+the privileged coordinator; generated-artifact conflicts go to the elected
+repair owner for a normal reviewed rebuild. When PR-authored checks are
+required, use a GitHub App installation token, list its bot login in
+`queue.coordinator_actors`, and enable `require_non_actions_author`; never manually re-author a
+workflow-token integration PR.
+
 ## Notify Source Threads
 
 After exact-main verification, `follow_release` returns one

diff --git a/adapters/claude-code/skills/manage-merge-queue/SKILL.md b/adapters/claude-code/skills/manage-merge-queue/SKILL.md
@@ -24,6 +24,11 @@ A genuine repair remains merge-ineligible, but DeployBot may temporarily hold
 overlapping ready work for the configured bounded repair window so concurrent
 merges do not repeatedly invalidate the replacement head.
 
+Before creating an exact-main recovery, call `claim_release_repair`; only the
+returned `owned` thread may use the deterministic repair branch. Respect the
+maximum batch size and keep new merges closed while an earlier release is
+unfinished.
+
 When `follow_release` returns `thread_notifications`, send each supplied
 message to its native source thread. The source thread calls
 `acknowledge_thread_deployment` with the matching `notification_id`. Present the

diff --git a/adapters/codex/agent-merge-queue/.codex-plugin/plugin.json b/adapters/codex/agent-merge-queue/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "deploybot",
-  "version": "0.2.11",
+  "version": "0.2.12",
   "description": "Coordinate exact-head pull requests through verified deployment and thread notification",
   "author": {
     "name": "DeployBot contributors"

diff --git a/adapters/codex/agent-merge-queue/skills/deploybot/SKILL.md b/adapters/codex/agent-merge-queue/skills/deploybot/SKILL.md
@@ -76,6 +76,22 @@ Use `deploybot doctor --json` for setup drift and `deploybot metrics --json` for
 p50, p95, and slow-stage evidence. A failed cumulative CI or deployment pauses
 the controller; only a designated coordinator may unpause after recovery.
 
+Before opening or editing an exact-main recovery PR, run
+`deploybot claim-release-repair` with the native provider and thread ID. Work only when it
+returns `owned`, using its deterministic branch. If it returns `claimed`, the
+named thread already owns that failed SHA; wait for that repair and never create
+a competing PR. The owner is encoded in the atomic branch ref, so a registry
+write failure is recovered by calling the same tool again.
+
+New batches are FIFO-bounded by `integration.max_batch_size`, and a merged batch
+closes admission until its cumulative main revision is verified live. Do not
+override either boundary for later work. Never execute merged PR code inside
+the privileged coordinator; generated-artifact conflicts go to the elected
+repair owner for a normal reviewed rebuild. When PR-authored checks are
+required, use a GitHub App installation token, list its bot login in
+`queue.coordinator_actors`, and enable `require_non_actions_author`; never manually re-author a
+workflow-token integration PR.
+
 ## Notify Source Threads
 
 After exact-main verification, `deploybot follow --json` returns one

diff --git a/adapters/codex/agent-merge-queue/skills/manage-merge-queue/SKILL.md b/adapters/codex/agent-merge-queue/skills/manage-merge-queue/SKILL.md
@@ -25,6 +25,11 @@ A genuine repair remains merge-ineligible, but DeployBot may temporarily hold
 overlapping ready work for the configured bounded repair window so concurrent
 merges do not repeatedly invalidate the replacement head.
 
+Before creating an exact-main recovery, run `deploybot claim-release-repair`;
+only the returned `owned` thread may use the deterministic repair branch. Respect the
+maximum batch size and keep new merges closed while an earlier release is
+unfinished.
+
 When `deploybot follow --json` returns `thread_notifications`, send each supplied
 message to its native source thread. In Codex use `send_message_to_thread`;
 the source thread runs `deploybot thread acknowledge` with the matching

diff --git a/adapters/cursor/.cursor/mcp.json b/adapters/cursor/.cursor/mcp.json
@@ -4,7 +4,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@bf1ccadb3a4110dd29b70efe4f621f822110bfcc",
+        "deploybot-merge-queue[mcp] @ git+https://github.com/Forward-Future/DeployBot.git@01c8c6e48c3a92155803cd4232b56b0c1d3363c2",
         "deploybot-mcp"
       ]
     }

diff --git a/docs/reference.md b/docs/reference.md
@@ -1,7 +1,7 @@
 # DeployBot reference
 
 This reference describes the CLI, MCP server, policy file, and GitHub Action in
-DeployBot v0.2.11. GitHub labels and authenticated comments are the durable state;
+DeployBot v0.2.12. GitHub labels and authenticated comments are the durable state;
 the CLI and MCP tools are two interfaces to the same operations.
 
 ## CLI
@@ -59,6 +59,7 @@ has fresh evidence; the user does not need to repeat the instruction.
 | `deploybot follow [--timeout SECONDS] [--poll SECONDS] [--json]` | Follow the newest exact base-branch head through CI, deployment, and HTTP verification. Defaults: 1800-second timeout and 10-second poll. |
 | `deploybot pause --reason TEXT` | Pause merging after a delivery failure. |
 | `deploybot unpause` | Resume a pipeline after verified recovery. |
+| `deploybot claim-release-repair --provider CLIENT --thread-id ID [--thread-url URL] [--sha SHA]` | Atomically claim the owner-encoded deterministic repair branch for the current failed exact-main release. Other threads recover the same owner from the ref instead of creating duplicate repair PRs. |
 
 Only a configured coordinator should run these operations. `react
 --dispatch-ci` is required when the merge identity does not trigger ordinary
@@ -96,6 +97,7 @@ arguments shown below are the tool-specific arguments.
 | `react_to_delivery_event` | `react` | optional `follow`, `dispatch_ci`, `timeout_seconds` |
 | `create_integration_pull_request` | `integrate` | optional `include_all` |
 | `follow_release` | `follow --json` | optional `timeout_seconds` |
+| `claim_release_repair` | `claim-release-repair` | `provider`, `thread_id`; optional `thread_url`, `main_sha` |
 | `delivery_metrics` | `metrics --json` | optional `limit` |
 | `update_agent_thread` | `thread update` | `provider`, `thread_id`, `phase`; optional `pull_request`, `title`, `branch`, `url` |
 | `acknowledge_thread_deployment` | `thread acknowledge` | `provider`, `thread_id`, `notification_id` |
@@ -165,6 +167,8 @@ Provider fields are:
 | `ci_failure_grace_seconds` | Non-negative window for an exact-main CI retry to replace a failed attempt before the release fails. Default: 90. |
 | `promotion_workers` | Positive maximum number of deploy requests promoted concurrently. Default: 4. |
 | `repair_hold_minutes` | Positive maximum time that a genuine repair may hold overlapping ready work without becoming merge-eligible. Default: 60. |
+| `hold_merges_while_releasing` | Default `true`; after a merge, admit no newer batch until the cumulative exact-main revision is verified live. |
+| `repair_branch_prefix` | Deterministic release-repair lease branch prefix; default `"deploybot/repair"`. |
 | `ready_to_merge_target_minutes` | Positive request-to-ready and queued-to-merge timing target; default 15. |
 | `merge_to_live_target_minutes` | Positive timing target; default 10. |
 | `auto_promote` | Default `true`. |
@@ -183,6 +187,8 @@ Provider fields are:
 | `mode` | `"manual"`; allowed: `manual`, `overlap`, `all`. |
 | `branch_prefix` | `"deploybot/integration"` |
 | `title_prefix` | `"DeployBot integration"` |
+| `max_batch_size` | Positive maximum frozen batch size; default 3. Later FIFO entries remain in the next batch. A larger indivisible source-overlap or dependency closure ships alone rather than being split or deadlocked. |
+| `require_non_actions_author` | Default `false`; when `true`, integration creation requires the Action `token` input and an App bot author listed in `queue.coordinator_actors`. |
 
 ## GitHub Action
 
@@ -194,6 +200,7 @@ The composite Action runs `deploybot react` from the checked-out default branch.
 | `follow` | `"true"` | Add `--follow` to the event worker. |
 | `dispatch_ci` | `"true"` | Dispatch configured CI after a merge made with `github.token`. |
 | `timeout` | `"1800"` | Release-follow timeout in seconds. |
+| `token` | `""` | GitHub App installation token used to author integration PRs so normal PR checks and events run; empty falls back to `github.token`. |
 
 The workflow needs `contents: write`, `pull-requests: write`, `checks: read`,
 `issues: write`, and `actions: write`. Use the event filters, concurrency group,
@@ -209,8 +216,11 @@ with `pipeline.ci_workflows`.
 - `MERGE_QUEUE_CONFIG` selects the policy path when `--config` is absent.
 - The variable named by `pipeline.webhook_url_env` supplies the optional event
   webhook URL.
-- The composite Action maps `github.token` to `GH_TOKEN`; callers do not need to
-  create a separate token when its documented permissions are sufficient.
+- The composite Action maps `token` to `GH_TOKEN`, falling back to
+  `github.token`. Repositories that require PR-authored checks for cumulative
+  integration must pass a GitHub App installation token, list that App's bot
+  login in `queue.coordinator_actors`, and set
+  `integration.require_non_actions_author = true`.
 
 The `thread-deployed` event contains `notification_id`, `repository`,
 `provider`, `thread_id`, `main_sha`, and a user-facing `message`, plus available

diff --git a/examples/github-workflow.yml b/examples/github-workflow.yml
@@ -59,5 +59,5 @@ jobs:
         with:
           ref: ${{ github.event.repository.default_branch }}
           persist-credentials: false
-      # v0.2.11 implementation; keep the full commit for privileged workflows.
-      - uses: Forward-Future/DeployBot@bf1ccadb3a4110dd29b70efe4f621f822110bfcc
+      # v0.2.12 implementation; keep the full commit for privileged workflows.
+      - uses: Forward-Future/DeployBot@01c8c6e48c3a92155803cd4232b56b0c1d3363c2
diff --git a/pyproject.toml b/pyproject.toml
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "deploybot-merge-queue"
-version = "0.2.11"
+version = "0.2.12"
 description = "DeployBot: a provider-neutral GitHub merge queue for coding agents"
 readme = "README.md"
 license = "MIT"

diff --git a/skills/deploybot/SKILL.md b/skills/deploybot/SKILL.md
@@ -79,6 +79,22 @@ Use `diagnose`/`deploybot doctor` for setup drift and `delivery_metrics` for p50
 p95, and slow-stage evidence. A failed cumulative CI or deployment pauses the
 controller; only a designated coordinator may unpause after recovery.
 
+Before opening or editing an exact-main recovery PR, call
+`claim_release_repair` with the native provider and thread ID. Work only when it
+returns `owned`, using its deterministic branch. If it returns `claimed`, the
+named thread already owns that failed SHA; wait for that repair and never create
+a competing PR. The owner is encoded in the atomic branch ref, so a registry
+write failure is recovered by calling the same tool again.
+
+New batches are FIFO-bounded by `integration.max_batch_size`, and a merged batch
+closes admission until its cumulative main revision is verified live. Do not
+override either boundary for later work. Never execute merged PR code inside
+the privileged coordinator; generated-artifact conflicts go to the elected
+repair owner for a normal reviewed rebuild. When PR-authored checks are
+required, use a GitHub App installation token, list its bot login in
+`queue.coordinator_actors`, and enable `require_non_actions_author`; never manually re-author a
+workflow-token integration PR.
+
 ## Notify Source Threads
 
 After exact-main verification, `follow_release` returns one

diff --git a/skills/manage-merge-queue/SKILL.md b/skills/manage-merge-queue/SKILL.md
@@ -49,6 +49,10 @@ merges do not repeatedly invalidate the replacement head.
 
 Finish with `follow_release`, tracking newer cumulative base heads through CI,
 deployment, and configured health checks. A failure pauses further merges until
-the coordinator verifies recovery and unpauses. Record exact heads, review
+the coordinator verifies recovery and unpauses. Before creating that recovery,
+call `claim_release_repair`; only the returned `owned` thread may use the
+deterministic repair branch. Respect the configured maximum batch size and keep
+new merges closed while an earlier exact-main release is unfinished. Record
+exact heads, review
 verdicts, merged commits, waiting items, repair packets, integration groups, and
 delivery timing.
diff --git a/src/agent_merge_queue/__init__.py b/src/agent_merge_queue/__init__.py
@@ -1,3 +1,3 @@
 """DeployBot: a provider-neutral GitHub merge queue for coding agents."""
 
-__version__ = "0.2.11"
+__version__ = "0.2.12"