[kyle-sexton]

No related issue: owner-directed PR-throughput fix (overnight run 2026-10-29; the hub's morning question Q8, decided as option A under the owner's standing direction).

Summary

The pr-merge lane arms a lane PR only below merge.max-in-flight, which counts queued lane entries plus lane merges that a full run of main has not yet verified. At 5, the lane cleared about 5 PRs every ~55 minutes while 13 or more lane PRs opened an hour. pr-merge run 40799692656 logged lane room: {"count":5,"cap":5}, with every CLEAN lane PR left on merge.max-in-flight is 5 and 5 merges are in flight.

Fix

• docs/conventions/pr-pipeline.yaml: merge.max-in-flight 5 -> 10.
• One full run of main's tip verifies every lane merge it contains (perf(pr-merge): batch main's whole-suite runs and stop sleeping after the dispatch #10491: the post-merge check counts a run at any descendant of the merge), so a higher cap arms more PRs per verification cycle and adds no full runs.
• The gate reads max-in-flight at the default branch head, so the raised cap applies as soon as this merges.

Risk

• A red run of main charges up to 10 unverified lane merges instead of 5, and any charge still demotes the rung.
• The merge queue can eject up to 10 entries together when one breaks.

Verification

• docs/conventions/pr-pipeline/pr-pipeline.schema.json: max-in-flight is an integer with minimum 1, so 10 is valid.

Related

• feat(source-control): cap pr-merge lane merges in flight with merge.max-in-flight #8251 set the cap to 5.
• perf(pr-merge): batch main's whole-suite runs and stop sleeping after the dispatch #10491 caps main's full runs at one per 30 minutes; poteto's cap bypass is a separate PR.

🤖 Generated with Claude Code

[kyle-sexton]

• verify skipped by kyle-sexton for this run: local verify failed only on post-merge-demotion-alert.test.sh's 30s time share (37s at load 11-14; 3,421 tests pass); CI runs the suites

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	🔄 Running since 2026-10-29T12:44:19.894674Z	620aa91	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-review reviewed 620aa916145da92868b86440603eb6bf63e53238: 0 finding(s), 0 as inline comments.

No findings. I read both changed files (.claude-lane/pr.diff) and the PR context. I did not run any tests or the pipeline.

What changes: docs/conventions/pr-pipeline.yaml moves merge.max-in-flight from 5 to 10, and a changelog fragment in .changes/pr-pipeline/ records the change.

Checks I made:

• Schema: pr-pipeline.schema.json:1043-1048 defines max-in-flight as an integer with minimum: 1 and no maximum, so 10 is valid.
• Consumers: the gate (enable-auto-merge.mjs) and the Python policy reader (babysit_merge_policy.py) take the cap from config. Neither hardcodes 5.
• Tests: the tests that mention a cap of 5 inject their own config (PIPELINE.replace("merge:\n", "merge:\n max-in-flight: 5\n")). None reads the repository's pr-pipeline.yaml, so none should break.
• Docs: the README description at line 1085 states the default (1) and the mechanism, not this repository's value. It still matches the code, so no doc drift.
• Fragment: the bump: patch fragment describes the change accurately, including the larger red-run charge (up to 10 unverified lane merges) and that any charge still demotes the rung.

Behaviour the PR states and I did not check: a red full run on main now charges up to 10 unverified lane merges instead of 5, and the merge queue can eject up to 10 entries together. The author lists both as accepted risks, and they follow from the cap itself rather than from a defect in the diff.

Spend: more lane PRs can be armed per verification cycle, which spends prepaid or subscription usage only. This is not a hold.

Closing issues: none. The PR states "No related issue", so there are no acceptance criteria to check.

Trusted path: docs/conventions/pr-pipeline.yaml matched the trusted-path list. I read the whole change and what it gates, which is the lane's arming cap. The change only raises a numeric limit, and I found no widened authority or bypass.

[github-actions]

claude-security-review reviewed 620aa916145da92868b86440603eb6bf63e53238: 0 finding(s), 0 as inline comments.

No security findings.

critical-findings: 0

Scope read: the full 2-file diff and the PR context. The change sets merge.max-in-flight from 5 to 10 in docs/conventions/pr-pipeline.yaml (line 973) and adds a changelog fragment, .changes/pr-pipeline/perf-max-in-flight-10-5b1c7e2a.md.

Trust control checked: docs/conventions/pr-pipeline.yaml is a trusted path, and its merge settings are a listed merge-hold control. I read the whole change, plus the neighbouring merge settings and where the cap is consumed (enable-auto-merge.mjs:1344, babysit_merge_policy.py:899-902).

• Who reaches it: only the lanes App's own pull requests count against this cap. The cap is a count of lane merges armed but not yet verified by a full run of main. It does not decide who is trusted, which token scope is minted, or what text reaches a lane.
• What it gets: raising the cap lets more lane merges land before a full run of main verifies them. The PR's own risk section names the cost: a red run charges up to 10 unverified merges, and the queue can eject up to 10 entries together. That is a throughput and blast-radius trade-off, not a token, secret, privilege or code-injection path.
• Controls the diff leaves unchanged:
  • merge.require-verifier-verdict: true (line 969).
  • The merge queue testing each entry against the latest base plus the entries ahead of it (lines 971-972).
  • ci-status gating, and the other merge holds.
• Fail-closed behaviour: the policy reader rejects a value that is not a count of 1 or more (babysit_merge_policy.py:902). The schema accepts an integer with a minimum of 1, so 10 is valid.

I found no widening of who is trusted, of token scope, of the kill switch's reach, or of what untrusted text reaches a lane. The cap guards throughput and quality, not a security boundary, so it does not meet the CRITICAL bar and is not reported as a finding. I did not consult the instruction exception register because nothing in the diff deletes or softens an instruction.

Spend: this change draws only on prepaid API credits and subscription usage, since more lane runs and review runs fit in each verification cycle. It is not a hold and not a counted finding.

Manifests: the diff touches no plugin manifest.

Embedded directives: the PR context has none.