[Decision] After a PR is open, merge main only on a conflict, a main-caused CI red or a queue removal, and re-check only the overlap; or keep merging main before every push #23390

Ruled: 6160990111 · letter A · 2026-10-14T04:36Z

The problem in one sentence: every PR lands hours later than it needs to. Developers keep re-testing their branch against a main that moves every few minutes, and the landing step already re-tests every PR against the newest main anyway.

Filed by domain:engine seat 2 (session_01ADzJtzYTLUfgrRZHxkagkX) at 2026-10-14T04:16Z, on the maintainer's order in this seat's session: 「关于这个规则是否合理，开决策卡」. This followed their question 「main 就是一直在合并，你一直修有什么意义呢？有没有更好的方案。」 ⛔ Not dispatchable; it is the maintainer's to rule. Triage adds domain:* and area:*.

Background

• Since S8's merge-ref red (fix(plugin-approvals,plugin-security): the approval request actions name the request in their success copy, and Explain access names the principal as a person #23202 broke S8 on the merge ref), this seat had told its devs to "merge main before every push". Each merge was followed by the full local battery: full build, the @objectstack/cli suite in 10 shards, dogfood, and 67–120 derived gates. That takes 1 to 2.5 hours per round.
• main takes many merges an hour. The devs merged it repeatedly and re-ran everything each time. This was measured on this seat's own cards in the last 24 hours:
  • C3 #15204 stages 7a ∥ 7b → 8-post, build ahead: delete the permission-set projection and the position write-through that stage 8 leaves unreferenced, then the post-stage-8 catalog gates and residue #22975 7a: three merges of main (to 6d96721faa, 18cd410dc4 and 28e294f450), each followed by a full re-run (reports 6160255066 and the session's own log). 7a took about 3 hours from resume to PR.
  • fix(plugin-security): an environment kernel's security catalog serves permission sets and positions saved through the metadata door again (S8 regression) #23308 (PR fix(plugin-security): an environment kernel's security catalog serves metadata-door permission sets and positions again #23334): two merges, each re-run in full (report 6157413368).
• At 2026-10-14T04:20Z this seat amended its own card's dispatches (C3 #15204 stages 7a ∥ 7b → 8-post, build ahead: delete the permission-set projection and the position write-through that stage 8 leaves unreferenced, then the post-stage-8 catalog gates and residue #22975, 6160721338): no proactive merges of main, scoped re-checks, and dogfood once on the final head. That is option A applied to one lane, as a seat execution parameter. The maintainer can overrule it at once, and the seat then reverts.

Governing text:

• AGENTS.md §7: "The queue rebuilds your PR as merged onto the current main, re-runs the subscribing workflows on that rebuilt generation, and lands it only if the required ones pass — the §10 re-verification, done by the platform, race-free."
• AGENTS.md §10: "Before opening a PR, pull main, refresh build state (§9), and run the full suite once. For the subsequent pre-merge merges of main — the ones you do only because main moved again while CI ran — scope it", and "Full pnpm typecheck && pnpm test again only when the incoming commits touch the same packages or the same behavior your diff does".
• skills(ci): two-speed CI — fast set on PR and merge-queue runs, full battery hourly on main and before a release, main-red stops the lane, four required contexts plus the guard, timing gates report-only, test budgets not deletions #22998 (two-speed CI, closed): PR and merge-queue runs carry the fast set; the full battery runs hourly on main, and a main red stops the lane. AGENTS.md does not say when a branch must merge main after its PR is open.

Protocol: no packages/spec contract changes under any option. This is a working-practice rule for developers and PM seats.

Premises (each with a re-check)

1. The merge queue rebuilds each PR onto the current main and re-runs the required set before it lands. Re-check: grep -n "rebuilds your PR" AGENTS.md, and grep -n "merge_group:" .github/workflows/ci.yml.
2. A PR's CI already runs on the merge ref, the PR head merged into main at run time. Re-check: the docs-drift comment on any open PR states "the merge of head … into base, which is what actions/checkout gives a pull_request run".
3. Dogfood runs on neither PR nor merge-queue runs, only in the hourly full battery. Re-check: grep -n "github.event_name != 'pull_request' && github.event_name != 'merge_group'" .github/workflows/ci.yml.
4. The one joint breakage this lane met (S8 against main's new test, fix(plugin-approvals,plugin-security): the approval request actions name the request in their success copy, and Explain access names the principal as a person #23202) was caught by CI on the merge ref, not by a local merge. Re-check: S8's landing record 6148225009 on C3 #15204 stage 8: S8-T #22962 + S8 retire the four catalog row objects; both Tier H; land right after D #22900 (handed to the engine lane) #23056.

The question

Once a PR is open, when must a developer merge main into it, and how much must they re-verify after?

Options

In business terms:

• A means the assembly line has one final inspection at the gate (the queue), so each worker stops re-inspecting every time a neighbour finishes a part.
• B means some foremen tell their crews this and others do not.
• C means every worker re-inspects the whole product whenever anything on the line changes.

四维分析

• 项目长远合理性（权重最高）: 主流平台把“和最新主干合起来是否还对”交给合并队列做最后把关，GitHub merge queue、bors、Zuul 都是这个模式。正是为了不让每个分支一直追主干，才有了合并队列，它替代的是“分支必须保持最新”这条规则。A 把这件事写成团队规则，以后不会又被各席位各自加回来。B 只在一部分车道生效。C 是合并队列出现之前的老办法。
• 实际业务拉动: 今天就受影响。本席位一天里 7a 追了 3 次主干，fix(plugin-security): an environment kernel's security catalog serves permission sets and positions saved through the metadata door again (S8 regression) #23308 追了 2 次，每次重跑 1 到 2.5 小时，维护者在等审批，问了两次进度。其他车道情况不明（见置信缺口）。
• 防 AI 犯错: 出错时谁看到什么。A 下，两个改动单独都对、合起来出错时，合并队列会把 PR 踢出来并亮红，主干每小时的完整检查也会亮红并停线，都是响亮的拒绝，没有静默放过。C 的代价是时间，不是安全；而且开发报告里写的提交号总在变，审查对着的版本经常已经过时，反而更容易出错。
• 创业阶段不扩散: A 删掉一个重复的仪式，不加新门禁，只把已有规则（§7、§10）说清楚。C 等于每轮多付一次重复验证。

Recommendation

• A. Fallback: B.
• Confidence gap: this was measured on one lane. How often other lanes chase main is not visible to this seat. A also assumes the queue's required set and the hourly battery stay as skills(ci): two-speed CI — fast set on PR and merge-queue runs, full battery hourly on main and before a release, main-red stops the lane, four required contexts plus the guard, timing gates report-only, test budgets not deletions #22998 set them.
• Self-check: on ① alone the choice is A. Do ②③④ flip it? No.

After the ruling

• A: this seat files the governed card in the domain:skills lane: AGENTS.md §10, .claude/agents/os-dev.md, and the pm-dispatch dispatch template. The maintainer approves that PR. This lane keeps 6160721338 meanwhile.
• B: this lane keeps 6160721338. No card.
• C: this seat withdraws 6160721338 on C3 #15204 stages 7a ∥ 7b → 8-post, build ahead: delete the permission-set projection and the position write-through that stage 8 leaves unreferenced, then the post-stage-8 catalog gates and residue #22975 and its devs return to merging main before every push.

os-decision-facets

• ① 项目长远合理性：A 缩小特例，把“和主干的兼容性”统一交给合并队列这一处把关，各席位不再各自定规矩。
• ② 实际业务拉动：今天就有，本席位一天里因追主干多花了约 5 轮、每轮 1 到 2.5 小时，维护者在等。
• ③ 防 AI 犯错：A 下合起来出错时由合并队列或主干每小时完整检查响亮拒绝，不会静默放过；C 只是更慢，不是更安全。
• ④ 创业阶段不扩散：A 删掉一个重复仪式，不新增门禁。
  Prior rulings read: "merge main", "behind main", "merge queue re-verification", "stale branch" → 0 rulings; skills(ci): two-speed CI — fast set on PR and merge-queue runs, full battery hourly on main and before a release, main-red stops the lane, four required contexts plus the guard, timing gates report-only, test budgets not deletions #22998 (two-speed CI); AGENTS.md §7, §10; thread: none