Work moves through seats on the mesh, lands in combined tops, and every checkout is kept current

167. Work moves through seats on the mesh, lands in combined tops, and every checkout is kept current

Context

ADR 0101 made integration one typed subsystem that lands one pull request per run of the required check, and listed batches among the alternatives it rejected: "They remain a person's decision, not the executor's." ADR 0155 recorded the owner spending the branch protection for a named lander, one landing at a time, pinned to a judged head.

By the morning of 2026-10-16 more than a hundred pull requests were open (107 at 09:10Z), nine or more sessions worked the repository at once on one machine, and three defects of the practice were measured rather than argued:

The owner answered the sessions that morning. The words, as written to them, in Czech, with an English reading beside each:

• "strasne rychle odbavovat milestones/issues/waves, deploy+bump+vv often, from now always, use majordomus mesh" (clear milestones, issues and waves very fast; deploy, bump and the rest often, from now on always; use the Majordomus mesh).
• "rozdelte si to, spolupracujte a at to odsejpa" (split the work between you, cooperate, and make it move).
• Asked whether to land combined tops or one pull request at a time: combined tops; and a standing approval for pinned admin merges, gh pr merge <n> --admin --merge --match-head-commit <sha>, only when that exact head's ci concluded success and the head contains the current origin/master.
• "moje rozhodnuti je vzdy vse updatovat, rebasovat, force-forward, whatever helps, document it, describe it (gh pages / official pages / ui) a pokracuj s puvodnim planem" (my decision is always to update everything, rebase, force forward, whatever helps; document it, describe it on the published site and in the UI, and continue with the original plan).
• "vse derived, inferred, generic, generated, dynamic, enforced for future" (everything derived, inferred, generic, generated, dynamic, and enforced from now on).

Decision

The practice in force is rule project.the-cooperation-model-is-the-owners-word. It is the one record of it: the integration, mesh and release documents point at the rule rather than restating it, the site renders the rule and this decision from these files, and the Mesh screen of the UI (/ui/mesh) draws who holds each seat from the live claims of the mesh, never from a list of names.

1. Seats are mesh claims. A seat is held by holding its exclusive claim on the mesh, and nothing else makes a session a seat. The landing seat holds campaign/<campaign>/landing while it lands; the release seat holds release/seat; a repair lane holds refs/heads/<branch> for each branch it brings current; a worker holds the paths of its one issue. Because the seat is the claim, it moves when the claim moves, a crashed holder's seat expires with its heartbeat, and the UI reads it from mesh.state rather than from anybody's memory.
2. Combined tops. The landing seat may land many pull requests in one run of the required check: master plus the heads of pull requests that conflict with nothing in authored paths (decided by a chain of git merge-tree), derived files regenerated once after the merge commit, one validation run judging every member, a red member dropped and fixed on its own branch, and one pinned merge landing the top, after which the forge marks every contained pull request merged. A release's bump may ride inside a top.
3. Always current. A stale checkout or branch is brought current without asking anyone, after what it holds is preserved: git stash create and git update-ref refs/rescue/<name> for uncommitted work, a patch under <repository>-rescue/ for anything else. A checkout or a branch nobody else has fetched may be reset, rebased or fast-forwarded; a pushed branch is brought current by merging master into it and pushing a fast-forward.
4. Release often. The release seat cuts a release whenever master holds landed work past the last tag, not once per milestone, and verifies what the site serves afterwards.

What this amends

ADR 0101's executor is unchanged: majordomus prs drain still lands one ready pull request at a time, never passes --admin, and holds its lease while it acts. What changes is the lander's own act. ADR 0101 left batches to a person; the owner has made that decision, so a combined top is no longer a hand-built exception but the landing seat's ordinary unit of work. ADR 0155's clause "one landing at a time" now reads: one landing seat at a time, and a landing may carry a whole top.

What still holds

• Every decision is taken against the current origin/master and the head SHAs it names, and is acted on only while they still hold; --match-head-commit refuses a head that moved.
• --admin is passed only pinned to a head whose ci concluded success and which contains the current master: the protection is spent on a judged tree, never to skip a check.
• No check, hook or gate is disabled, skipped or edited to land; --no-verify is never used.
• A release is never expedited: a tag is pushed only on a commit whose ci succeeded (scripts/ci/release-verdict).
• No pushed branch is force-pushed. The owner's "force-forward" is read as "bring it forward by whatever helps"; on a branch other sessions and the forge read, what helps is a merge, because a rewritten remote head cannot be recovered by the rescue ref of the session that rewrote it.
• Evidence is recorded for each decision: the master and head a top was built from, its members, the run that judged it, and the commit production serves after it.

Consequences

Throughput is no longer bounded by one pull request per run: a top of twenty members costs one run. A top's red is attributed by its jobs to a member, which is dropped and fixed on its own branch, so the attribution ADR 0101 protected survives at the cost of one more run per red member.

Combined tops are still assembled by the landing seat's own procedure, not by a capability of the executor; the typed prs compose that would record a top's members as a manifest never landed. Until it does, the record of a top is its pull request: its body names the members and their heads, and its merge commit's parents are master and the top.

Three enforcement points are carried by other workers and are named by the rule as they land: a new worktree starts from the remote trunk rather than a stale local master; start makes sure the checkout's server runs before a task begins; and a checkout that has fallen behind is detected and brought current.

Alternatives rejected

• Keep one pull request per run. Measured on 2026-10-15 and 16: the queue outgrew it.
• Name the seats in a document. A list of sessions is stale the moment one reconnects; the claim is already the fact, so the UI reads the claim.
• Force-push stale branches. It is fast for the session that does it and destroys work another session pushed in the meantime; a merge of master costs one commit.