Delivery modes & merge authority
How each project ships (no-mistakes, direct-PR, local-only, prod-only), what +yolo does and doesn't allow, branch prefixes, and the Gerrit forge binding.
Every project has a delivery posture recorded in data/projects.md. It answers two separate questions:
- How does work reach the project? That is the mode.
- Who approves landing it? That is the merge authority: you by default, or the first mate under
+yolo.
The registry line#
bin/fm-project-mode.sh parses lines of this shape:
- <name> [<mode> +yolo branch=<prefix> forge=gerrit] - <description> (added <date>)
bin/fm-project-mode.sh xyz # → "no-mistakes off"
bin/fm-project-mode.sh --branch-prefix xyz # → "fm/"
bin/fm-project-mode.sh --forge xyz # → "none" | "gerrit"
bin/fm-project-mode.sh --raw xyz # keeps "no-mistakes-prod-only" uncollapsed
You rarely edit this by hand. Say "set xyz to direct-PR" or "give xyz yolo", and the first mate updates it through the project-management skill.
Modes#
no-mistakes — the rigorous default#
The worker commits on its ship branch and pushes to the local no-mistakes gate. It then drives the nine-step pipeline (intent → rebase → review → test → document → lint → push → pr → ci) through to a green PR. It answers gates but never passes --yes. It reports done: PR <url> checks green. See no-mistakes.
This is the safe fallback: an unregistered project resolves to no-mistakes with yolo off, and the gap is surfaced to you.
direct-PR — fast path#
The worker pushes its branch and opens a non-draft PR itself (via gh-axi), with no pipeline, and reports done: PR <url>. A deliberately held draft reports paused: instead of done:.
local-only — no remote#
The worker stops with a clean ship branch and reports done: ready in branch <branch>. After approval, the first mate runs bin/fm-merge-local.sh <id>. That is a guarded fast-forward of the project's local default branch, and the only git write the first mate itself makes inside projects/. It refuses divergence and tells you to have the crewmate rebase.
no-mistakes-prod-only — per-task choice#
This is a registry classification. The project-management skill makes it the default suggestion for a new remote-backed project. At intake the first mate classifies each task by its surface:
- Internal-only tooling, automation, contributor process or release work ships
direct-PR. - Product-facing, mixed or uncertain work ships
no-mistakes.
"Never infer internal-only from file location or project name."
Kun's rule of thumb for when you need no-mistakes
you can ask yourself 'would i ask another human to do code review for this change' and if the answer is no, then you probably don't need no-mistakes. — @kunchenguid, 2026-09-22
+yolo — standing merge autonomy#
+yolo is orthogonal to mode. It changes only who approves landing.
| yolo off (default) | yolo on | |
|---|---|---|
| Green, in-scope PR | waits for your word | first mate merges it |
| Local-only landing | waits for your word | first mate lands it |
| Red PR or unreported required check | never merged | never merged |
| Destructive / irreversible / security-sensitive | escalates | still escalates |
| Scope | — | "exercised only within the captain's original request, and it never quietly widens" |
Only your current explicit instruction can merge past a red required check, and only when it names the check (fm-pr-merge.sh --allow-red <check>).
Away mode is a separate grant. While you are /afk, a PR green at its live head may merge under away authority. Destructive actions still cannot be pre-authorized. See Daily commands.
branch=<prefix>#
This overrides the default fm/ prefix for ship branches in that project, for example branch=kun/. The brief records a Ship branch: line, and fm-spawn.sh cross-checks it against its arguments to catch drift.
forge=gerrit#
This binds the project to Gerrit instead of GitHub PRs:
- The worker publishes a change with
gerrit-axi publish --squash --jsonand reportsdone: PR <change url> published for review. fm-pr-merge.shrefuses Gerrit outright. Submitting would require faking an attributed human Code-Review+2. A human reviewer submits the change server-side.forge=gerritwithlocal-onlyis rejected, because local-only publishes nothing.
GitLab merge requests work through the ordinary PR path (see docs/gitlab-merge-watch.md).
Precedence, in one list#
- Your current, explicit, concrete instruction ("ship this one direct-PR"). It wins, "exactly as stated and no further".
- The project's registry entry, which is the standing posture.
- The safe default:
no-mistakes, yolo off.
Ambiguous scope or a conflict still gets one concise clarifying question before action.