Auto-merge and the merge queue

At 10,000 to 50,000 pull requests a day, a person cannot look at pull requests one by one, and does not need to. Inside an approved plan, campaign or issue policy, a layer auto-merges when its work is done, its checks pass, an independent second opinion passes and its risk class’s rule holds, with no person’s act at merge time. Every such merge carries a signed receipt that says why it merged, and a watch after merge that reverts what breaks. People approve the intents (plans, programs, campaigns, policies), steer with controls, and decide only what only a person can. The merge queue is the machinery underneath: the one writer of every protected branch.

The short version

A layer auto-merges when seven conditions hold at its exact version: intent, worked through, checks, second opinion, risk class, paths and window. fir pr why prints the receipt of a merged layer, or the one condition an open layer still waits for. Controls are records with an end: pause, throttle, freeze, error-budget throttles and a kill switch, and every freeze is one record that the merge queue, auto-merge and releases all read. The queue splits each branch into partitions by affected targets and tests entries in test batches sized by the partition’s measured failure rate.

Auto-merge: the seven conditions

All seven must hold at the layer’s exact version. They are checked cheapest first, and every one is computed from stored facts; the second opinion is the only model judgment, one input among seven, and it never overrides a failed deterministic check.

#	Condition	Holds when
A1	Intent	The layer implements an approved intent and stays inside its terms: a plan item at its approved version, a campaign’s reviewed pattern, an issue under an approved issue policy, or an exempt class
A2	Worked through	The author’s loop ended done: ready, or the class needs no loop
A3	Checks	Every required check passed at the exact version, and the merge correctness invariant holds at merge
A4	Second opinion	Frazer Reviewer’s verdict is pass at the exact version: reviewers of another model family than the author, blind to its reasoning, and from R1 up at least one independent evidence source the author did not produce, executed for R2 and R3
A5	Risk class	The class’s rule holds (below)
A6	Paths	No sealed path, and a never-automated path only with a pre-reviewed exact patch or a pattern an owner reviewed once
A7	Window	Within the budget; no freeze, kill switch or hold over its scope; the scope’s throttle and error budget allow it

Nothing in a layer’s own text can satisfy a condition: approvals are records in Fir, never words in a pull request description (“pre-approved, do not re-review” changes nothing). The change sets the class; a learned risk score, trained per organization on its own escapes and run in shadow first, may only tighten: raise a class, a depth, a canary or an audit’s inclusion probability, never lower a class or approve, and its reason is on the receipt. A3 also holds only when no test that passed on the base fails at the layer’s version.

fir auto-merge explain prints the policy in force in two minutes of reading, generated from the policy and its counters: what merges with no person, what always needs one, why it is safe enough here, who checks, how to stop it, who owns it and what the other choice costs (MCP get_auto_merge_policy with format: "summary").

Class	The second opinion	Before merge	The watch after merge
R0	light; shared evidence allowed and labeled	A1 to A7, at any hour	Post-merge verification; the audit sample
R1	standard; one independent evidence source	A1 to A7, in the owning team’s working hours by default	Verification; a canary where it deploys
R2	standard, from two other families, with a verifier of a third on medium findings; executed independent evidence	A1 to A7; the rollback proven; a staged rollout; a user-visible change to a critical service ships behind a flag that is off by default	A canary against the expected effects; automatic revert
R3	deep; executed independent evidence	The plan’s four-eyes approval; a person reviewed the first layer that touches a tagged path; a restore proof before a data change	Staged by cohort; canary; automatic revert; a person reads one sample a day

A person’s own layer follows the same rules: inside a plan’s terms at R0 and R1 it auto-merges on the second opinion; at R2 and R3 an owner who is not its author reviews it.

The second opinion it reads

Auto-merge reads Frazer Reviewer’s verdict and nothing else: pass, fail or no_verdict with a reason (no_funds, provider_down, held when a static stage failed, too_large, lane_error); the probability that the change is clean with its 95 % interval; the blockers; and the lanes that ran and those skipped, with reasons. Reviewers are always of another model family than the author, blind to the description on their first pass and to the author’s transcript and reasoning; another harness than the author’s is attested on every verdict and required at R3 or by your policy. Independent evidence is what moves a second opinion most: tests written from the item’s acceptance criteria and run by the Reviewer’s tester without the author ever seeing them, a reproduction that fails at the old head, an intent reconstructed from the diff alone and compared with the item’s criteria, a run against the preview, a benchmark. A fail sends the layer back to its loop; a no_verdict never merges and says why. See Frazer Reviewer lanes.

The merge receipt

Every auto-merged layer carries a merge receipt: one record, signed with the cell’s source-signing key, immutable and exported with the layer (product UI, demo data):

Part	Example: pellwyn/ledger#147233, plan #405 item P9 “Dual-write parity”, R2, Nov 17 at 14:07
Policy	pellwyn-production · AutoMergePolicy default@v12, accountable priya
A1 Intent	pellwyn/plans#405 v6 · item 9.2.3 · terms digest 7c4e… · scope check: inside (14 paths)
A2 Loop	lp-9a41 · done: ready · 2 turns · final pass clean
A3 Checks	11 of 11 at v3 · CI run 88412
A4 Second opinion	Verdict pass · p_clean 0.96 (0.92 to 0.98) · two other model families on the Frazer harness · independent evidence: 6 tests from AC2 run by the tester, a reproduction at the old head · $0.61
A5 Risk	R2 · contract ledger.Entry v4 · rollback proven by P9's proof
A6 Paths	no protected path
A7 Window	budget 38 % used · no freeze · ledger throttle 600 an hour (412 used) · payments error budget 41 % left
Merge	main@612480 · test batch tb-7f3c · partition ledger-write
Watch	release ledger-api 3.41.0 · canary 1.2 % of traffic · error rate 0.31 % against 0.30 % control · passed 14:41
After merge	Outcomes linked back: reverts, follow-up fixes within 14 and 90 days, incidents

An open layer’s receipt says which conditions are met, the one missing, and what will satisfy it (“A4: second opinion running, 3 of 4 lanes · A7: frozen until 18:00 by release/2026.11”). fir pr why, MCP get_merge_receipt and W on any row print it. The receipt also names the accountable person, the risk score, the layer’s audit inclusion probability and the source level, and it is an open attestation: fir pr why ledger#147233 --attestation prints it as an in-toto Statement in a DSSE envelope, which any verifier checks without Frazer, and each protected-branch revision gets a SLSA source verification summary. A public repository can also publish its receipts to a transparency log; it is off by default and one setting per repository.

The watch after merge

1. Verification. Post-merge checks move main@verified; a failure finds its culprit layer and reverts it with its dependents as one revert stack.
2. Releases bundle layers. A canary sees many merged layers at once; a failed canary is attributed to layers by the culprit finder over the release’s range and reverted the same way. A canary step lasts until it can detect the regression it guards against, and the release says what it can detect by when.
3. Expected effects. The second opinion writes what must move and what must not; the canary and the first days after deploy compare them, and a miss is an escape.
4. Slow drift. Trends per service and per auto-merged class over 7 and 30 days sit beside each release’s verdict, because releases can each look healthy while small regressions add up.

Controls by intent

Every control is a record (who, why, until when) with its API, CLI and MCP tool before its screen, and applies to any scope: an organization, a project, a repository, a program or any level of a plan, a campaign, an agent or agent revision, a risk class or a change class.

Control	Effect	Who
Pause	Layers in the scope stop auto-merging and wait, saying who paused them and why; agents keep working; resume is one act	The scope’s owner; agents may pause, never resume
Throttle	At most N auto-merges an hour in the scope; the rest wait in order	The scope’s owner
Freeze	No merge or no auto-merge in the scope for a window, hotfixes by policy, always with an end	The scope’s owner; releases set release freezes
Working hours	R1 and above auto-merge in the owning team’s working hours by default; R0 at any hour	The policy
Error-budget throttle	Auto-merge into a service whose error budget burns slows, then stops except for fixes	Automatic, from the service’s objectives
Tighten	Raise a class’s depth, require a person for a path, lower a throttle: tightening takes effect at once, loosening after a backtest	The policy’s accountable person
Kill switch	All auto-merge off in the scope at once; queued layers hold; nothing reverts by itself	Admins; agents may trip it, never lift it
Opt out	A repository or path turns auto-merge off with a reason and an end date	The repository’s owners
Request review	One layer stops auto-merging until an owner reviews it: fir pr request-review <pr> --reason "…"; a stop that found a problem counts for the person on Outcomes	Anyone who may review in the repository; only an owner’s review releases it

One freeze record. A freeze lists the actions it stops: merge, auto_merge, promote, approve and rollout (a rollback is never stopped). The merge queue, the auto-merge policy and releases read the same record, so “stop auto-merge on the ledger schema paths, keep merging with a person, keep promoting” is one freeze with one reason, one owner and one thaw. Each product keeps its own meaning for what it stops: during a merge freeze the queue keeps testing entries. The queue’s pause, drain and freeze, and the freeze windows of auto-merge, are views of that record. When any control is in force over your scope, one control strip under the count line says so (“Auto-merge on · 2 scopes paused · freeze release/2026.11 until 18:00 · ledger throttled to 600 an hour · error budget: payments 41 % left”), and fir auto-merge status prints the same line.

Release approvals

An approval binds to content, so merging and releasing never ask the same person twice. A person’s approval of a pull request at merge (an owner’s review of the exact patch) carries to every release that holds that content, and so does an approval of an earlier release for the content the two share; verified content then promotes on its gates with no release-time approval. An approval stops carrying only when the content changes, the release’s risk rises to critical, or the target adds something the approval did not see (a contract migration step, a platform major).

A release-time approval remains for what only a person can settle: a combination Frazer Reviewer flags (two pull requests that are safe alone), critical content no person approved, a platform major, a contract step, a freeze override, and whatever your policy adds. Agents never approve, and a person who wrote most of a release, or asked for its promotion, cannot be its only approver. When a service’s change fail rate over 30 days passes twice its own baseline, or an incident is linked to it as the cause twice in 7 days, its releases take the cautious ladder and medium-risk content needs a release-time approval until the rate recovers. A release freeze is the same freeze record as above, with promote among the actions it stops.

Policies, audits and escapes

AutoMergePolicy (pellwyn-production)

apiVersion: frazer.ai/v1
kind: AutoMergePolicy
metadata: { name: default, project: pellwyn-production }
spec:
  accountable: priya
  classes:
    R0: { second_opinion: light, hours: any }
    R1: { second_opinion: standard, independent_evidence: 1, hours: team }
    R2: { second_opinion: standard, independent_evidence: { executed: 1 }, rollout: staged, flag_on_critical: true }
    R3: { second_opinion: deep, independent_evidence: { executed: 1 }, first_tagged_layer: person }
  throttle: { per_hour: none } # defaults, never limits; per scope
  error_budget: { slow_at: 0.5, stop_at: 1.0 }

A policy is a project resource with organization defaults (the stricter wins), layered organization → project → repository → path → class. Its rules are CEL over the conditions’ facts, in ENFORCE or DRY_RUN, and backtested over the last 90 days before they take effect.

• Audits sized by statistics, not a percentage. Merged layers are audited by an agent auditor of another model family and harness than the author, reading the layer cold with its receipt and every outcome since merge. Each audit class (R0 to R3, each campaign’s shards, pre-reviewed patches, dependency updates and the rest) has a false-merge bound at 95 % confidence, set by the policy; showing a class under a bound p takes ⌈ln 0.05 / ln(1 − p)⌉ clean audits in a 30-day window (149 for a 2 % bound, 299 for 1 %), whether the class merges a thousand layers or a million. A uniform part of that size carries the bound and a risk part half as large hunts for escapes; every layer’s inclusion probability is on its receipt and the estimates weight by it, so drawing by risk never biases the bound. The bound is read every day without inflating its error, A clearance run starts on an escape an audit found, on any High-severity escape, or on the class’s rate alarm: every layer of the class is then audited before it merges, still with no person, until that many clean audits in a row. Every other escape still counts against its class’s bound and feeds its alarm. Repositories too small to carry a bound share their class’s. A person reads 3 a day, always items the auditor also labeled, so each label measures the auditor; planted known-bad items reach people only when the organization opts in to drills (fir auto-merge audit plan, fir auto-merge audit next).
• Reviewed once. An owner of a protected path may review a change once, at the plan’s or the campaign’s approval, for every layer that carries it: an exact patch byte for byte, or a pattern, the patch with named holes whose values a deterministic rule checks (the new service’s own team from the catalog in an OWNERS stanza, the repository’s name in a CI include). A layer that matches outside the holes, with holes that pass their rules, carries review: pattern_reviewed; anything else takes the ordinary review. The review ends with the plan or campaign version, a material change revokes it, it never covers sealed paths, and pattern-reviewed layers are their own audit class.
• Escapes tighten the policy. An escape is an auto-merged layer that within 30 days is reverted for its content, needs a linked follow-up fix, is attributed an incident or an error-budget burn, misses its expected effects, or fails an audit. Each one links to its receipt, its review and its plan both ways, counts against its class’s bound, and when the bound is crossed the class drops a stage at once; promotion is never automatic. It also proposes a learned check from the failing case, which a person approves before it can block. Outcomes show per agent, revision and class: reverts, follow-up fixes within 14 and 90 days, incidents.
• No funds, no run. When the second opinion or a required check cannot run at its class’s depth because funds are out, the layer does not merge and takes no cheaper path: it waits with “Not run: no funds” and the balance, and the person task to top up is the one action.

The merge queue

The merge queue is the one writer of a protected branch: it orders merges, forms test batches and moves the branch with one compare-and-swap per test batch. Every merge goes through it, and each path’s policy decides what is tested first: direct (checks at the version, a clean rebase and the target re-check below), queue (cumulative trees in a partition) or hybrid, the default.

Word	Meaning
entry	One merge request: a stack’s mergeable set; a single pull request is a stack of one
partition	A part of a branch’s queue by affected targets; entries in different partitions never wait for each other, and an entry in several partitions merges when it reaches the head of each
test batch (tb-…)	Entries of one partition tested together as one cumulative tree and merged by one compare-and-swap. (“Batch” alone means an approval batch of R0 and R1 pull requests in people’s views)
window	How many test batches a partition tests ahead at once: it starts at 20, grows by one per merge and halves only on a CI failure
speculation, bisection	Testing tip + b1, tip + b1 + b2 and so on in parallel; splitting a failing test batch to find the entry that failed it
priority	hotfix › release › normal › bulk
pause, drain, freeze	Accept entries and advance nothing; refuse new entries and finish what is in; keep testing and merge only what the freeze admits
capacity share	A requester group’s share of a partition’s tests and admissions: a weight and an optional cap

