governance: merge-queue ruleset——agent-registry/template-service 先行（P2-7，ADR-0042）

[randypanding]

摘要

自动合并计划 P2-7（#92，ADR-0042 已合入 agent-registry#59）。多 agent 并发"各自对 main 绿、合起来红"由队列串行化解决。

变更

新 ruleset merge-queue：目标 ~DEFAULT_BRANCH，范围 agent-registry + template-service（高活跃仓先行，观察一周后全量须修订 ADR-0042）；merge_method=squash；保守串行起步（min_entries_to_merge=1，check 超时 1h，max_entries_to_build=5）。

配套（并行 PR）

• agent-registry validate.yml 增 merge_group 触发（队列 required check 上报的前提）
• template-service ci.yml 增 merge_group + EXPECTED_SKIP merge_group 分支（ADR-0032 登记义务）

验证

• JSON 校验
• 合并后 apply ruleset，drift-check §1 文本对账跟随（T4）
• T1 语义冲突拦截 / T3 并发吞吐：apply 后执行

[coderabbitai]

Warning

Review limit reached

@randypanding, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Limit details: You’ve used all 10 included reviews currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ee961e04-6c5d-444a-b102-787fea213956

📥 Commits

Reviewing files that changed from the base of the PR and between c034fe9 and 78259b8.

📒 Files selected for processing (1)

• governance/rulesets/merge-queue.json

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Enable merge queues for agent-registry and template-service

✨ Enhancement ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Adds active merge queues to two high-activity repositories’ default branches.
• Uses squash merges with conservative build limits and one-hour check timeouts.
• Serializes validated merge groups to prevent combined changes from breaking main.

Diagram

graph TD
  Ruleset["Merge Queue Ruleset"] -->|scopes| Repos["Selected Repositories"] -->|default branches| Queue["Merge Queue"] --> Group["Merge Group"] --> Checks{"Checks pass?"}
  Checks -->|Yes| Merge["Squash Merge"]
  Checks -->|No| Queue

Loading

High-Level Assessment

A native GitHub organization ruleset is the appropriate approach because it keeps merge-queue policy declarative, reviewable, and compatible with the existing apply and drift-check tooling. A custom queue bot or separate per-repository rulesets would add operational complexity without improving this controlled two-repository rollout.

Files changed (1) +38 / -0

Other (1) +38 / -0

merge-queue.jsonDefine the initial organization merge-queue ruleset +38/-0

Define the initial organization merge-queue ruleset

• Adds an active default-branch merge queue for agent-registry and template-service, retaining an organization-administrator bypass. It requires squash merging, permits up to five queued builds, uses a one-entry merge threshold, and allows one hour for checks to respond.

governance/rulesets/merge-queue.json

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Invalid merge queue payload 🐞 Bug ≡ Correctness

Description

The merge queue uses an unsupported timeout field and lowercase merge method while omitting three
required parameters, so apply.sh will receive an API validation failure instead of creating the
ruleset. This prevents merge-queue enablement for both targeted repositories.

Code

governance/rulesets/merge-queue.json[R31-34]

+        "check_response_timeout_seconds": 3600,
+        "max_entries_to_build": 5,
+        "merge_method": "squash",
+        "min_entries_to_merge": 1

Relevance

●●● Strong

Deterministic API payload validation bug fix; matches team's pattern of accepting governance
correctness fixes.

PR-#19

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The checked-in payload contains check_response_timeout_seconds, lowercase squash, and lacks
three fields that GitHub documents as required. The repository's apply script sends ruleset files
verbatim to the organization rulesets endpoint.

governance/rulesets/merge-queue.json[29-35]
governance/apply.sh[53-61]
🌐 GitHub documents check_response_timeout_minutes, grouping_strategy, max_entries_to_merge, and min_entries_to_merge_wait_minutes as required merge-queue parameters, and restricts merge_method to uppercase MERGE, SQUASH, or REBASE.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The merge-queue parameters do not match GitHub's organization ruleset API schema. Replace `check_response_timeout_seconds` with `check_response_timeout_minutes` (using `60` for the intended one-hour timeout), use the uppercase `SQUASH` enum, and provide required `grouping_strategy`, `max_entries_to_merge`, and `min_entries_to_merge_wait_minutes` values; use `max_entries_to_merge: 1` to preserve the stated serial grouping policy.

## Issue Context
`governance/apply.sh` submits each ruleset JSON directly to GitHub without transforming its parameters, so the checked-in file must already match the REST API request schema.

## Fix Focus Areas
- governance/rulesets/merge-queue.json[30-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 8 rules

✅ Web pages:

  🌐 rules

  🌐 available-rules-for-rulesets

  🌐 content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md at main · github/docs

  +6 more

Review mode: ⚖️ Balanced: This is an active governance configuration changing merge behavior and bypass scope across two repositories, so it has meaningful operational blast radius despite being a small, localized diff.

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Invalid merge queue payload 🐞 Bug ≡ Correctness

The merge queue uses an unsupported timeout field and lowercase merge method while omitting three
required parameters, so apply.sh will receive an API validation failure instead of creating the
ruleset. This prevents merge-queue enablement for both targeted repositories.

Agent Prompt

## Issue description
The merge-queue parameters do not match GitHub's organization ruleset API schema. Replace `check_response_timeout_seconds` with `check_response_timeout_minutes` (using `60` for the intended one-hour timeout), use the uppercase `SQUASH` enum, and provide required `grouping_strategy`, `max_entries_to_merge`, and `min_entries_to_merge_wait_minutes` values; use `max_entries_to_merge: 1` to preserve the stated serial grouping policy.

## Issue Context
`governance/apply.sh` submits each ruleset JSON directly to GitHub without transforming its parameters, so the checked-in file must already match the REST API request schema.

## Fix Focus Areas
- governance/rulesets/merge-queue.json[30-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools