Most merge queues are a service beside a forge. A change waits on a server, a bot rebases it, and the result comes back as a comment on a review page. mq is a merge queue that runs where the developer works. mq land replays a branch on its target, runs the target's checks on the replayed tree, and fast-forwards the target to the tree that passed, on a laptop with no network. It lands into one repository. A repository names the ones it builds with in its own tree, and a change across several lands each half through its own repository's queue, the dependencies first (Several repositories).

These pages specify the product as it should be, and the binary does not implement all of it yet.

The design rests on three choices. The unit of work is a Git branch, and its name is the only name a user types. State is kept where Git keeps it, so Git's own tools show what mq shows. Each command name says what mq does, and takes a Git word only when Git's behaviour carries over.

The pages #

Page	What it specifies
rules.md	The two definitions (a check, a checked tree) and the nine rules behind every name and every output.
delivery.md	The path one change takes at full speed, as commands: what a land waits on, what each check costs, batches and their bisection, the traps, the install and a second machine.
install.md	How a queue that serves mq's repository builds, installs and rolls back the mq it runs, from its own checked branch.
commands.md	Every command, with its arguments and flags.
outcomes.md	The block a command prints, with the nine outcome words and the exit codes.
runs.md	Who runs the checks: the `land` that needs them, or the operating system's scheduler.
conflicts.md	A conflict, resolved by a command or left in the worktree as a Git rebase.
branches.md	What a land leaves behind, the pool of worktrees, a branch based on another, and waiting for a later branch.
machines.md	How several machines work offline, reconcile by replay on pull and share their check results.
web.md	The dashboard `mq web` serves: its readers and their journeys, its pages and the question each answers, where each figure comes from, its client and visual system, its API, its transports and who may read, its live updates, what a peer can make it spend, and its slices.
teams.md	Teammates, forges and peers, and how a release is made.
configuration.md	The rules on the branch `mq/config`, and one machine's own keys.
trust.md	What `mq` records about who did what, what it trusts, and the Git mechanisms that bound that trust.
sessions.md	Worked sessions, from `mq init` to a release.
naming.md	Every command with its naming verdict.
invariants.md	The invariants no command may weaken.
convergence.md	Each node of the DAG as a set of changes, and what each piece of state merges as.
refs.md	The state: each fact's one place (Git for what synchronises, the journal for events, one SQLite index per schema identity, `index.N.db`, derived from both), the refs, what the index holds, the check results, the two proofs, and the decision record with the workflows walked through.
related-work.md	The state of the art: each queue's algorithm, guarantees and failure modes, affected targets and flaky checks, the questions they put to mq, and the source of each claim about another tool.
reproduction.md	Murmuration's evaluation and numbers, the reproduction mq asks of its order on the queue's machine, the departures, and what is not measured yet.
design.md	The design every module answers to (one place per fact, one engine over Git and the index, the run as a bounded round, one dependency graph, merges where replicas meet), where the code stands, then the implementation: its layers, its modules, recovery, tests and open choices.

A newcomer reads sessions.md, then delivery.md, commands.md and outcomes.md. Whoever implements a command reads rules.md and invariants.md first, then design.md, then the page of its topic.