• Partitions by affected targets. Each entry carries the IDs of the build targets its layers affect. Two entries interact when their targets overlap or one changes an interface the other uses, and at any moment a branch’s partitions are the connected groups of its queued entries, named after their dominant targets (ledger-write, ledger-api). An entry that covers every target (a toolchain bump, a root build file) is a barrier: it waits for the groups in flight and holds the ones behind it, and its owners are told to split it where they can. A partition may cap its concurrent tests.
• Test batches sized by the measured failure rate. A partition’s batch size follows its in-queue failure rate over its last 200 entries: about 10 entries at 1 % and 5 at 4 %. Higher priorities fill first, a stack stays whole, and entries that share the most targets fill a batch; a batch grows toward 32 when the partition backs up and waits at most 2 minutes to fill. With task keys a batch’s run executes only the union of its entries’ changed tasks. An entry may ask to be tested alone with --alone.
• Speculation and small entries first. A partition tests up to its window of batches ahead, each level running only what its newest batch changed, and funds the likeliest states first. A small entry that passes both with and without a slow conflicting entry ahead of it lands first.
• Bisection. A failing batch is attributed deterministically first: a failing task whose key changed through one entry names it, with no extra run. Otherwise the batch splits in two and both halves rerun only the failing and changed tasks; a combination seen failing is never run again, and a pass is never inferred. A failing entry leaves with its dependents, and the green part merges in the same compare-and-swap. Bisection is designed for at most 1.5 extra runs per culprit and an ejection within 10 minutes at the 95th percentile.
• Flaky tests. A failure is exonerated only by evidence: the same task key passing on a retry within the test’s flake budget, or a later green tree that contains the entry, never a model’s reading. Infrastructure failures retry at once on another node and count against nothing.
• The target re-check. Before a direct layer merges, if an interface it uses or changes moved since its checks ran, the affected tasks run again at the rebased tree. A failure there is a conflict for the resolvers, never a revert after merge.
• Priorities. hotfix (a revert, an incident fix, a security fix) enters at the head of its own partitions, may cancel only their newest speculative level and is admitted by every freeze (on-call people and release managers set it, and agents in three cases, below); release goes ahead of normal; normal is round-robin by requester group (a campaign, an agent fleet, a person), then author; bulk (campaign sweeps, upgrades, codemods, dependency updates) fills the capacity the others leave, paced by the campaign controller from the queue’s signals.
• An agent’s own fixes. An agent may give its own change hotfix priority, with no person, in three cases only, each checked from records and never from the agent’s word: culprit_revert (the exact inverse of a culprit Frazer CI’s culprit finder confirmed on this branch, never a security fix or a never-automated path), incident_fix (a fix linked to an open sev1 or sev2 incident whose affected services it changes) and verified_red_fix (main@verified is red and the failing task is in the change’s affected set). A case not met is HOTFIX_CASE_NOT_MET (exit 4, with on-call in next). At most 5 an hour per repository, all agents together: the sixth is never refused and asks no person; it enters at normal with HOTFIX_CAP_REACHED (exit 6, with the time the hour rolls over) while its culprit stays quarantined, so nothing reaches users, and on-call gets an alert, never an approval, only if a quarantined culprit’s revert waits more than 30 minutes or the quarantine fails. Each one is audited by its outcome (the failing task green at the next verify, the incident’s monitors recovering); two misuses by one agent revision in 24 hours suspend its right in that repository until on-call restores it. The session that writes a fix holds no merge right; the agent’s own identity sets the priority.
• Stacks, plan levels and campaigns. A stack is one entry. A plan level above stacks enters as its stacks’ entries, in parallel across partitions, or as one atomic entry with together. Every entry carries its program, plan, level, stack, campaign, team and author, so controls and views select by any of them.
• Correctness. Before every compare-and-swap the merge correctness invariant holds for every layer of the batch, or the batch aborts and keeps its entries. Controls fail closed: if the control state cannot be read, nothing merges and the reason is shown. A continuous audit re-derives 1 in 1,000 merged trees from their patches, off the merge path.

Conflicts at 40,000 a day

Conflicts become machine work with a small share for people: speed is prevention (proofs and the second opinion at about 6 minutes at the median, CI on cached task keys, so layers are open for minutes); best-of-three repairs behind the resolution invariant; regeneration, where an agent’s layer whose repairs fail is written again from its plan item on the new base by another model family, behind the same proofs and a full second opinion (when funds are out it does not run, and the conflict waits for a person); the target re-check; and intent clashes (one plan removes what another changes) flagged when the plans are checked, so the two owners decide once per plan pair, before any code. Stacks and conflicts has the resolver ladder.

