Add the merge-bot workflow

[ptr727]

Closes the merge-bot-pull-request.yml gap from the 2026-08-02 hub audit (audit run 2026-08-02T16:10Z | hub 69688ec).

Why it matters here

Dependabot already opens pull requests against both main and develop (both ecosystems dual-target, per .github/dependabot.yml), and nothing merged them. Every dependency and action bump waited on a manual merge, which is how action pins go stale between sweeps. The audit classified the absence as drift rather than a letter miss, since the file is declared appliesTo: "*" with fidelity: interface.

What it carries

The two jobs the contract requires (requiredJobKeys in spec/files.json):

• merge-dependabot - enables auto-merge on an in-repo Dependabot pull request, squash onto develop and merge onto main. Every tier auto-merges, semver-major included, because the required checks are the gate rather than the size of the bump.
• disable-auto-merge-on-maintainer-push - fires when a maintainer pushes to a bot's branch, so their commits do not merge along with the bot's. Idempotent, and re-enabled by hand.

The fleet canonical also carries merge-codegen and merge-upstream-version. This repository runs neither codegen nor an upstream-version tracker, so both are N/A under WORKFLOW.md section 1 and are left out rather than carried as conditions that can never match. The file is interface fidelity, so it is checked by required job names and wiring rather than byte-for-byte.

Dependencies checked, not assumed

The workflow needs an App token, and CODEGEN_APP_CLIENT_ID / CODEGEN_APP_PRIVATE_KEY are already configured in both the Actions and Dependabot stores. These are baseline secrets in spec/secrets.json, implicit for every fleet repo and deliberately not repeated in the registry's requiredSecrets, so no registry change is needed.

pull_request_target is used rather than pull_request because the jobs hold the App key, so the workflow and action SHAs resolve from the trusted base. It is safe here because no job checks out pull request code; each runs gh pr merge by URL. The create-github-app-token pin matches the hub canonical exactly.

Verification

actionlint, editorconfig-checker, and the hub prose gate all report clean, and the parsed job keys are exactly the two the contract requires.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 44.96%. Comparing base (1ab0f11) to head (7ce1a25).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop      #38   +/-   ##
========================================
  Coverage    44.96%   44.96%           
========================================
  Files           25       25           
  Lines         3398     3398           
  Branches       259      259           
========================================
  Hits          1528     1528           
  Misses        1824     1824           
  Partials        46       46           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Adds the missing GitHub Actions workflow that auto-manages Dependabot PR merging for this repo, aligning with the fleet “merge-bot” contract by enabling auto-merge on new/reopened bot PRs and disabling it when a maintainer pushes to the bot branch (to avoid merging maintainer commits unintentionally).

Changes:

• Introduces a pull_request_target workflow to enable auto-merge on in-repo Dependabot PRs using a GitHub App token.
• Adds an idempotent job that disables auto-merge when a non-bot actor pushes to a Dependabot PR branch.

Suppressed comments (1)

.github/workflows/merge-bot-pull-request.yml:80

• This job also authenticates gh using the GitHub App token (GH_TOKEN), so it shouldn’t need GITHUB_TOKEN permissions. Setting permissions to none reduces exposure for a secrets-using pull_request_target workflow.

    permissions:
      pull-requests: write

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

.github/workflows/merge-bot-pull-request.yml:79

• This job doesn't use GITHUB_TOKEN to write to PRs (it uses GH_TOKEN from the GitHub App token), so the current pull-requests: write permission is unnecessary. Reduce permissions to least privilege.

    permissions:
      pull-requests: write

.github/workflows/merge-bot-pull-request.yml:37

• Job-level permissions currently grant GITHUB_TOKEN write access (contents/pull-requests), but the job uses GH_TOKEN (GitHub App token) for the merge. Tighten the job permissions to avoid granting unnecessary write permissions to GITHUB_TOKEN.

    permissions:
      contents: write
      pull-requests: write

.github/workflows/merge-bot-pull-request.yml:24

• This workflow uses a GitHub App token via GH_TOKEN for all write operations, so GITHUB_TOKEN can be constrained at the workflow level to least privilege to reduce the blast radius if a future step accidentally uses it.

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
  cancel-in-progress: false

jobs:

[ptr727]

Suppressed findings answered

All four collapsed findings, across both rounds on 7ce1a25, make the same point as the inline thread: the jobs authenticate with the App token, so the GITHUB_TOKEN permissions are unused. All correct. No change here, raised upstream as ptr727/ProjectTemplate#521, because this file is fleet-carried and a one-repo change would diverge from the canonical and be reverted by the next re-vendor.

Round 1, Suppressed comments (1)

1. merge-bot-pull-request.yml:80 - No change needed here, tracked in ptr727/ProjectTemplate#521

This job also authenticates gh using the GitHub App token (GH_TOKEN), so it shouldn't need GITHUB_TOKEN permissions. Setting permissions to none reduces exposure for a secrets-using pull_request_target workflow.

Accurate, including the point about it being a secrets-using pull_request_target workflow, which is why it is worth acting on rather than filing and forgetting.

Round 2, Suppressed comments (3)

2. merge-bot-pull-request.yml:79 - No change needed here, tracked in ptr727/ProjectTemplate#521

This job doesn't use GITHUB_TOKEN to write to PRs (it uses GH_TOKEN from the GitHub App token), so the current pull-requests: write permission is unnecessary.

3. merge-bot-pull-request.yml:37 - No change needed here, tracked in ptr727/ProjectTemplate#521

Job-level permissions currently grant GITHUB_TOKEN write access (contents/pull-requests), but the job uses GH_TOKEN (GitHub App token) for the merge.

4. merge-bot-pull-request.yml:24 - No change needed here, tracked in ptr727/ProjectTemplate#521

This workflow uses a GitHub App token via GH_TOKEN for all write operations, so GITHUB_TOKEN can be constrained at the workflow level to least privilege to reduce the blast radius if a future step accidentally uses it.

This one names the real risk most precisely. The grant is not exploitable today, since no step reads GITHUB_TOKEN, but it is standing write access on the one workflow where a carelessly added future step would inherit it. The workflow-level versus job-level question it raises is carried into the upstream issue as an open decision rather than settled here.

---

Verified rather than assumed: gh pr merge and gh pr merge --disable-auto both read GH_TOKEN, actions/create-github-app-token authenticates from the client id and private key, and no job in this file checks out code.

The upstream issue also asks whether the audit should compare permissions at all. It does not today, because the contract for this file checks required job keys rather than the body, which is why this drift would not be flagged on any repo carrying it.

4 of 4 suppressed findings, plus the inline thread, are now answered.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.