Gates, stated plainly

A gate stops a change or a call that should not go through. This page lists the gates Muster documents: how a pull request merges, what evidence CI gives, how review works, what guards an agent, and what is recorded.

The merge gate

This is how pull requests reach main in the Muster repository itself. An agent opens a pull request with an issue key in the title. Nothing else merges to main: no manual merge and no queue comment.

A new push makes the approval stale, so the review must approve the new head again.

Wait for the checks. Branch protection requires one check, CI: Result, which needs every other job.
A reviewer run reads the head commit. When it finds no blocker, the review app approves that head.
The merge queue acts on that approval. It needs one approval, an issue key in the title, base main, no draft and no conflict.
The queue builds a draft pull request on current main and runs every job again. Only a green draft merges, so two pull requests that are each green alone cannot turn main red together.

A pull request in conflict gets the label needs-rebase and a comment. A major version bump from a dependency bot matches no queue rule, and the owner merges it by hand.

CI evidence

Each required check is one job named for its cause, and it fails alone. These are the main ones.

Job	What it checks
Go: Build, Go: Vet	one go command each
Go: Unit Tests	every package once, no database
Go: Integration Tests, Go: Race Tests	sharded, each package run with a throwaway database
Repo: Inspect Rules	the repository rules, such as import rules and budgets
Docs: Format and Structure	the docs rules for every Markdown file
Security: Vulnerability Scan, Secret Scan	one go command each
Go: Coverage Floors	floors per package, and 90 percent of changed lines covered
CI: Annotations	fails the run if any check carries an annotation
CI: Result	needs every job and fails when any one is not a success

No run may carry an annotation of any level, and the fix is always the cause, never a filter. Every job runs on the runner the repository names, with no fallback to a hosted runner. The inspect tests keep these rules.

Review

The reviewer is a read only role. Its verdict is an event, for example review_verdict with changes_requested.

A reviewer is not seated while the pull request is merged or closed, conflicts, or has running checks.
After three changes requested verdicts since the last approval the ticket escalates once and gets no more seats, until an operator releases it. The cap is a setting.
A pull request over 800 changed lines, unapproved, goes back to the writer with a request to split. The limit is a setting.
A conflicting pull request gets a limited number of writer seats, then the ticket escalates to a person.

The dispatch queue

Waiting tickets are ranked by tier weight, then by how long they have waited, then by ticket id. Before any seat the pass checks a list of rules and names the first one that stops the ticket, such as label_hold, seat_cap or ticket_spend_cap. Each role keeps its share of the seat cap. The ops Dispatch page lists the queue and the newest decisions with their rule.

Guards on agents

The sentry decides every tool call from a policy made on the server. These are some of its rules.

Rule	What it does
`egress-host`	A host off the list is refused. An empty list allows none.
`egress-metadata`	Cloud metadata names and addresses are refused, even when listed.
`protected-path`	Workflow files and the guard's own sources cannot be changed by any role.
`outside-worktree`	A write that resolves outside the worktree is refused.
`role-readonly`	A read only role cannot use a write tool.
`credential-read`	Reads of key, token and environment files are refused.

Every outside system the sentry and the executors reach sits behind a port, so a guard or a limit is written once.

The helm gives an operator four controls on one ticket: hold, lift, retry and cancel run. Each writes one event. There are also all-stop and a spend brake.

Isolation today is a hardened container: a non root user, a read only root, no container socket and a network that denies by default.

Direction: a user space kernel runtime and, when a stated trigger holds, a microVM for stronger isolation.

The workflow owner gate

Secrets live in an environment that allows only the main branch, so a pull request run reads an empty value. A rule fails any workflow that reads a secret without naming that environment. A change to a workflow goes to the owner for review, and any other change goes to the reviewer agent.

Direction: more gating, driven by data

Planned, from approved designs. None of it is shipped yet.

The merge class goes live. Muster already orders a pull request into the queue when its review approved and its checks are done. The design takes each decision class, merge, kill, cleanup and deploy read-back, from shadow to live behind its own flag, with cutover criteria and a rollback. A ticket then closes only with a read-back event from the live system.
Health and meter based gating. A read only CI reader will feed the log, and a meter will compute CI pass rate, flakes, cache hit rate, wall time and merge queue time for each slice: repository, team, role, area, branch kind or runner pool. Green, amber and red thresholds will live in Settings. A crossing will give an order for the action the owner chose: notify, open a ticket, hold a slice, trip a brake for a slice, or none. Each action starts in shadow, and nothing acts by default.

The record of why

Every action leaves a receipt: a trail from the cause to the result.

Every order names the id of the event that caused it, with its rule and an explanation.
The ops explain route returns the chain for one ticket, oldest first: the event, the rule, the order, the explanation and whether it was executed.
The effect log keeps one row per key: attempts, state and last error. A failure writes an effect_failed event.
The tally writes read back events, such as merge_read_back when the forge shows the pull request merged. A ticket closes only on a read back later than the queue order.