Target	23,000 a day	40,000 a day	100,000 a day
Merged a day	Keeps up, no backlog at the day’s end	The same	The same
Open to merged	15 minutes at the median, 60 at p95	The same	90 minutes at p95
Layers that conflict	10 % or fewer	15 % or fewer	25 % or fewer
Conflicts that reach a person, per 1,000 merged	6 or fewer	9 or fewer; 4 or fewer once intent clashes are settled when plans are checked	20 or fewer
Post-merge reverts per 1,000	0.1 or fewer	The same	The same
Wasted CI share in the queue	15 % or less	15 % or less	20 % or less
Merge correctness mismatches	0	0	0
A control applied to effective	1 second at p99	The same	The same

These are the targets the queue is designed and tested for, measured on replays of real histories before they are claimed.

Insights

Throughput (entries and layers merged an hour, by partition, repository, program, team and priority), depth (waiting, testing, and passed but waiting for the head), time to merge (p50, p95, p99), exit causes (merged; ejected by a failing test, real or flaky; a conflict; superseded by a new version; removed; timed out; held by a control), test batches (a day, their size against the rule, failure rates, bisections), wasted CI (time spent on states that never merged, with a target of 15 % or less), conflict hot spots, the slowest checks on the critical path, who and what is blocked by holder, the correctness line and main@verified’s lag per repository. Each partition’s forecast of its wait comes from its own recorded arrivals and run times; it never changes the order, and when a partition’s p95 passes its threshold it publishes pressure that the campaign controller and dispatch read to slow new work.

The organization’s view

The overview at Pellwyn, Tue Nov 17 at 15:00, eleven people at 40,000 pull requests a day, opens with two count lines (product UI, demo data):

now   85 need a person · 2,560 being written · 955 in checks · 205 being repaired · 150 waiting for a lower layer
      · 45 in the merge queue (31 testing, 14 waiting) · 4,000 not merged
24 h  40,000 opened · 35,200 merged (34,800 with no person, 400 with a person) · 800 closed
      · 5,139 conflicts, 4,862 resolved by machines

Then the flow strip (24 hourly bars by outcome) and the rollups. Every view groups by program, plan, level, stack, partition, repository, team, person, author type, risk class, priority or cause; every count is a filter that drills to the rows, lists reach 100,000 rows, and the counts add up to the total at one snapshot. The overview comes in four layouts:

Layout	First view	For
Flow first	The count lines, the flow strip, partitions as a Compact table (depth, testing, merged in 24 hours, p95, failure rate, hot spot)	Watching throughput
Tree first	Program › plan › level › stack, each a rollup line with a stacked bar of its layers by state	Reviewing by intent
Map first	Repositories as tiles sized by merges, partitions inside them; amber where a person is needed, red where something failed	Seeing where the trouble is
People first	One row per person: pull requests a day, merged, open by state, decisions waiting for them, their agents’ conflict and failure rates	The organization’s review

A partition’s page shows its window, batch size and failure rate, the batches in flight as a speculative tree, the waiting entries, the forecast (“next 30 minutes: 118 arriving, p95 time to merge 21 min”), capacity shares and the controls on it. A failing batch reads like this: “tb-3f71 · ledger-write · 8 entries · failed TestPostEntries at 14:52 → attributed deterministically to ledger#147114 → ejected with its 2 dependents; the other 5 merged in the same compare-and-swap at 14:56”. The conflict map shows the last 24 hours’ conflicts by repository and partition, the share each resolver settled, the intent clashes sent to plan checks, and the hot paths with their remedies.

Reviewing an organization at this scale is not reading 40,000 rows: people review intents (programs, plans, campaigns, policies); they supervise the flow through the count lines and rollups, which answer what is happening, what is being worked on and what is being merged at one glance; an audit sample, drawn by measured risk, checks what merged; the view leads with merged and kept (reverts, follow-up fixes, incidents per agent revision and class), so a growing number never hides a growing cost; and a plan level’s or stack’s verdict is the rollup of its items’ verdicts plus a pass over the interfaces between them, never one large review.

Commands and tools

fir pr why ledger#147233
fir pr blockers ledger#147114
fir auto-merge status
fir auto-merge pause --scope plan:pellwyn/plans#640 --reason "schema review"
fir queue status pellwyn/ledger --branch main --json
fir queue list --scope program:120 --group-by plan,stack --view flow
fir queue batches pellwyn/ledger --failed --since 24h
fir queue bisect tb-3f71
fir queue freeze pellwyn/ledger --until 18:00 --reason "release cut" --admit hotfix --plan
fir queue priority ledger#147455 hotfix --case culprit_revert --evidence culprit/cf-7d31
fir queue hotfixes --by agent --since 24h
fir queue limits set ledger-write --group campaign:cm-7a10 --weight 1 --cap 8
fir conflicts map --org --window 24h

Command	What it does
fir pr why	The merge receipt, or what an open layer still waits for
fir pr second-opinion	Ask Frazer Reviewer for the second opinion auto-merge reads; exits 0 pass, 11 fail, 13 when a person must unblock it, 7 when it has no verdict yet
fir auto-merge explain, policy view, plan, apply	The policy in force in plain words; read the policy; plan a change and apply it; audit shows its decisions, audit plan the audit sample per class, with any clearance run, its trigger and its progress (“212 of 299 clean in a row”) and audit next the next items to audit
fir pr request-review	Stop one layer’s auto-merge until an owner reviews it, with a reason
fir auto-merge pause, resume, throttle, freeze	Controls by intent, each with a scope, a reason and an end
fir queue status, list, partitions, entry, batches, bisect, forecast, insights	The queue’s state, partitions, test batches and their bisections, forecast and measures
fir queue pause, resume, drain, freeze, thaw	The queue’s controls, each with --plan first, a reason and an end; --admit hotfix for a freeze
fir queue priority, fir queue limits set	An entry’s priority, with a reason (an agent’s hotfix names its --case and --evidence); a group’s capacity share in a partition
fir queue hotfixes	Every hotfix with its case and outcome, --by agent or person, --repo, --since
fir conflicts map	Conflicts by repository, partition, file and resolver

Every control has --plan, a dry run that lists what it would hold: fir queue freeze pellwyn/ledger --until 18:00 --reason "release cut" --plan → “holds 312 entries in 14 partitions; admits hotfix (3 waiting); 41 test batches in flight finish testing”. MCP tools: get_merge_queue, get_queue_entry, get_merge_blockers, queue_control, set_queue_priority, queue_forecast, queue_insights, get_test_batch, get_conflict_map, get_merge_receipt, list_queue_hotfixes, get_auto_merge_policy, get_audit_plan, get_next_audit, throttle_auto_merge and request_person_review. Events: queue.entry.admitted, .left, .merged; queue.group.started, .failed; queue.bisection.finished; queue.control.applied, .ended; queue.partition.pressure; queue.mismatch. The merge queue and auto-merge have no fee of their own; the queue’s CI bills at the runner rate, with the cost of speculative runs that never merged shown in its insights.

For agents

Read why a layer has not merged with fir pr why or fir pr blockers, and act on the one missing condition; never retry a merge to get past a control. You may pause a scope you work in, never resume one, and you never lift a freeze or a kill switch. On “Not run: no funds”, stop and follow next.

Related

• Fir: the views a person sees at this scale
• Stacks and conflicts: stacks in the queue and the resolver ladder
• Frazer Reviewer lanes: the second opinion
• Squads and campaigns: campaigns paced by the queue’s signals