Field guide · learn by doing實戰手冊 · 邊做邊學实战手册 · 边做边学実践ハンドブック · 手を動かして学ぶ실전 핸드북 · 하면서 배우기

MUR Daily Jobs CookbookMUR 日常任務手冊MUR 日常任务手册MUR 日常タスクハンドブックMUR 일상 작업 핸드북

26 hands-on tutorials for the MUR local-first agent platform — agents, workflows, and fleets, from your first mur agent create to N-way parallel merges. Every command is copy-paste ready and sourced from the actual CLI. 26 個 MUR 本地優先 Agent 平台的實戰教學 — 從第一次 mur agent create 到 N 路平行合併，涵蓋 Agent、Workflow、Fleet。每一條指令都可直接複製貼上，並以實際 CLI 原始碼為準。26 个 MUR 本地优先 Agent 平台的实战教程 — 从第一次 mur agent create 到 N 路并行合并，涵盖 Agent、Workflow、Fleet。每一条命令都可直接复制粘贴，并以实际 CLI 源代码为准。ローカルファースト Agent プラットフォーム MUR の実践チュートリアル 26 本 — 初めての mur agent create から N-way 並列マージまで、Agent・Workflow・Fleet を網羅します。どのコマンドもそのままコピー＆ペーストでき、実際の CLI ソースコードに準拠しています。MUR 로컬 우선 Agent 플랫폼의 실전 튜토리얼 26개 — 첫 mur agent create부터 N-웨이 병렬 병합까지, Agent, Workflow, Fleet를 다룹니다. 모든 명령은 그대로 복사해 붙여넣을 수 있으며, 실제 CLI 소스 코드를 기준으로 합니다.

26 jobs任務任务タスク작업 4 difficulty levels個難度等級个难度等级段階の難易度개 난이도 등급 8 parallel patterns種平行模式种并行模式種類の並列パターン가지 병렬 패턴 copy-paste ready指令可直接使用命令可直接使用コマンドはそのまま使用可能명령 바로 사용 가능

Part 0 · Before you start第零部 · 開始之前第零部 · 开始之前第0部 · はじめる前に제0부 · 시작하기 전에

Install & first-run checklist安裝與首次啟動檢查安装与首次启动检查インストールと初回起動チェック설치 및 첫 실행 점검

MUR is a single Rust binary plus per-agent runtimes. Everything lives under ~/.mur/. Five minutes of setup covers every tutorial below. MUR 是一個 Rust 單一執行檔加上每個 Agent 各自的 runtime。所有資料都在 ~/.mur/ 底下。五分鐘的準備就能跑完以下所有教學。MUR 是一个 Rust 单一可执行文件加上每个 Agent 各自的 runtime。所有数据都在 ~/.mur/ 之下。五分钟的准备就能跑完以下所有教程。MUR は 1 つの Rust 実行ファイルに、Agent ごとの runtime を加えた構成です。すべてのデータは ~/.mur/ の下にあります。5 分の準備で、以下のチュートリアルをすべて実行できます。MUR는 Rust 단일 실행 파일에 Agent별 runtime이 더해진 구조입니다. 모든 데이터는 ~/.mur/ 아래에 있습니다. 5분만 준비하면 아래 모든 튜토리얼을 실행할 수 있습니다.

Install, verify, register a model安裝、驗證、註冊模型安装、验证、注册模型インストール、検証、モデル登録설치, 검증, 모델 등록

●○○○setup

# Install via Homebrew, or build from source / 用 Homebrew 安裝，或從原始碼建置
$ brew install mur            # from source: ./install.sh
$ mur --version

# Option A — local model via Ollama (no API key, fully offline)
# 選項 A — Ollama 本地模型（免 API key，完全離線）
$ ollama pull llama3.2:3b

# Option B — cloud model: register it in the model registry (~/.mur/models.yaml)
# 選項 B — 雲端模型：先在模型註冊表登記（~/.mur/models.yaml）
$ mur model add anthropic_opus \
    --provider anthropic --model claude-opus-4-7 \
    --secret env:ANTHROPIC_API_KEY --tier frontier
$ mur model list
$ mur model prices show        # cached models.dev pricing catalog / 快取的價格目錄

The registry entry's --secret accepts env:VAR, keychain:svc/acct, file:/path, or cmd:./script — agents reference the entry via model_ref and never hold raw keys. 註冊表項目的 --secret 接受 env:VAR、keychain:svc/acct、file:/path、cmd:./script — Agent 透過 model_ref 引用，本身不保存明文金鑰。注册表条目的 --secret 接受 env:VAR、keychain:svc/acct、file:/path、cmd:./script — Agent 通过 model_ref 引用，本身不保存明文密钥。レジストリ項目の --secret は env:VAR、keychain:svc/acct、file:/path、cmd:./script を受け付けます — Agent は model_ref 経由で参照し、平文のキーを自身には保存しません。레지스트리 항목의 --secret은 env:VAR, keychain:svc/acct, file:/path, cmd:./script를 받습니다 — Agent는 model_ref로 참조할 뿐, 평문 키를 직접 보관하지 않습니다.
mur model add auto-fills pricing + context window from the models.dev catalog unless you pass --no-fetch. 除非加 --no-fetch，mur model add 會自動從 models.dev 目錄補上價格與 context window。除非加 --no-fetch，mur model add 会自动从 models.dev 目录补上价格与 context window。--no-fetch を付けない限り、mur model add は models.dev カタログから価格と context window を自動補完します。--no-fetch를 붙이지 않는 한, mur model add는 models.dev 카탈로그에서 가격과 context window를 자동으로 채웁니다.

MUR_HOME gotcha: every path in this guide assumes the default data root ~/.mur. The MUR_HOME env var overrides that root — if you set it, set it everywhere (shell profile, launchd/systemd services, cron): any process that misses the override reads and writes a different root, and your skills, fleets, and channels silently split across two homes.MUR_HOME 陷阱：本手冊所有路徑都假設預設資料根目錄 ~/.mur。環境變數 MUR_HOME 會覆蓋這個根目錄——一旦要設就到處都設（shell profile、launchd/systemd 服務、cron）：漏掉覆蓋的行程會讀寫另一個根目錄，你的 skill、fleet 與 channel 就會默默分家在兩個 home 裡。MUR_HOME 陷阱：本手册所有路径都假设默认数据根目录 ~/.mur。环境变量 MUR_HOME 会覆盖这个根目录——一旦要设就到处都设（shell profile、launchd/systemd 服务、cron）：漏掉覆盖的进程会读写另一个根目录，你的 skill、fleet 和 channel 就会默默分家在两个 home 里。MUR_HOME の落とし穴：本ガイドのパスはすべて既定のデータルート ~/.mur を前提としています。環境変数 MUR_HOME はこのルートを上書きします。設定するならすべての場所で（shell profile、launchd/systemd サービス、cron）設定してください。上書きが漏れたプロセスは別のルートを読み書きし、skill・fleet・channel が 2 つの home に静かに分裂します。MUR_HOME 함정: 이 가이드의 모든 경로는 기본 데이터 루트 ~/.mur를 전제로 합니다. 환경 변수 MUR_HOME은 이 루트를 재정의합니다 — 설정한다면 모든 곳에서(shell profile, launchd/systemd 서비스, cron) 설정하십시오. 재정의가 누락된 프로세스는 다른 루트를 읽고 쓰며, skill·fleet·channel이 두 home으로 조용히 갈라집니다.

Heads-up — mur sync writes into your repo: sync injects skill content into AI-tool config files, including AGENTS.md at the repo root. Seeing AGENTS.md modified after a sync is normal MUR behavior — just don’t commit that churn by accident.注意——mur sync 會寫入你的 repo：sync 會把技能內容注入 AI 工具設定檔，包括 repo 根目錄的 AGENTS.md。sync 之後看到 AGENTS.md 有改動是 MUR 的正常行為——小心別把這些變動誤 commit 進去。注意——mur sync 会写入你的 repo：sync 会把技能内容注入 AI 工具配置文件，包括 repo 根目录的 AGENTS.md。sync 之后看到 AGENTS.md 有改动是 MUR 的正常行为——小心别把这些变动误 commit 进去。注意——mur sync はリポジトリに書き込みます：sync はスキル内容を AI ツール設定ファイル（リポジトリ直下の AGENTS.md を含む）に注入します。sync 後に AGENTS.md が変更されているのは MUR の正常な動作です——誤ってコミットしないよう注意してください。주의 — mur sync는 repo에 기록합니다: sync는 스킬 내용을 AI 도구 설정 파일(저장소 루트의 AGENTS.md 포함)에 주입합니다. sync 후 AGENTS.md가 수정되어 있는 것은 MUR의 정상 동작입니다 — 실수로 커밋하지 않도록 주의하십시오.

Part 1 · Easy第一部 · 入門第一部 · 入门第1部 · 入門제1부 · 입문

Agents — your daily companionsAgent — 你的日常夥伴Agent — 你的日常伙伴Agent — 日々の相棒Agent — 당신의 일상 파트너

A MUR agent is a supervised local process with its own identity (Ed25519), system prompt, model, skills, MCP tools, and OS-enforced sandbox. These seven jobs are the moves you'll make every day. MUR Agent 是受監管的本地行程，擁有自己的身分（Ed25519）、系統提示詞、模型、技能、MCP 工具與作業系統層級的沙箱。這七個任務就是你每天的基本動作。MUR Agent 是受监管的本地进程，拥有自己的身份（Ed25519）、系统提示词、模型、技能、MCP 工具与操作系统层面的沙箱。这七个任务就是你每天的基本动作。MUR の Agent は監督下にあるローカルプロセスで、固有のアイデンティティ（Ed25519）、システムプロンプト、モデル、スキル、MCP ツール、そして OS レベルのサンドボックスを持ちます。この 7 つのタスクが毎日の基本動作です。MUR Agent는 감독되는 로컬 프로세스로, 자체 신원(Ed25519), 시스템 프롬프트, 모델, 스킬, MCP 도구, OS 수준 샌드박스를 갖습니다. 이 일곱 가지 작업이 매일의 기본 동작입니다.

Create your first agent and say hello建立第一個 Agent 並打聲招呼创建第一个 Agent 并打声招呼最初の Agent を作成して挨拶する첫 Agent를 만들고 인사 건네기

●○○○lifecycle

Daily job日常情境日常场景日常のシナリオ일상 시나리오: stand up a personal assistant agent — local or cloud — and confirm it's alive. 建立一個私人助理 Agent — 本地或雲端皆可 — 並確認它真的活著。创建一个私人助理 Agent — 本地或云端皆可 — 并确认它真的活着。個人アシスタントの Agent を作成し — ローカルでもクラウドでも構いません — 本当に生きていることを確認します。개인 비서 Agent를 만들고 — 로컬이든 클라우드든 — 실제로 살아 있는지 확인합니다.

# Local agent (Ollama, zero keys) / 本地 Agent（Ollama，不需金鑰）
$ mur agent create helper --model llama3.2:3b

# Cloud agent (Claude) — TWO steps / 雲端 Agent（Claude）— 必須兩步
$ mur agent create assistant --provider anthropic --model claude-opus-4-7
$ mur agent secret assistant set ANTHROPIC_API_KEY   # hidden prompt → OS keychain

# Start it: run the per-agent runtime symlink, or install a service
# 啟動：執行該 Agent 專屬的 runtime 符號連結，或安裝成系統服務
$ ~/.local/bin/mur_agent_assistant start &
#   …or as a login service (launchd / systemd) / 或裝成登入服務
$ mur agent install-service assistant

# Verify / 驗證
$ mur agent list
$ mur agent status assistant
$ mur agent card assistant          # A2A agent card (JSON)

# One raw A2A turn (JSON message) / 一個原生 A2A 回合（JSON 訊息）
$ mur agent send assistant '{"role":"user","parts":[{"kind":"text","text":"hello"}]}'

Everything lands in ~/.mur/agents/assistant/: profile.yaml (model, tools, entitlements), sys_prompt.md, identity keys, agent.sock. 所有東西都在 ~/.mur/agents/assistant/：profile.yaml（模型、工具、權限）、sys_prompt.md、身分金鑰、agent.sock。所有东西都在 ~/.mur/agents/assistant/：profile.yaml（模型、工具、权限）、sys_prompt.md、身份密钥、agent.sock。すべては ~/.mur/agents/assistant/ にあります：profile.yaml（モデル、ツール、権限）、sys_prompt.md、アイデンティティ鍵、agent.sock。모든 것이 ~/.mur/agents/assistant/에 있습니다: profile.yaml(모델, 도구, 권한), sys_prompt.md, 신원 키, agent.sock.
Agent names are case-insensitive at the CLI (mur agent send Assistant resolves), but the canonical on-disk name is what the runtime enforces. CLI 的 Agent 名稱不分大小寫（mur agent send Assistant 也解析得到），但 runtime 強制使用磁碟上的正規名稱。CLI 的 Agent 名称不区分大小写（mur agent send Assistant 也能解析），但 runtime 强制使用磁盘上的规范名称。CLI の Agent 名は大文字・小文字を区別しません（mur agent send Assistant でも解決されます）が、runtime はディスク上の正規名を強制します。CLI의 Agent 이름은 대소문자를 구분하지 않지만(mur agent send Assistant도 해석됩니다), runtime은 디스크상의 정규 이름을 강제합니다.
mur agent send is a single LLM turn with no tool execution — a probe, not a work order. Real tool use happens in the interactive TUI (job 2) or via workflows/fleets. mur agent send 是單一 LLM 回合，不會執行工具 — 適合探測，不適合派工。真正的工具使用在互動 TUI（任務 2）或 workflow／fleet。mur agent send 是单次 LLM 回合，不会执行工具 — 适合探测，不适合派发任务。真正的工具使用在交互式 TUI（任务 2）或 workflow／fleet。mur agent send は単一の LLM ターンで、ツールは実行しません — 疎通確認には向きますが、作業の割り当てには不向きです。実際のツール使用は対話型 TUI（タスク 2）または workflow／fleet で行います。mur agent send는 단일 LLM 턴이며 도구를 실행하지 않습니다 — 상태 탐침에는 적합하지만 작업 배정에는 부적합합니다. 실제 도구 사용은 인터랙티브 TUI(작업 2)나 workflow/fleet에서 이루어집니다.

Gotcha: a cloud agent whose registry entry has no secret silently degrades to a stub that just echoes — if replies look suspiciously parrot-like, run mur agent secret assistant list and set the missing key. 陷阱：註冊表沒設 secret 的雲端 Agent 會靜默降級成只會回音的 stub — 如果回覆像鸚鵡學舌，跑 mur agent secret assistant list 檢查並補上金鑰。陷阱：注册表没设 secret 的云端 Agent 会静默降级成只会回声的 stub — 如果回复像鹦鹉学舌，运行 mur agent secret assistant list 检查并补上密钥。落とし穴：レジストリに secret が未設定のクラウド Agent は、エコーを返すだけの stub に静かに降格します — 返答がオウム返しに見えたら、mur agent secret assistant list で確認してキーを補ってください。함정: 레지스트리에 secret이 설정되지 않은 클라우드 Agent는 에코만 하는 stub으로 조용히 강등됩니다 — 응답이 앵무새처럼 들리면 mur agent secret assistant list로 확인하고 키를 채워 넣으십시오.

Chat in the terminal — the daily driver終端機對話 — 每天的主力介面终端对话 — 每天的主力界面ターミナル対話 — 毎日のメインインターフェース터미널 대화 — 매일의 주력 인터페이스

●○○○TUI

Daily job日常情境日常场景日常のシナリオ일상 시나리오: open a streaming chat with real tool execution, resume yesterday's conversation, and drive several agents side by side. 開一個支援即時串流與真實工具執行的聊天視窗、接續昨天的對話，並同時駕馭多個 Agent。打开一个支持实时流式输出与真实工具执行的聊天窗口、接续昨天的对话，并同时驾驭多个 Agent。リアルタイムストリーミングと実ツール実行に対応したチャット画面を開き、昨日の会話を再開し、複数の Agent を同時に操ります。실시간 스트리밍과 실제 도구 실행을 지원하는 채팅 창을 열고, 어제의 대화를 이어가며, 여러 Agent를 동시에 다룹니다.

# Interactive chat with tools + HITL approvals / 互動聊天（含工具與人工核准）
$ mur agent cli assistant

# The murmur shortcut / murmur 捷徑
$ murmur                       # bare = the mur concierge / 不帶參數 = 總管 mur
$ murmur pm qa                 # 2+ names = one split pane each (tmux) / 每個 Agent 一格

# Useful flags / 常用旗標
$ mur agent cli assistant --resume            # continue last conversation / 續聊
$ mur agent cli assistant --auto-reads        # auto-approve read-only bash / 唯讀指令自動核准
$ mur agent cli assistant --budget-usd 2      # session cost ceiling / 本次花費上限
$ mur agent cli assistant --skin mur --plain  # skin; line mode for pipes / 佈景；管線用行模式

# Inside the session / 會話中指令
/help          /clear          /sessions       /channels [N]
/auto [on|off] /skin [dark|light|mur]          /card           /quit
/mcp add <name> <command> [args…]   /skill add <path>    # live tool/skill mgmt
!git status    # run locally; output is attached to your next message
               # 在本機執行；輸出會附在你下一則訊息前

--auto approves every tool call for the session — handy for trusted chores, dangerous for anything else. --auto-reads is the safer everyday middle ground. --auto 會核准本次會話所有工具呼叫 — 跑可信雜務方便，其他情況危險。--auto-reads 是日常較安全的折衷。--auto 会批准本次会话所有工具调用 — 跑可信杂务方便，其他情况危险。--auto-reads 是日常较安全的折中。--auto はこのセッションのすべてのツール呼び出しを承認します — 信頼できる雑務には便利ですが、それ以外では危険です。--auto-reads が日常向けのより安全な折衷案です。--auto는 이번 세션의 모든 도구 호출을 승인합니다 — 신뢰할 수 있는 잡무에는 편리하지만 그 외에는 위험합니다. --auto-reads가 일상적으로 더 안전한 절충안입니다.
/channels 3 switches the chat onto channel #3 from the list — you can watch a fleet channel live from inside a chat. /channels 3 會把對話切到清單上第 3 條 channel — 你可以在聊天視窗裡即時看 fleet channel。/channels 3 会把对话切到列表中第 3 条 channel — 你可以在聊天窗口里实时查看 fleet channel。/channels 3 は会話をリストの 3 番目の channel に切り替えます — チャット画面の中から fleet の channel をリアルタイムで見られます。/channels 3은 대화를 목록의 3번째 channel로 전환합니다 — 채팅 창 안에서 fleet channel을 실시간으로 볼 수 있습니다.

Keep and search personal knowledge notes建立並搜尋個人知識筆記创建并搜索个人知识笔记個人ナレッジノートの作成と検索개인 지식 노트 만들고 검색하기

●○○○memory

Daily job日常情境日常场景日常のシナリオ일상 시나리오: capture the deploy checklist you keep re-deriving, then find it (and everything related) by meaning, not filename. 把你一再重新推導的部署檢查表記下來，之後用「語意」找回它 — 不用記檔名。把你一再重新推导的部署检查清单记下来，之后用“语义”找回它 — 不用记文件名。何度も導き直しているデプロイチェックリストを書き留めておき、後で「意味」で探し出します — ファイル名を覚える必要はありません。매번 다시 떠올리던 배포 체크리스트를 기록해 두고, 나중에 "의미"로 다시 찾습니다 — 파일명을 기억할 필요가 없습니다.

# Create a note / 建立筆記
$ mur notes create deploy-checklist -d "Production deploy checklist" --body-file checklist.md
#   (or pipe stdin / 或用stdin)
$ echo "1. tag  2. push  3. verify brew" | mur notes create release-steps -d "Release steps"

# Find things by meaning / 語意搜尋
$ mur notes search "what do I check before deploying"
$ mur notes list --maturity stable
$ mur notes show deploy-checklist

# Unified search across notes + connected sources (Obsidian/Notion/Joplin)
# 跨筆記與外部來源（Obsidian/Notion/Joplin）的統一搜尋
$ mur search "key rotation procedure" -k 5

Notes are knowledge objects with a maturity lifecycle (draft → emerging → stable → canonical) and decay — frequently-used knowledge surfaces first. 筆記是有成熟度生命週期（draft → emerging → stable → canonical）與衰減機制的知識物件 — 常用的知識優先浮上來。笔记是具有成熟度生命周期（draft → emerging → stable → canonical）与衰减机制的知识对象 — 常用的知识优先浮上来。ノートは成熟度ライフサイクル（draft → emerging → stable → canonical）と減衰メカニズムを持つ知識オブジェクトです — よく使う知識ほど優先的に浮かび上がります。노트는 성숙도 수명주기(draft → emerging → stable → canonical)와 감쇠 메커니즘을 가진 지식 객체입니다 — 자주 쓰는 지식이 먼저 떠오릅니다.
The same retrieval pipeline powers automatic context injection into your AI tools — what you save here shows up as ambient knowledge in tomorrow's sessions. 同一條檢索管線也負責自動注入 AI 工具的上下文 — 今天存的，明天的工作階段就會自動出現。同一条检索管道也负责自动注入 AI 工具的上下文 — 今天存的，明天的会话就会自动出现。同じ検索パイプラインが AI ツールへのコンテキスト自動注入も担います — 今日保存したものは、明日のセッションに自動的に現れます。같은 검색 파이프라인이 AI 도구의 컨텍스트 자동 주입도 담당합니다 — 오늘 저장한 것이 내일 세션에 자동으로 나타납니다.

Index the repo, search it by meaning為 Repo 建索引，用語意搜尋程式碼为 Repo 建索引，用语义搜索代码リポジトリをインデックス化し、コードを意味で検索するRepo를 인덱싱하고 시맨틱 검색으로 코드 찾기

●○○○code search

Daily job日常情境日常场景日常のシナリオ일상 시나리오: "where do we validate session tokens?" — ask the codebase in plain language instead of guessing grep patterns. 「session token 是在哪裡驗證的？」— 用白話問程式碼庫，不用猜 grep 的正規表達式。“session token 是在哪里验证的？”— 用大白话问代码库，不用猜 grep 的正则表达式。「session token はどこで検証されている？」— grep の正規表現を推測せず、平易な言葉でコードベースに尋ねます。"session token은 어디서 검증되나?" — 일상 언어로 코드베이스에 물어봅니다. grep 정규식을 추측할 필요가 없습니다.

# Index the current repo (do this after commits) / 建索引（commit 後執行）
$ cd ~/code/my-service && mur project index

# Ask by intent / 用意圖查詢
$ mur project search "where do we validate session tokens" --limit 5
$ mur project search "retry logic for outbound webhooks" --all   # all projects / 跨專案

# Hygiene / 維護
$ mur project status
$ mur project list
$ mur project remove ~/code/old-service     # free disk from stale indexes / 清舊索引

Search is hybrid vector + BM25 — meaning first, keywords as tiebreaker. Use grep for exact strings and exhaustive matches; use this for concepts. 搜尋是向量＋BM25 混合 — 語意優先、關鍵字加權。找精確字串與全面比對用 grep；找概念用這個。搜索是向量＋BM25 混合 — 语义优先、关键字加权。找精确字符串与穷举匹配用 grep；找概念用这个。検索はベクトル＋BM25 のハイブリッドです — 意味を優先し、キーワードで重み付けします。正確な文字列や網羅的な照合には grep を、概念を探すにはこちらを使います。검색은 벡터＋BM25 하이브리드입니다 — 의미 우선, 키워드 가중. 정확한 문자열과 전수 매칭은 grep으로, 개념 검색은 이것으로 하십시오.
The index is a rebuildable cache — deleting it never loses data (mur project index --rebuild). 索引只是可重建的快取 — 刪掉不會遺失任何資料（mur project index --rebuild）。索引只是可重建的缓存 — 删掉不会丢失任何数据（mur project index --rebuild）。インデックスは再構築可能なキャッシュにすぎません — 削除してもデータは一切失われません（mur project index --rebuild）。인덱스는 재구축 가능한 캐시일 뿐입니다 — 지워도 데이터를 잃지 않습니다(mur project index --rebuild).

Teach a skill — knowledge your agents act on教一個技能 — Agent 會照著做的知識教一个技能 — Agent 会照着做的知识スキルを教える — Agent がそのとおりに実行する知識스킬 가르치기 — Agent가 그대로 따라 하는 지식

●○○○skills

Daily job日常情境日常场景日常のシナリオ일상 시나리오: your team's code-review checklist should live in the agent, not in your head. Author it once, install it on any agent, share it safely. 團隊的 code review 檢查表應該住在 Agent 裡，而不是你腦中。寫一次、裝到任何 Agent 上、安全地分享。团队的 code review 检查清单应该住在 Agent 里，而不是你脑中。写一次、装到任何 Agent 上、安全地分享。チームの code review チェックリストは、あなたの頭の中ではなく Agent の中に住むべきです。一度書けば、どの Agent にも装着でき、安全に共有できます。팀의 code review 체크리스트는 당신 머릿속이 아니라 Agent 안에 있어야 합니다. 한 번 작성해서 어떤 Agent에든 설치하고 안전하게 공유합니다.

# Scaffold + edit / 建骨架並編輯
$ mur skill new review-checklist --category context
$ mur skill edit review-checklist        # opens $EDITOR, validates on save

# ~/.mur/skills/review-checklist/skill.yaml — minimal valid manifest
name: review-checklist
version: 0.1.0
publisher: human:peggy
description: What we always check in a code review
category: context            # context | workflow | command | meta | note | media
triggers:
  - type: keyword            # command | keyword | session_start | manual
    pattern: "code review"
content:
  abstract: The five checks every review must pass.
  context: |
    1. Tests cover the change   2. No hardcoded values
    3. Errors are handled       4. Docs updated   5. No secret material

# Install onto an agent / 安裝到 Agent
$ mur agent skill add assistant ~/.mur/skills/review-checklist/skill.yaml
$ mur agent skill list assistant
$ mur agent skill disable assistant review-checklist   # keep files, stop injecting

# Install from a URL — fetched, schema-validated, SECURITY-SCANNED first
# 從網址安裝 — 先抓取、驗證結構、再做安全掃描
$ mur agent skill add-url assistant https://example.com/skills/rust-review.yaml

# Trust a publisher key once (TOFU), later installs auto-trust
# 首次信任發佈者金鑰（TOFU），之後的安裝自動信任
$ mur agent skill trust-publisher <key-fingerprint> --name alice

content takes exactly one mode: context (guidance text), procedure (a runnable DAG — that's a workflow skill, jobs 11–13), command, or note. content 只能選一種模式：context（指引文字）、procedure（可執行 DAG — 即 workflow 技能，任務 11–13）、command 或 note。content 只能选一种模式：context（指导文字）、procedure（可执行 DAG — 即 workflow 技能，任务 11–13）、command 或 note。content はいずれか 1 つのモードだけを選べます：context（ガイダンステキスト）、procedure（実行可能な DAG — すなわち workflow スキル、タスク 11–13）、command または note。content는 한 가지 모드만 선택할 수 있습니다: context(안내 텍스트), procedure(실행 가능한 DAG — 즉 workflow 스킬, 작업 11–13), command 또는 note.
Remote installs are fail-closed: blocking security findings refuse the install unless you explicitly --yes; registry installs verify content hash + publisher signature. 遠端安裝失敗即拒絕：安全掃描發現阻斷性問題就拒裝，除非你明確 --yes；registry 安裝會驗證內容雜湊與發佈者簽章。远程安装失败即拒绝：安全扫描发现阻断性问题就拒装，除非你明确 --yes；registry 安装会验证内容哈希与发布者签名。リモートインストールはフェイルクローズドです：セキュリティスキャンがブロッキングな問題を見つけると、明示的に --yes しない限りインストールを拒否します。registry からのインストールではコンテンツハッシュと発行者署名を検証します。원격 설치는 실패 시 거부(fail-closed)입니다: 보안 스캔이 차단성 문제를 발견하면 명시적으로 --yes를 주지 않는 한 설치를 거부합니다. registry 설치는 콘텐츠 해시와 게시자 서명을 검증합니다.
Skills mature with use (Draft → Emerging → Stable → Canonical) and are injected by relevance — mur skill stats shows how often one actually fires. 技能隨使用成熟（Draft → Emerging → Stable → Canonical）並依關聯性注入 — mur skill stats 可看實際觸發頻率。技能随使用成熟（Draft → Emerging → Stable → Canonical）并按相关性注入 — mur skill stats 可查看实际触发频率。スキルは使用に応じて成熟し（Draft → Emerging → Stable → Canonical）、関連性に基づいて注入されます — mur skill stats で実際の発火頻度を確認できます。스킬은 사용에 따라 성숙하며(Draft → Emerging → Stable → Canonical) 관련성에 따라 주입됩니다 — 실제 트리거 빈도는 mur skill stats로 확인할 수 있습니다.

Wire tools into an agent with MCP用 MCP 幫 Agent 接上工具用 MCP 帮 Agent 接入工具MCP で Agent にツールを接続するMCP로 Agent에 도구 연결하기

●○○○MCP

Daily job日常情境日常场景日常のシナリオ일상 시나리오: give your agent real capabilities — a filesystem server, a remote API with OAuth, tools from the official MCP registry. 給 Agent 真正的能力 — 檔案系統伺服器、需要 OAuth 的遠端 API、官方 MCP registry 上的工具。给 Agent 真正的能力 — 文件系统服务器、需要 OAuth 的远程 API、官方 MCP registry 上的工具。Agent に本物の能力を与えます — ファイルシステムサーバー、OAuth が必要なリモート API、公式 MCP registry 上のツール。Agent에게 진짜 능력을 줍니다 — 파일 시스템 서버, OAuth가 필요한 원격 API, 공식 MCP registry의 도구.

# Local stdio server / 本地 stdio 伺服器
$ mur agent mcp add assistant weather --command npx --arg -y --arg @anthropic-mcp/weather

# Remote Streamable-HTTP server with a bearer token / 帶 bearer token 的遠端伺服器
$ mur agent mcp add-remote assistant myapi https://mcp.example.com --bearer-env MY_TOKEN

# Remote server with OAuth 2.1 (auth-code + PKCE) / OAuth 2.1 登入
$ mur agent mcp add-remote assistant linear https://mcp.linear.app/mcp
$ mur agent mcp login assistant linear

# From the official MCP registry / 從官方 registry 安裝
$ mur agent mcp search "github"
$ mur agent mcp registry-add assistant com.example/github

# Audit & control / 稽核與控制
$ mur agent mcp list assistant
$ mur agent mcp inspect assistant --probe      # drift/pin check / 漂移與釘選檢查
$ mur agent mcp disable assistant weather

# Bonus: give Claude Code MUR's own tools / 反向：讓 Claude Code 用 MUR 的工具
$ claude mcp add mur -- mur-mcp-server

Adding an MCP server auto-syncs its command into the agent's spawn allowlist (processes.spawn entitlement) — agents can only exec what you granted, enforced by the OS sandbox. 加入 MCP 伺服器會自動把指令同步進 Agent 的生成允許清單（processes.spawn 權限）— Agent 只能執行你授權的程式，由作業系統沙箱強制。添加 MCP 服务器会自动把命令同步进 Agent 的生成允许列表（processes.spawn 权限）— Agent 只能执行你授权的程序，由操作系统沙箱强制执行。MCP サーバーを追加すると、コマンドが Agent のスポーン許可リスト（processes.spawn 権限）に自動同期されます — Agent はあなたが許可したプログラムしか実行できず、OS のサンドボックスがそれを強制します。MCP 서버를 추가하면 해당 명령이 Agent의 스폰 허용 목록(processes.spawn 권한)에 자동으로 동기화됩니다 — Agent는 당신이 승인한 프로그램만 실행할 수 있으며, OS 샌드박스가 이를 강제합니다.
MUR's own MCP server exposes 19 read-only tools (notes/project search, compression, agent status, parallel_jobs…) to any MCP client. MUR 自己的 MCP 伺服器對任何 MCP 客戶端提供 19 個唯讀工具（筆記／專案搜尋、壓縮、Agent 狀態、parallel_jobs…）。MUR 自己的 MCP 服务器向任何 MCP 客户端提供 19 个只读工具（笔记／项目搜索、压缩、Agent 状态、parallel_jobs…）。MUR 自身の MCP サーバーは、任意の MCP クライアントに 19 個の読み取り専用ツールを提供します（ノート／プロジェクト検索、圧縮、Agent ステータス、parallel_jobs…）。MUR 자체 MCP 서버는 어떤 MCP 클라이언트에든 19개의 읽기 전용 도구를 제공합니다(노트/프로젝트 검색, 압축, Agent 상태, parallel_jobs…).

Schedule a daily briefing排程每日簡報定时每日简报毎日のブリーフィングをスケジュールする매일 브리핑 스케줄링

●○○○schedule

Daily job日常情境日常场景日常のシナリオ일상 시나리오: at 9:30 every weekday, your assistant should brief you — unprompted. Agent schedules inject a message into the agent on a cron beat. 每個平日 9:30，助理應該主動向你簡報。Agent 排程會按 cron 節拍把訊息注入 Agent。每个工作日 9:30，助理应该主动向你简报。Agent 定时任务会按 cron 节拍把消息注入 Agent。平日の 9:30 には、アシスタントが自発的にブリーフィングしてくれるべきです。Agent スケジュールは cron のリズムに合わせてメッセージを Agent に注入します。평일마다 9:30에 비서가 먼저 브리핑해 주어야 합니다. Agent 스케줄은 cron 박자에 맞춰 메시지를 Agent에 주입합니다.

# Cron-triggered message (5-field POSIX cron) / cron 觸發訊息（五欄位）
$ mur agent schedule add assistant \
    --cron "30 9 * * 1-5" \
    --message "Brief me: yesterday's channel activity, open PRs, today's schedule"

# Manage / 管理
$ mur agent schedule list assistant
$ mur agent schedule next assistant --count 3     # preview next fire times / 預覽下次觸發
$ mur agent schedule remove assistant 0           # by index / 依索引移除

# Idle trigger: nudge after 1h of silence / 閒置觸發：安靜一小時後提醒
$ mur agent schedule idle-add assistant --after-secs 3600 \
    --message "Anything I should pick up while you're away?" --cooldown-secs 7200

This is message injection: the runtime wakes the agent with your text as a normal turn — the agent can then use its tools, message other agents (--sends-to), or notify you via its companion channel. 這是訊息注入：runtime 到點以你的文字喚醒 Agent，當成一般回合 — Agent 可以動用工具、傳訊給其他 Agent（--sends-to），或透過 companion 管道通知你。这是消息注入：runtime 到点用你的文字唤醒 Agent，当作普通回合 — Agent 可以动用工具、给其他 Agent 发消息（--sends-to），或通过 companion 通道通知你。これはメッセージ注入です：時刻になると runtime があなたのテキストで Agent を起こし、通常のターンとして扱います — Agent はツールを使い、他の Agent にメッセージを送り（--sends-to）、あるいは companion チャネル経由であなたに通知できます。이것은 메시지 주입입니다: 시간이 되면 runtime이 당신의 텍스트로 Agent를 깨워 일반 턴처럼 처리합니다 — Agent는 도구를 쓰고, 다른 Agent에게 메시지를 보내고(--sends-to), companion 채널로 당신에게 알릴 수 있습니다.
Contrast with job 10 (workflow schedules, which run a saved procedure) and job 19 (fleet auto-run, which runs a whole squad). 對照任務 10（workflow 排程：執行既存程序）與任務 19（fleet 自動執行：出動整支小隊）。对照任务 10（workflow 定时：执行既有流程）与任务 19（fleet 自动运行：出动整支小队）。タスク 10（workflow スケジュール：既存の手順を実行）およびタスク 19（fleet 自動実行：チーム全体を出動）と比較してください。작업 10(workflow 스케줄: 기존 절차 실행), 작업 19(fleet 자동 실행: 스쿼드 전체 출동)와 비교해 보십시오.

Part 2 · Medium第二部 · 中階第二部 · 中级第2部 · 中級제2부 · 중급

Workflows — repeatable proceduresWorkflow — 可重複的作業程序Workflow — 可重复的作业流程Workflow — 繰り返し可能な作業手順Workflow — 반복 가능한 작업 절차

A workflow is a saved procedure MUR can re-run. Two flavors exist: flat workflows (~/.mur/workflows/*.yaml — simple ordered steps) and workflow skills (category: workflow in ~/.mur/skills/ — a real DAG with parallelism, delegation and approval gates). Jobs 8–10 use the flat kind; jobs 11–13 use the DAG kind. Workflow 是 MUR 可重複執行的既存程序。有兩種形態：扁平 Workflow（~/.mur/workflows/*.yaml，單純的循序步驟）與 Workflow 技能（~/.mur/skills/ 中 category: workflow，真正的 DAG，支援平行、委派與核准關卡）。任務 8–10 用前者，任務 11–13 用後者。Workflow 是 MUR 可重复执行的既有流程。有两种形态：扁平 Workflow（~/.mur/workflows/*.yaml，单纯的顺序步骤）与 Workflow 技能（~/.mur/skills/ 中 category: workflow，真正的 DAG，支持并行、委派与审批关卡）。任务 8–10 用前者，任务 11–13 用后者。Workflow は MUR が繰り返し実行できる既存の手順です。形態は 2 つあります：フラット Workflow（~/.mur/workflows/*.yaml、単純な逐次ステップ）と Workflow スキル（~/.mur/skills/ 内の category: workflow、本物の DAG で並列・委任・承認ゲートに対応）。タスク 8–10 は前者、タスク 11–13 は後者を使います。Workflow는 MUR가 반복 실행할 수 있는 기존 절차입니다. 두 가지 형태가 있습니다: 플랫 Workflow(~/.mur/workflows/*.yaml, 단순 순차 단계)와 Workflow 스킬(~/.mur/skills/의 category: workflow, 병렬·위임·승인 게이트를 지원하는 진짜 DAG). 작업 8–10은 전자를, 작업 11–13은 후자를 사용합니다.

Save a morning-triage workflow and run it建立「晨間巡檢」Workflow 並執行创建“晨间巡检”Workflow 并运行「朝の巡回チェック」Workflow を作成して実行する"아침 점검" Workflow 만들고 실행하기

●●○○workflow

Daily job日常情境日常场景日常のシナリオ일상 시나리오: every morning you run the same three commands to see repo health. Save them once, run them with one command forever. 每天早上你都跑同樣三條指令檢查 repo 狀態。存一次，之後一條指令搞定。每天早上你都跑同样三条命令检查 repo 状态。存一次，之后一条命令搞定。毎朝、同じ 3 つのコマンドでリポジトリの状態を確認しています。一度保存すれば、以後はコマンド 1 つで済みます。매일 아침 같은 세 명령으로 repo 상태를 확인합니다. 한 번 저장하면 이후에는 명령 하나로 끝납니다.

# 1. Author the workflow file / 撰寫 workflow 檔
$ cat > ~/.mur/workflows/morning-triage.yaml <<'EOF'
name: morning-triage
description: Repo health check to start the day
content: Pull, test, and list open PRs every morning
trigger: "when starting the work day"
steps:
  - order: 1
    description: Sync with main
    command: "git pull --rebase"
  - order: 2
    description: Fast test suite
    command: "cargo nextest run --workspace"
    on_failure: abort
  - order: 3
    description: What needs review
    command: "gh pr list --state open"
EOF

# 2. Run it (exact-name match) / 執行（名稱精準比對）
$ mur workflow run morning-triage

# Fuzzy also works — semantic search resolves it / 模糊查詢也行（語意搜尋）
$ mur workflow run "check repo health"

# Inspect what you have / 檢視現有 workflow
$ mur workflow list
$ mur workflow show morning-triage --md

mur workflow run <query> resolves in order: exact name → semantic search (>0.6 similarity) → keyword match → workflow-skill fallback. mur workflow run <query> 依序解析：精準名稱 → 語意搜尋（相似度 >0.6）→ 關鍵字比對 → workflow 技能後備。mur workflow run <query> 依次解析：精确名称 → 语义搜索（相似度 >0.6）→ 关键字匹配 → workflow 技能兜底。mur workflow run <query> は次の順で解決します：完全一致の名前 → セマンティック検索（類似度 >0.6）→ キーワード照合 → workflow スキルへのフォールバック。mur workflow run <query>는 다음 순서로 해석합니다: 정확한 이름 → 시맨틱 검색(유사도 >0.6) → 키워드 매칭 → workflow 스킬 폴백.
Flat steps run sequentially by order; on_failure: abort stops the run, skip continues, retry retries. 扁平步驟依 order 循序執行；on_failure: abort 中止、skip 跳過、retry 重試。扁平步骤按 order 顺序执行；on_failure: abort 中止、skip 跳过、retry 重试。フラットなステップは order に従って逐次実行されます。on_failure: abort は中止、skip はスキップ、retry は再試行です。플랫 단계는 order에 따라 순차 실행됩니다. on_failure: abort는 중단, skip은 건너뛰기, retry는 재시도입니다.
--yes auto-approves steps marked needs_approval: true; --prompt prints the workflow as an AI prompt instead of executing. --yes 會自動核准 needs_approval: true 的步驟；--prompt 則把 workflow 印成 AI 提示詞而不執行。--yes 会自动批准 needs_approval: true 的步骤；--prompt 则把 workflow 打印成 AI 提示词而不执行。--yes は needs_approval: true のステップを自動承認します。--prompt は workflow を実行せず、AI プロンプトとして出力します。--yes는 needs_approval: true 단계를 자동 승인합니다. --prompt는 workflow를 실행하지 않고 AI 프롬프트로 출력합니다.

Tip: prefer mur workflow new for an interactive scaffold (name / description / trigger / steps prompts) if you don't like writing YAML by hand. 提示：不想手寫 YAML 的話，用 mur workflow new 互動式建立（依提示輸入名稱／描述／觸發語／步驟）。提示：不想手写 YAML 的话，用 mur workflow new 交互式创建（按提示输入名称／描述／触发语／步骤）。ヒント：YAML を手書きしたくない場合は、mur workflow new で対話的に作成できます（プロンプトに従って名前／説明／トリガー／ステップを入力）。팁: YAML을 손으로 쓰기 싫다면 mur workflow new로 대화식으로 만드십시오(프롬프트에 따라 이름/설명/트리거/단계 입력).

Harvest yesterday's session into a workflow把昨天的工作階段收割成 Workflow把昨天的会话收割成 Workflow昨日のセッションを Workflow としてハーベストする어제 세션을 Workflow로 수확하기

●●○○memoryharvest

Daily job日常情境日常场景日常のシナリオ일상 시나리오: you just finished a fiddly release procedure in Claude Code. MUR's ambient capture recorded every step — turn it into a reusable workflow instead of re-discovering it next month. 你剛在 Claude Code 完成一套繁瑣的發版流程。MUR 的環境擷取已默默記下每一步 — 把它變成可重用的 workflow，下個月不用重新摸索。你刚在 Claude Code 完成一套繁琐的发版流程。MUR 的环境捕获已默默记下每一步 — 把它变成可复用的 workflow，下个月不用重新摸索。Claude Code で面倒なリリース手順を終えたばかりです。MUR のアンビエントキャプチャがすべてのステップを静かに記録済み — それを再利用可能な workflow に変えれば、来月ゼロから思い出す必要はありません。방금 Claude Code에서 번거로운 릴리스 절차를 마쳤습니다. MUR의 앰비언트 캡처가 이미 모든 단계를 조용히 기록했습니다 — 재사용 가능한 workflow로 바꾸면 다음 달에 다시 더듬을 필요가 없습니다.

# During the important session: pin it so harvest never skips it
# 重要工作階段進行中：標記它，收割關卡就不會略過
$ mur in

# Later (or next morning): review what MUR proposes
# 之後（或隔天早上）：審查 MUR 提出的 workflow 草案
$ mur out
Proposal: "release procedure for mur-core" (14 steps, 38 min)
  ✓ Accept draft workflow   ⏭ Skip   ✗ Quit review

# Accept → saved as a workflow SKILL, runnable immediately
# 接受後 → 存成 workflow「技能」，立即可執行
✓ Skill saved as release-procedure
  edit: ~/.mur/skills/release-procedure/skill.yaml
  run:  mur run release-procedure

# Non-interactive review (scripts/CI) / 非互動審查
$ mur out --action analyze

Ambient capture is always on (hooks record events to ~/.mur/session/recordings/); the harvest gate only proposes workflows from sessions that look valuable — mur in guarantees yours qualifies. 環境擷取隨時進行（hook 把事件寫入 ~/.mur/session/recordings/）；收割關卡只會從看起來有價值的工作階段提案 — mur in 保證你這場入選。环境捕获随时进行（hook 把事件写入 ~/.mur/session/recordings/）；收割关卡只会从看起来有价值的会话提出提案 — mur in 保证你这场入选。アンビエントキャプチャは常時動いています（hook がイベントを ~/.mur/session/recordings/ に書き込みます）。ハーベストゲートは価値がありそうなセッションからのみ提案します — mur in で今回のセッションの選出を保証できます。앰비언트 캡처는 항상 동작합니다(hook이 이벤트를 ~/.mur/session/recordings/에 기록). 수확 게이트는 가치 있어 보이는 세션에서만 제안을 만듭니다 — mur in은 이번 세션의 선정을 보장합니다.
Proposals wait in ~/.mur/inbox/workflow-proposals/ until you review them. Accepting converts the linear steps into a chained DAG skill with volatile literals skeletonized (<STR>, <N>). 提案存放於 ~/.mur/inbox/workflow-proposals/ 等你審查。接受後會把線性步驟轉為串鏈 DAG 技能，並把易變字面值骨架化（<STR>、<N>）。提案存放在 ~/.mur/inbox/workflow-proposals/ 等你审查。接受后会把线性步骤转为链式 DAG 技能，并把易变字面量骨架化（<STR>、<N>）。提案は ~/.mur/inbox/workflow-proposals/ に置かれ、あなたのレビューを待ちます。受け入れると線形ステップがチェーン状の DAG スキルに変換され、変わりやすいリテラルはスケルトン化されます（<STR>、<N>）。제안은 ~/.mur/inbox/workflow-proposals/에 저장되어 검토를 기다립니다. 수락하면 선형 단계를 체인형 DAG 스킬로 변환하고, 변하기 쉬운 리터럴을 스켈레톤화합니다(<STR>, <N>).

Put a workflow on a schedule讓 Workflow 按表定時執行让 Workflow 按表定时执行Workflow をスケジュールどおりに実行させるWorkflow를 일정대로 실행하기

●●○○cron

Daily job日常情境日常场景日常のシナリオ일상 시나리오: run morning-triage automatically at 9:00 on weekdays — no terminal required. 平日早上九點自動跑 morning-triage，不用開終端機。工作日早上九点自动跑 morning-triage，不用开终端。平日の朝 9 時に morning-triage を自動実行します。ターミナルを開く必要はありません。평일 아침 9시에 morning-triage를 자동 실행합니다. 터미널을 열 필요가 없습니다.

# Attach a cron schedule (5-field) / 掛上 cron 排程（五欄位）
$ mur workflow schedule set morning-triage "0 9 * * 1-5"

# Inspect, pause, resume, remove / 檢視、暫停、恢復、移除
$ mur workflow schedule list
$ mur workflow schedule disable morning-triage
$ mur workflow schedule enable morning-triage
$ mur workflow schedule remove morning-triage

On macOS this installs a LaunchAgent (~/Library/LaunchAgents/com.mur.schedule.<name>.plist); on Linux, a crontab line. Both simply invoke mur run <name> at the appointed time and log to ~/.mur/logs/. macOS 上會安裝 LaunchAgent（~/Library/LaunchAgents/com.mur.schedule.<name>.plist）；Linux 則寫入 crontab。兩者到點都是執行 mur run <name>，日誌在 ~/.mur/logs/。macOS 上会安装 LaunchAgent（~/Library/LaunchAgents/com.mur.schedule.<name>.plist）；Linux 则写入 crontab。两者到点都是执行 mur run <name>，日志在 ~/.mur/logs/。macOS では LaunchAgent（~/Library/LaunchAgents/com.mur.schedule.<name>.plist）がインストールされ、Linux では crontab に書き込まれます。どちらも時刻になると mur run <name> を実行し、ログは ~/.mur/logs/ にあります。macOS에서는 LaunchAgent(~/Library/LaunchAgents/com.mur.schedule.<name>.plist)를 설치하고, Linux에서는 crontab에 기록합니다. 둘 다 시간이 되면 mur run <name>을 실행하며, 로그는 ~/.mur/logs/에 있습니다.
Schedules are recorded in ~/.mur/schedules.yaml; if the Commander daemon is running it claims the schedule instead of the OS. 排程記錄在 ~/.mur/schedules.yaml；若 Commander 常駐程式在跑，會由它接手而非作業系統。定时任务记录在 ~/.mur/schedules.yaml；若 Commander 守护进程在跑，会由它接管而非操作系统。スケジュールは ~/.mur/schedules.yaml に記録されます。Commander デーモンが動いていれば、OS ではなくそちらが引き継ぎます。스케줄은 ~/.mur/schedules.yaml에 기록됩니다. Commander 데몬이 실행 중이면 OS 대신 데몬이 넘겨받습니다.

Safety: scheduled runs are non-interactive — keep scheduled workflows read-safe. A step with needs_approval: true can't be approved at 9am with nobody watching. 安全：排程執行沒有互動介面 — 排程的 workflow 請保持唯讀安全。needs_approval: true 的步驟在早上九點沒人看著時是無法核准的。安全：定时执行没有交互界面 — 定时的 workflow 请保持只读安全。needs_approval: true 的步骤在早上九点没人盯着时是无法批准的。安全上の注意：スケジュール実行には対話インターフェースがありません — スケジュールする workflow は読み取り専用の安全なものにしてください。needs_approval: true のステップは、朝 9 時に誰も見ていなければ承認できません。안전: 스케줄 실행에는 인터랙티브 인터페이스가 없습니다 — 스케줄된 workflow는 읽기 전용으로 안전하게 유지하십시오. needs_approval: true 단계는 아침 9시에 지켜보는 사람이 없으면 승인될 수 없습니다.

A real DAG: run independent steps in parallel真正的 DAG：獨立步驟平行執行真正的 DAG：独立步骤并行执行本物の DAG：独立したステップを並列実行する진짜 DAG: 독립 단계의 병렬 실행

●●○○Parallel · DAG fan-out

Daily job日常情境日常场景日常のシナリオ일상 시나리오: lint and test don't depend on each other — why wait? Author a workflow skill whose independent steps run concurrently, then a report step that waits for both. lint 與 test 彼此不相依 — 何必排隊？寫一個 workflow 技能，讓獨立步驟同時跑，最後的報告步驟等它們全部完成。lint 与 test 彼此不依赖 — 何必排队？写一个 workflow 技能，让独立步骤同时跑，最后的报告步骤等它们全部完成。lint と test は互いに依存しません — 順番待ちをする理由はありません。workflow スキルを書いて独立ステップを同時に走らせ、最後のレポートステップで全完了を待ちます。lint와 test는 서로 의존하지 않습니다 — 굳이 줄 세울 이유가 있을까요? workflow 스킬을 작성해 독립 단계를 동시에 실행하고, 마지막 보고 단계가 이들의 완료를 기다리게 합니다.

# ~/.mur/skills/repo-health/skill.yaml
name: repo-health
version: 0.1.0
publisher: human:you
description: Lint and test in parallel, then summarize
category: workflow
content:
  abstract: Fan out lint + test concurrently; report when both finish.
  procedure:
    steps:
      # rank 0 — no depends_on → BOTH run at the same time
      # rank 0 — 沒有 depends_on → 兩個同時開跑
      - id: lint
        description: Clippy over the workspace
        command: "cargo clippy --workspace -- -D warnings"
      - id: test
        description: Fast test suite
        command: "cargo nextest run --workspace"
        on_failure: retry
        retry: { max_retries: 1, backoff_secs: 5 }
        timeout_secs: 900
      # rank 1 — waits for BOTH roots / 等兩個根步驟都完成
      - id: report
        description: Summarize results
        depends_on: [lint, test]
        command: "echo 'repo-health: lint + test done'"

# Run it — same command as any workflow / 執行方式與一般 workflow 相同
$ mur workflow run repo-health

# Cancel siblings on first failure / 首個失敗即取消其他平行分支
$ mur workflow run repo-health --fail-fast

How parallelism works: the executor topo-sorts steps into ranks. Every step with an empty depends_on is rank 0; all steps in the same rank are spawned concurrently and joined before the next rank starts. 平行原理：執行器把步驟拓撲排序成 rank。depends_on 為空的步驟都是 rank 0；同 rank 的步驟同時啟動，全部結束後才進入下一個 rank。并行原理：执行器把步骤拓扑排序成 rank。depends_on 为空的步骤都是 rank 0；同 rank 的步骤同时启动，全部结束后才进入下一个 rank。並列の仕組み：実行エンジンはステップをトポロジカルソートして rank に分けます。depends_on が空のステップはすべて rank 0 です。同じ rank のステップは同時に起動し、全部終わってから次の rank に進みます。병렬 원리: 실행기는 단계를 토폴로지 정렬해 rank로 나눕니다. depends_on이 비어 있는 단계는 모두 rank 0이며, 같은 rank의 단계는 동시에 시작하고 전부 끝난 뒤에야 다음 rank로 넘어갑니다.
Cycles and unknown depends_on ids are rejected at build time with a clear error. 循環相依或不存在的 depends_on id 會在建構期就被拒絕，並給出明確錯誤。循环依赖或不存在的 depends_on id 会在构建期就被拒绝，并给出明确错误。循環依存や存在しない depends_on の id は構築時点で拒否され、明確なエラーが返ります。순환 의존이나 존재하지 않는 depends_on id는 빌드 시점에 거부되며 명확한 오류를 냅니다.
This is single-machine parallelism over command steps. For multi-agent parallelism, see job 13. 這是單機上 command 步驟 的平行。多 Agent 平行見任務 13。这是单机上 command 步骤 的并行。多 Agent 并行见任务 13。これは単一マシン上での command ステップ の並列です。複数 Agent の並列はタスク 13 を参照してください。이것은 단일 머신에서 command 단계의 병렬화입니다. 다중 Agent 병렬은 작업 13을 보십시오.

Gate the risky step behind human approval把高風險步驟鎖在人工核准之後把高风险步骤锁在人工审批之后高リスクなステップを人手の承認の後ろにロックする고위험 단계를 수동 승인 뒤에 잠그기

●●○○HITLchannel

Daily job日常情境日常场景日常のシナリオ일상 시나리오: your deploy workflow should build and verify on its own — but the actual deploy must wait for you to say go. 部署 workflow 應該自己完成建置與驗證 — 但真正的部署動作必須等你點頭。部署 workflow 应该自己完成构建与验证 — 但真正的部署动作必须等你点头。デプロイの workflow はビルドと検証を自力で終えるべきです — ただし実際のデプロイ操作は、あなたのゴーサインを待たなければなりません。배포 workflow는 빌드와 검증을 스스로 끝내야 합니다 — 하지만 실제 배포 동작은 당신의 승인을 기다려야 합니다.

# In the skill's procedure, tag the mutating step with a risk tier:
# 在技能的 procedure 中，替會改變狀態的步驟標上風險層級：
      - id: deploy
        description: Deploy to production
        depends_on: [verify]
        command: "fly deploy --app my-api"
        risk: write        # read < write < network-egress < spend < destructive < privileged
        on_failure: abort

# Run over a channel — the gate only fires on channel runs
# 掛上 channel 執行 — 關卡只在 channel 執行時生效
$ mur workflow run deploy-api --channel-new
# channel: ch-0198f2...        ← printed to stderr / 印在 stderr
… build ✓  verify ✓
⏸ deploy paused: HitlRequest written, waiting for approval (300s)

# In another terminal: find the pending request's hitl id
# 另一個終端機：找出待核准請求的 hitl id
$ grep HitlRequest ~/.mur/channels/ch-0198f2*/events.jsonl | tail -1 | jq .payload.hitl_id
"hitl-0198f3ab..."

# Approve — or deny with a reason / 核准，或附理由拒絕
$ mur channel approve ch-0198f2... hitl-0198f3ab...
$ mur channel approve ch-0198f2... hitl-0198f3ab... --deny --reason "not before the demo"

risk: read runs unattended (audit only). Every other tier pauses the step, writes a HitlRequest event, and waits — default 300 s, then fail-closed deny. risk: read 不需等待（僅留稽核紀錄）。其他層級都會暫停步驟、寫入 HitlRequest 事件並等待 — 預設 300 秒，逾時失敗即拒絕。risk: read 无需等待（仅留审计记录）。其他级别都会暂停步骤、写入 HitlRequest 事件并等待 — 默认 300 秒，超时失败即拒绝。risk: read は待機不要です（監査記録だけ残します）。それ以外のレベルはステップを一時停止し、HitlRequest イベントを書き込んで待機します — デフォルト 300 秒、タイムアウトはフェイルクローズドで拒否です。risk: read는 대기하지 않습니다(감사 기록만 남김). 다른 등급은 모두 단계를 일시 정지하고 HitlRequest 이벤트를 기록한 뒤 대기합니다 — 기본 300초, 시간 초과 시 실패로 거부(fail-closed)됩니다.
The command is SHA-256 pinned at request time and re-verified at the execute boundary — if anything drifted between approval and execution, MUR refuses to run it. 指令在請求當下以 SHA-256 釘住，執行前再驗證一次 — 核准與執行之間若有任何改動，MUR 直接拒絕執行。命令在请求当下以 SHA-256 固定，执行前再验证一次 — 审批与执行之间若有任何改动，MUR 直接拒绝执行。コマンドはリクエスト時点で SHA-256 によりピン留めされ、実行前にもう一度検証されます — 承認から実行までの間に少しでも変更があれば、MUR は実行を即座に拒否します。명령은 요청 시점에 SHA-256으로 고정(pin)되고 실행 직전에 다시 검증됩니다 — 승인과 실행 사이에 어떤 변경이라도 있으면 MUR는 실행을 그대로 거부합니다.
--yes auto-approves Ask-tier gates (recorded as an auto response). Crashed runs resume: re-running with the same run id skips steps whose successful ToolResult is already on the channel. --yes 會自動核准 Ask 層級的關卡（以 auto 回應記錄）。中斷的執行可續跑：相同 run id 重跑會跳過 channel 上已有成功 ToolResult 的步驟。--yes 会自动批准 Ask 级别的关卡（以 auto 响应记录）。中断的执行可续跑：相同 run id 重跑会跳过 channel 上已有成功 ToolResult 的步骤。--yes は Ask レベルのゲートを自動承認します（auto 応答として記録）。中断した実行は再開できます：同じ run id で再実行すると、channel 上に成功した ToolResult があるステップはスキップされます。--yes는 Ask 등급 게이트를 자동 승인합니다(auto 응답으로 기록). 중단된 실행은 이어서 실행할 수 있습니다: 같은 run id로 재실행하면 channel에 이미 성공한 ToolResult가 있는 단계를 건너뜁니다.

Delegate parallel steps to specialist agents把平行步驟委派給專家 Agent把并行步骤委派给专家 Agent並列ステップを専門 Agent に委任する병렬 단계를 전문가 Agent에게 위임하기

●●○○Parallel · delegation fan-outA2A

Daily job日常情境日常场景日常のシナリオ일상 시나리오: code review day: have a coder agent analyze the diff while a docs agent checks the changelog — at the same time, each writing its own signed reply into one shared channel. Code review 日：讓 coder Agent 分析 diff、docs Agent 檢查 changelog — 同時進行，各自把「自己簽章」的回覆寫進同一條共享 channel。Code review 日：让 coder Agent 分析 diff、docs Agent 检查 changelog — 同时进行，各自把“自己签名”的回复写进同一条共享 channel。Code review の日：coder Agent に diff を分析させ、docs Agent に changelog をチェックさせます — 同時進行で、それぞれが「自分で署名した」返信を同じ共有 channel に書き込みます。Code review 날: coder Agent가 diff를 분석하고 docs Agent가 changelog를 점검하게 합니다 — 동시에 진행하며, 각자 "자기 서명"한 응답을 같은 공유 channel에 기록합니다.

# ~/.mur/skills/parallel-review/skill.yaml (procedure excerpt)
    steps:
      # rank 0 — two delegate steps dial two agents CONCURRENTLY
      # rank 0 — 兩個委派步驟「同時」呼叫兩個 Agent
      - id: code-review
        description: Review the diff
        delegate_to: coder
        intent: "review the current git diff for correctness and risk"
      - id: docs-review
        description: Check docs drift
        delegate_to: docs
        intent: "verify CHANGELOG and README match the diff"
      # rank 1 — synthesis waits for both / 綜整步驟等兩者完成
      - id: synthesize
        description: Merge findings
        depends_on: [code-review, docs-review]
        command: "echo 'both reviews are on the channel'"

# Delegation requires a channel + running agents / 委派需要 channel 與運行中的 Agent
$ mur agent status
$ mur workflow run parallel-review --channel-new

Each delegate_to step dials the specialist over A2A (channel/delegate). The specialist runs its turn and signs + writes its own reply into the shared channel — the router never ghost-writes for it. 每個 delegate_to 步驟透過 A2A（channel/delegate）呼叫專家。專家跑完自己的回合後，親自簽章並寫入共享 channel — router 絕不代筆。每个 delegate_to 步骤通过 A2A（channel/delegate）调用专家。专家跑完自己的回合后，亲自签名并写入共享 channel — router 绝不代笔。各 delegate_to ステップは A2A（channel/delegate）経由でスペシャリストを呼び出します。スペシャリストは自分のターンを終えると、共有 channel に自ら署名して書き込みます — router が代筆することは決してありません。각 delegate_to 단계는 A2A(channel/delegate)를 통해 전문가를 호출합니다. 전문가는 자기 턴을 마친 뒤 공유 channel에 직접 서명해 기록합니다 — router는 절대 대필하지 않습니다.
One compliant agent can serve N concurrent delegate turns — you don't need N distinct agents to fan out. 一個 Agent 就能同時服務 N 個委派回合 — 平行展開不需要 N 個不同的 Agent。一个 Agent 就能同时服务 N 个委派回合 — 并行展开不需要 N 个不同的 Agent。1 つの Agent が N 個の委任ターンを同時にさばけます — 並列ファンアウトに N 個の別々の Agent は必要ありません。Agent 하나가 N개의 위임 턴을 동시에 처리할 수 있습니다 — 병렬 팬아웃에 서로 다른 Agent N개가 필요하지 않습니다.
Every event is Ed25519-signed by its actor and verified per-actor on fold; retries get distinct idempotency keys so events never collide. 每個事件都由其行為者以 Ed25519 簽章、讀取時逐行為者驗證；重試使用不同的冪等鍵，事件不會相撞。每个事件都由其行为者用 Ed25519 签名、读取时逐行为者验证；重试使用不同的幂等键，事件不会相撞。すべてのイベントはそのアクター自身が Ed25519 で署名し、読み取り時にアクターごとに検証されます。リトライは別の冪等キーを使うため、イベントが衝突することはありません。모든 이벤트는 해당 행위자가 Ed25519로 서명하고, 읽을 때 행위자별로 검증됩니다. 재시도는 다른 멱등 키를 사용하므로 이벤트가 충돌하지 않습니다.

Where's the transcript? ~/.mur/channels/<id>/events.jsonl — an append-only, signed event log: Delegation, agent replies, ToolCall/ToolResult, StateChange. 對話紀錄在哪？ ~/.mur/channels/<id>/events.jsonl — 只增不改、有簽章的事件日誌：Delegation、Agent 回覆、ToolCall/ToolResult、StateChange。对话记录在哪？ ~/.mur/channels/<id>/events.jsonl — 只增不改、带签名的事件日志：Delegation、Agent 回复、ToolCall/ToolResult、StateChange。会話ログはどこに？ ~/.mur/channels/<id>/events.jsonl — 追記専用で署名付きのイベントログです：Delegation、Agent の返信、ToolCall/ToolResult、StateChange。대화 기록은 어디에? ~/.mur/channels/<id>/events.jsonl — 추가 전용이며 서명된 이벤트 로그입니다: Delegation, Agent 응답, ToolCall/ToolResult, StateChange.

Part 3 · Hard第三部 · 進階第三部 · 进阶第3部 · 上級제3부 · 고급

Fleets — agent squads on a shared goalFleet — 為共同目標編組的 Agent 小隊Fleet — 为共同目标编组的 Agent 小队Fleet — 共通の目標のために編成された Agent チームFleet — 공동 목표로 편성된 Agent 스쿼드

A fleet is a named squad of agents working one goal over a single signed channel (fleet-<name>), with a router agent coordinating. Fleets add the safety rails autonomy needs: iteration caps, deadlines, budgets, kill-switches, and cryptographic governance. Fleet 是一支有名字的 Agent 小隊，在同一條簽章 channel（fleet-<name>）上為單一目標工作，由 router Agent 協調。Fleet 補上自主運作必要的安全欄杆：迭代上限、期限、預算、緊急停止與加密治理。Fleet 是一支有名字的 Agent 小队，在同一条签名 channel（fleet-<name>）上为单一目标工作，由 router Agent 协调。Fleet 补上自主运作所需的安全护栏：迭代上限、期限、预算、紧急停止与加密治理。Fleet は名前を持つ Agent のチームで、単一の目標のために同じ署名付き channel（fleet-<name>）上で働き、router Agent が調整します。Fleet は自律運用に不可欠な安全ガードレールを備えます：反復回数上限、期限、予算、緊急停止、そして暗号学的ガバナンスです。Fleet는 이름을 가진 Agent 스쿼드로, 같은 서명 channel(fleet-<name>) 위에서 단일 목표를 위해 일하며 router Agent가 조율합니다. Fleet는 자율 운용에 필수적인 안전 난간을 더합니다: 반복 상한, 기한, 예산, 긴급 정지, 암호학적 거버넌스.

Create a dev-team fleet and run one iteration建立 devteam Fleet 並跑一輪创建 devteam Fleet 并跑一轮devteam Fleet を作成して 1 回実行するdevteam Fleet 만들고 한 차례 실행하기

●●●○Parallel · broadcast

Daily job日常情境日常场景日常のシナリオ일상 시나리오: you have three specialist agents (pm, qa, ghmanager). Squad them up under one standing goal and fan that goal out to all of them in one command. 你有三個專家 Agent（pm、qa、ghmanager）。把他們編成一隊、掛上常設目標，一條指令將目標同時廣播給所有成員。你有三个专家 Agent（pm、qa、ghmanager）。把它们编成一队、挂上常设目标，一条命令将目标同时广播给所有成员。3 つの専門 Agent（pm、qa、ghmanager）がいます。これらを 1 つのチームに編成し、常設の目標を掛けて、コマンド 1 つで目標を全メンバーへ同時にブロードキャストします。전문가 Agent 셋(pm, qa, ghmanager)이 있습니다. 이들을 한 팀으로 편성하고 상설 목표를 걸어, 명령 하나로 목표를 모든 멤버에게 동시에 브로드캐스트합니다.

# Create the fleet / 建立 Fleet
$ mur fleet create devteam \
    --members pm,qa,ghmanager \
    --router mur \
    --goal "Keep the repo green: triage, fix, test, report."

# Inspect / 檢視
$ mur fleet list
$ mur fleet show devteam

# Members must be running / 成員 Agent 必須在運行中
$ mur agent status

# One iteration: goal fans out to every member in parallel
# 跑一輪：目標平行廣播給每位成員
$ mur fleet run devteam

create writes ~/.mur/fleets/devteam/fleet.yaml and mints the shared signed channel fleet-devteam (router role for the router, delegate role for members). Omit --router and the concierge mur routes. create 會寫入 ~/.mur/fleets/devteam/fleet.yaml 並建立共享簽章 channel fleet-devteam（router 擔任 Router 角色、成員為 Delegate）。省略 --router 則由總管 mur 擔任。create 会写入 ~/.mur/fleets/devteam/fleet.yaml 并创建共享签名 channel fleet-devteam（router 担任 Router 角色、成员为 Delegate）。省略 --router 则由总管 mur 担任。create は ~/.mur/fleets/devteam/fleet.yaml を書き込み、共有署名 channel fleet-devteam を作成します（router が Router ロール、メンバーが Delegate）。--router を省略するとコンシェルジュの mur が担当します。create는 ~/.mur/fleets/devteam/fleet.yaml을 기록하고 공유 서명 channel fleet-devteam을 만듭니다(router가 Router 역할, 멤버는 Delegate). --router를 생략하면 컨시어지 mur가 맡습니다.
Under the hood run builds an in-memory DAG of delegate steps (job 13's machinery) — one per member, all rank 0 — so members work concurrently and each signs its own reply on the fleet channel. run 底層建出記憶體中的委派 DAG（任務 13 的機制）— 每位成員一步、全在 rank 0 — 成員同時工作，並各自在 fleet channel 上簽署回覆。run 底层构建出内存中的委派 DAG（任务 13 的机制）— 每位成员一步、全在 rank 0 — 成员同时工作，并各自在 fleet channel 上签署回复。run は内部でメモリ上の委任 DAG を構築します（タスク 13 の仕組み）— メンバーごとに 1 ステップ、すべて rank 0 — メンバーは同時に働き、それぞれ fleet の channel 上で返信に署名します。run은 내부적으로 메모리상의 위임 DAG를 만듭니다(작업 13의 메커니즘) — 멤버당 한 단계, 전부 rank 0 — 멤버는 동시에 일하며 각자 fleet channel에 서명한 응답을 남깁니다.
Runs pass yes: false — risk-tiered steps are never blanket-approved (fail-closed). 執行一律 yes: false — 風險分級步驟絕不概括核准（失敗即關閉）。执行一律 yes: false — 风险分级步骤绝不一揽子批准（失败即关闭）。実行は常に yes: false です — リスク階層付きステップを一括承認することは決してありません（フェイルクローズド）。실행은 항상 yes: false입니다 — 위험 등급 단계는 절대 일괄 승인되지 않습니다(fail-closed).

fleet ≠ team ≠ fleet_sync: a fleet is an agent squad; “team” is your human org/seats; “fleet_sync” is device sync. Unrelated subsystems. fleet ≠ team ≠ fleet_sync：fleet 是 Agent 小隊；team 是人類組織／席次；fleet_sync 是裝置同步。三者互不相關。fleet ≠ team ≠ fleet_sync：fleet 是 Agent 小队；team 是人类组织／席位；fleet_sync 是设备同步。三者互不相关。fleet ≠ team ≠ fleet_sync：fleet は Agent のチーム、team は人間の組織／シート、fleet_sync はデバイス同期です。三者は互いに無関係です。fleet ≠ team ≠ fleet_sync: fleet는 Agent 스쿼드, team은 인간 조직/좌석, fleet_sync는 기기 동기화입니다. 셋은 서로 무관합니다.

Member capability floor: scripted repo operations (verbatim git/gh sequences) need a sonnet-class model — small quantized local models (~4B) return empty turns even with every command supplied. And git push over an SSH remote execs ssh, which typical spawn allowlists omit: grant it (mur agent perm allow-spawn <agent> ssh) or switch to HTTPS via gh auth setup-git.成員能力門檻：照稿執行 repo 操作（逐字 git/gh 序列）需要 sonnet 級模型——小型量化本地模型（約 4B）即使指令全給也會交白卷。另外 git push 走 SSH 遠端會執行 ssh，一般 spawn 白名單沒有它：授權（mur agent perm allow-spawn <agent> ssh）或改用 gh auth setup-git 走 HTTPS。成员能力门槛：照稿执行 repo 操作（逐字 git/gh 序列）需要 sonnet 级模型——小型量化本地模型（约 4B）即使命令全给也会交白卷。另外 git push 走 SSH 远程会执行 ssh，一般 spawn 白名单没有它：授权（mur agent perm allow-spawn <agent> ssh）或改用 gh auth setup-git 走 HTTPS。メンバーの能力下限：スクリプト化されたリポジトリ操作（git/gh コマンド列の逐語実行）には sonnet クラスのモデルが必要です——小型量子化ローカルモデル（約 4B）はコマンドを全部与えても空の応答を返します。また SSH リモートへの git push は ssh を exec しますが、通常の spawn 許可リストには含まれません：許可する（mur agent perm allow-spawn <agent> ssh）か、gh auth setup-git で HTTPS に切り替えてください。멤버 능력 하한: 스크립트화된 repo 작업(git/gh 명령을 그대로 실행)에는 sonnet급 모델이 필요합니다 — 소형 양자화 로컬 모델(~4B)은 명령을 모두 제공해도 빈 응답을 반환합니다. 또한 SSH 원격으로의 git push는 ssh를 실행하는데, 일반 spawn 허용 목록에는 없습니다: 허용하거나(mur agent perm allow-spawn <agent> ssh) gh auth setup-git으로 HTTPS로 전환하십시오.

Queue work for the fleet把工作丟進 Fleet 佇列把任务丢进 Fleet 队列ジョブを Fleet のキューに投入する작업을 Fleet 큐에 넣기

●●●○jobs

Daily job日常情境日常场景日常のシナリオ일상 시나리오: issues arrive all day. Queue them as fleet jobs instead of editing fleet.yaml or babysitting a terminal. issue 整天不斷進來。把它們排入 fleet 工作佇列，不用改 fleet.yaml，也不用守著終端機。issue 整天不断进来。把它们排入 fleet 任务队列，不用改 fleet.yaml，也不用守着终端。issue は一日中絶えず入ってきます。fleet のジョブキューに積んでおけば、fleet.yaml を編集する必要も、ターミナルに張り付く必要もありません。issue가 하루 종일 계속 들어옵니다. fleet 작업 큐에 넣어 두면 fleet.yaml을 고칠 필요도, 터미널을 지킬 필요도 없습니다.

# Queue async jobs (FIFO) / 排入非同步工作（先進先出）
$ mur fleet send devteam "triage issue #142 and propose a fix"
$ mur fleet send devteam "update the release notes for v2.33"

# See the queue (--all includes finished) / 查看佇列（--all 含已完成）
$ mur fleet jobs devteam --all

# One-shot job that jumps the queue / 插隊的一次性工作
$ mur fleet run devteam "hotfix: CI is red on main, investigate now"

Jobs persist as ~/.mur/fleets/devteam/jobs/<uuidv7>.yaml — one file per job, ordered by filename (uuidv7 is time-sortable). 工作以 ~/.mur/fleets/devteam/jobs/<uuidv7>.yaml 保存 — 一件一檔，按檔名排序（uuidv7 依時間可排序）。任务以 ~/.mur/fleets/devteam/jobs/<uuidv7>.yaml 保存 — 一件一个文件，按文件名排序（uuidv7 按时间可排序）。ジョブは ~/.mur/fleets/devteam/jobs/<uuidv7>.yaml として保存されます — 1 件 1 ファイルで、ファイル名順に並びます（uuidv7 は時間順にソート可能）。작업은 ~/.mur/fleets/devteam/jobs/<uuidv7>.yaml로 저장됩니다 — 건당 파일 하나, 파일명 순 정렬(uuidv7은 시간순 정렬 가능).
Passing a job string to run executes that job immediately for this iteration instead of the standing goal. 給 run 帶上工作字串，該輪就改執行這件事，而不是常設目標。给 run 带上任务字符串，该轮就改为执行这件事，而不是常设目标。run にジョブ文字列を渡すと、その回は常設目標ではなくそのジョブを実行します。run에 작업 문자열을 넘기면 그 회차는 상설 목표 대신 그 일을 실행합니다.

Dispatching long jobs: the router hands members your job text plus its routing note verbatim — but for multi-KB specs the battle-tested pattern is a spec file: write the full brief into the repo, send a short job saying “read <absolute path> and execute it”. Name the assignee explicitly and have everyone else reply SKIP.派長工單的實務：router 會把你的工單原文加上路由註記完整交給成員——但對數 KB 的大規格，實戰驗證的模式是「規格檔」：把完整任務書寫進 repo，工單只留一句「讀 <絕對路徑> 並執行」。明確點名受派者，其他成員一律回 SKIP。派发长工单的实务：router 会把你的工单原文加上路由注记完整交给成员——但对数 KB 的大规格，实战验证的模式是「规格文件」：把完整任务书写进 repo，工单只留一句「读 <绝对路径> 并执行」。明确点名受派者，其他成员一律回 SKIP。長いジョブの割り当て実務：router はジョブ本文をルーティング注記付きでそのままメンバーに渡します——しかし数 KB 規模の仕様では、実戦で検証済みのパターンは「仕様ファイル」です：完全な指示書をリポジトリに書き、ジョブは「<絶対パス> を読んで実行せよ」の一文だけにします。担当者を明示的に指名し、他のメンバーには SKIP と返答させます。긴 작업 배정 실무: router는 작업 본문을 라우팅 메모와 함께 그대로 멤버에게 전달합니다 — 그러나 수 KB급 사양서라면 실전 검증된 패턴은 “사양 파일”입니다: 전체 지시서를 repo에 쓰고, 작업은 “<절대 경로>를 읽고 실행하라” 한 문장만 보냅니다. 담당자를 명시하고 나머지 멤버는 SKIP으로 답하게 하십시오.

Let the router plan who does what讓 Router 規劃誰做什麼让 Router 规划谁做什么Router に誰が何をするかを計画させるRouter가 누가 무엇을 할지 계획하게 하기

●●●○Parallel · routed plan

Daily job日常情境日常场景日常のシナリオ일상 시나리오: not every task needs every member. On each iteration the router can emit a structured plan — a validated DAG that routes work to the right members with dependencies — instead of broadcasting to everyone. 不是每件事都需要全員出動。每輪迭代 router 可產出結構化計畫 — 一個經驗證的 DAG，把工作派給合適成員並帶相依關係 — 而非對全員廣播。不是每件事都需要全员出动。每轮迭代 router 可产出结构化计划 — 一个经过验证的 DAG，把任务派给合适成员并带依赖关系 — 而非向全员广播。すべての仕事に全員出動が必要なわけではありません。router は各イテレーションで、全員へのブロードキャストの代わりに構造化された計画 — 適切なメンバーへ依存関係付きで仕事を割り当てる、検証済みの DAG — を生成できます。모든 일에 전원이 출동할 필요는 없습니다. 매 반복마다 router는 구조화된 계획을 내놓을 수 있습니다 — 적합한 멤버에게 일을 배정하고 의존 관계를 담은, 검증된 DAG — 전원 브로드캐스트 대신 말입니다.

# Same command — planning happens inside the run
# 指令相同 — 規劃在執行內部發生
$ mur fleet run devteam "ship the login fix: code it, test it, open the PR"

# Watch what the router decided / 觀察 router 的決策
$ tail -f ~/.mur/channels/fleet-devteam/events.jsonl | jq -r .kind
Delegation      ← router planned: pm→plan, qa→test (after), ghmanager→PR (after)
Message …

The router's plan is validated hard: members must exist, dependencies must resolve, cycles are rejected. router 的計畫經嚴格驗證：成員必須存在、相依必須可解析、循環一律拒絕。router 的计划经严格验证：成员必须存在、依赖必须可解析、循环一律拒绝。router の計画は厳密に検証されます：メンバーは実在し、依存関係は解決可能でなければならず、循環は必ず拒否されます。router의 계획은 엄격히 검증됩니다: 멤버는 존재해야 하고, 의존성은 해석 가능해야 하며, 순환은 무조건 거부됩니다.
Fail-safe: any absent or invalid plan falls back to broadcast-to-all — the fleet never stalls because the router hallucinated a plan. 失效保護：計畫缺席或無效時自動退回全員廣播 — router 亂寫計畫也不會讓 fleet 卡死。失效保护：计划缺失或无效时自动回退到全员广播 — router 乱写计划也不会让 fleet 卡死。フェイルセーフ：計画が欠けているか無効な場合は全員ブロードキャストに自動フォールバックします — router がでたらめな計画を書いても fleet が止まることはありません。페일세이프: 계획이 없거나 무효이면 자동으로 전원 브로드캐스트로 되돌아갑니다 — router가 엉터리 계획을 내도 fleet가 멈추지 않습니다.
Plan steps with dependencies land at higher ranks, so “code → test → PR” chains execute in order while independent branches still run in parallel. 帶相依的計畫步驟落在較高 rank，「寫碼 → 測試 → 開 PR」依序執行，獨立分支仍然平行。带依赖的计划步骤落在较高 rank，“写码 → 测试 → 开 PR”依次执行，独立分支仍然并行。依存関係を持つ計画ステップは高い rank に置かれ、「コーディング → テスト → PR 作成」は順番に実行されますが、独立した枝は引き続き並列です。의존성이 있는 계획 단계는 더 높은 rank에 놓여 "코드 작성 → 테스트 → PR 열기"가 순서대로 실행되고, 독립 분기는 여전히 병렬로 돕니다.

Loop until the job is actually done迴圈執行直到真正完成循环执行直到真正完成本当に完了するまでループ実行する정말 끝날 때까지 루프 실행하기

●●●○guarded loop

Daily job日常情境日常场景日常のシナリオ일상 시나리오: “keep iterating until all tests pass” — with hard guards so it can't run away: iteration cap, wall-clock deadline, budget, stuck-detection, and a deterministic done-marker. 「反覆迭代直到測試全綠」— 並加上硬性防護避免失控：迭代上限、時鐘期限、預算、卡住偵測，以及確定性的完成標記。“反复迭代直到测试全绿”— 并加上硬性防护避免失控：迭代上限、时钟期限、预算、卡住检测，以及确定性的完成标记。「テストが全部グリーンになるまで繰り返す」— そして暴走を防ぐ強制ガードを加えます：反復回数上限、時計ベースの期限、予算、スタック検知、そして決定的な完了マーカーです。"테스트가 전부 초록이 될 때까지 반복" — 그리고 폭주를 막는 강제 가드를 더합니다: 반복 상한, 시계 기한, 예산, 멈춤 감지, 결정적 완료 마커.

# Configure convergence once / 先設定收斂條件
$ mur fleet set-loop devteam --done-when "marker:ALL_GREEN" --max-iterations 8

# Run the guarded loop / 執行守護迴圈
$ mur fleet run devteam --loop --max-iterations 5 --deadline 30m --budget-usd 5.0
iteration 1/5 … members report … no marker → continue
iteration 2/5 … qa emits "ALL_GREEN" on its own line → converged ✓

Deterministic convergence: done_when: marker:<TEXT> converges only when a member emits the marker alone on its own line in this run — prose that merely quotes or negates it can't false-converge. No marker configured? The router judges DONE/CONTINUE, failing safe to continue. 確定性收斂：done_when: marker:<TEXT> 只在成員於本輪把標記單獨成行輸出時收斂 — 內文引用或否定它都不會誤判。沒設標記？由 router 判斷 DONE/CONTINUE，且失效預設為繼續。确定性收敛：done_when: marker:<TEXT> 只在成员于本轮把标记单独成行输出时收敛 — 正文引用或否定它都不会误判。没设标记？由 router 判断 DONE/CONTINUE，且失效默认为继续。決定的な収束：done_when: marker:<TEXT> は、メンバーがこの回にマーカーを単独の行として出力した場合にのみ収束します — 本文中で引用しても否定しても誤判定しません。マーカー未設定なら router が DONE/CONTINUE を判断し、失敗時のデフォルトは継続です。결정적 수렴: done_when: marker:<TEXT>는 멤버가 이번 회차에 마커를 한 줄에 단독으로 출력했을 때만 수렴합니다 — 본문에서 인용하거나 부정해도 오판하지 않습니다. 마커를 안 정했다면? router가 DONE/CONTINUE를 판정하며, 실패 시 기본값은 계속 진행입니다.
Guards live outside any agent (in the CLI loop runner): iteration cap (default 8), relative deadline (30s/5m/2h/1d — not a calendar date), stuck-detection, and the budget from job 18. 防護都在 Agent 外部（CLI 迴圈執行器）：迭代上限（預設 8）、相對期限（30s/5m/2h/1d，不是日期）、卡住偵測，以及任務 18 的預算。防护都在 Agent 外部（CLI 循环执行器）：迭代上限（默认 8）、相对期限（30s/5m/2h/1d，不是日期）、卡住检测，以及任务 18 的预算。ガードはすべて Agent の外側にあります（CLI のループランナー）：反復回数上限（デフォルト 8）、相対期限（30s/5m/2h/1d、日付ではありません）、スタック検知、そしてタスク 18 の予算です。가드는 전부 Agent 외부(CLI 루프 실행기)에 있습니다: 반복 상한(기본 8), 상대 기한(30s/5m/2h/1d, 날짜가 아님), 멈춤 감지, 그리고 작업 18의 예산.
CLI flags override the loop: block in fleet.yaml for this run only. CLI 旗標僅在本次執行覆寫 fleet.yaml 的 loop: 區塊。CLI 标志仅在本次执行覆盖 fleet.yaml 的 loop: 块。CLI フラグは今回の実行に限り fleet.yaml の loop: ブロックを上書きします。CLI 플래그는 이번 실행에 한해 fleet.yaml의 loop: 블록을 덮어씁니다.

Real budgets and the kill-switch真實預算與緊急停止真实预算与紧急停止実コストの予算と緊急停止실제 예산과 긴급 정지

●●●○safety

Daily job日常情境日常场景日常のシナリオ일상 시나리오: cap what a loop can spend, watch real token accounting, and stop everything instantly when you need to. 限制迴圈能花多少錢、看真實 token 計帳，需要時立刻叫停一切。限制循环能花多少钱、查看真实 token 记账，需要时立刻叫停一切。ループが使える金額を制限し、実際の token 課金を確認し、必要なときはすべてを即座に停止します。루프가 쓸 수 있는 돈을 제한하고, 실제 token 정산을 확인하고, 필요하면 즉시 모든 것을 멈춥니다.

# Budget-capped loop: stops BEFORE cumulative cost exceeds the cap
# 預算上限迴圈：累計成本超過前就先停
$ mur fleet run devteam --loop --budget-usd 2.50

# Cost rate resolution / 費率解析順序:
#   MUR_FLEET_COST_PER_1K env → dearest output rate in ~/.mur/models.yaml → default
$ MUR_FLEET_COST_PER_1K=0.03 mur fleet run devteam --loop --budget-usd 1

# KILL-SWITCH: stop everything now / 緊急停止：立即全面停止
$ mur fleet stop devteam
✋ a running --loop bails next iteration; the daemon skips it; manual run refuses

# Resume when ready / 恢復
$ mur fleet start devteam

Spend is real, not projected: each turn's actual input+output tokens flow back through the task usage into the loop's ledger; a 0-token iteration falls back to projection so spend can never silently under-count. 花費是真實值，不是預估：每回合實際的輸入＋輸出 token 會經由任務用量回流到迴圈帳本；0 token 的迭代退回預估值，花費絕不會被靜默低估。花费是真实值，不是预估：每回合实际的输入＋输出 token 会经由任务用量回流到循环账本；0 token 的迭代回退到预估值，花费绝不会被静默低估。支出は実測値であり、見積もりではありません：各ターンの実際の入力＋出力 token がタスクの使用量経由でループの帳簿に還流します。0 token のイテレーションは見積もり値にフォールバックするため、支出が静かに過小計上されることは決してありません。지출은 실제 값이지 추정치가 아닙니다: 매 턴의 실제 입력＋출력 token이 작업 사용량을 통해 루프 장부로 되돌아옵니다. 0 token 반복은 추정치로 폴백하므로 지출이 조용히 과소 계상되는 일은 절대 없습니다.
stop writes a .stopped sentinel in ~/.mur/fleets/devteam/; start clears it. Simple, inspectable, and honored by every execution path. stop 會在 ~/.mur/fleets/devteam/ 寫入 .stopped 哨兵檔；start 清除它。簡單、可檢視，且所有執行路徑都遵守。stop 会在 ~/.mur/fleets/devteam/ 写入 .stopped 哨兵文件；start 清除它。简单、可查看，且所有执行路径都遵守。stop は ~/.mur/fleets/devteam/ に .stopped センチネルファイルを書き込み、start がそれを消去します。シンプルで、目視確認でき、すべての実行経路がこれに従います。stop은 ~/.mur/fleets/devteam/에 .stopped 센티널 파일을 기록하고, start는 이를 지웁니다. 단순하고 들여다볼 수 있으며, 모든 실행 경로가 이를 지킵니다.

Unattended: let the daemon run the fleet無人值守：讓常駐程式自動跑 Fleet无人值守：让守护进程自动跑 Fleet無人運転：デーモンに Fleet を自動実行させる무인 운영: 데몬이 Fleet를 자동 실행하게 하기

●●●○daemoncron

Daily job日常情境日常场景日常のシナリオ일상 시나리오: a docs-gardening fleet that wakes every 30 minutes (or weekdays at 09:00) without you — protected by an explicit opt-in switch, a mandatory budget, and the kill-switch. 一支每 30 分鐘（或平日 09:00）自動甦醒的文件維護 fleet — 由明確的啟用開關、強制預算與緊急停止共同保護。一支每 30 分钟（或工作日 09:00）自动苏醒的文档维护 fleet — 由明确的启用开关、强制预算与紧急停止共同保护。30 分ごと（または平日 09:00）に自動で目覚めるドキュメント保守 fleet — 明示的な有効化スイッチ、強制予算、緊急停止によって保護されます。30분마다(또는 평일 09:00에) 스스로 깨어나는 문서 유지보수 fleet — 명시적 활성화 스위치, 강제 예산, 긴급 정지가 함께 보호합니다.

# 1. Give the fleet a trigger + budget / 設定觸發器與預算
$ mur fleet set-loop docs --trigger interval:30m --budget-usd 3 --max-iterations 4
#    …or cron (5-field POSIX, local timezone) / 或 cron（五欄位，當地時區）
$ mur fleet set-loop docs --trigger "cron:0 9 * * 1-5" --budget-usd 3

# 2. Opt in — auto-run is OFF by default / 明確啟用 — 預設為關閉
$ export MUR_FLEET_AUTORUN=1        # or config.yaml: fleet.autorun: true

# 3. The daemon's 30s tick now auto-runs due fleets
#    常駐程式每 30 秒檢查，到期的 fleet 自動執行

The safety triad — all three or nothing runs: (1) MUR_FLEET_AUTORUN switch on, (2) per-fleet budget_usd > 0, (3) no .stopped sentinel. Plus commander governance (job 21) checked fail-closed. 安全三要件 — 缺一不跑：(1) MUR_FLEET_AUTORUN 開關開啟、(2) 該 fleet 的 budget_usd > 0、(3) 沒有 .stopped 哨兵。另加 Commander 治理（任務 21），讀取失敗即拒絕。安全三要素 — 缺一不跑：(1) MUR_FLEET_AUTORUN 开关开启、(2) 该 fleet 的 budget_usd > 0、(3) 没有 .stopped 哨兵。另加 Commander 治理（任务 21），读取失败即拒绝。安全の三要件 — 1 つでも欠ければ動きません：(1) MUR_FLEET_AUTORUN スイッチが有効、(2) その fleet の budget_usd > 0、(3) .stopped センチネルが存在しない。さらに Commander ガバナンス（タスク 21）が加わり、読み取り失敗はフェイルクローズドで拒否されます。안전 3요소 — 하나라도 빠지면 실행되지 않습니다: (1) MUR_FLEET_AUTORUN 스위치 켜짐, (2) 해당 fleet의 budget_usd > 0, (3) .stopped 센티널 없음. 여기에 Commander 거버넌스(작업 21)가 더해지며, 읽기 실패 시 거부(fail-closed)입니다.
Last run time is stamped in ~/.mur/fleets/<name>/.last_run. Cron fleets are baseline-stamped on first sight, so enabling one never fires spuriously — it waits for the next real boundary. 上次執行時間記在 ~/.mur/fleets/<name>/.last_run。cron fleet 首次被看到時會先蓋基準戳記，啟用當下絕不誤發 — 等到下一個真正的時間點才跑。上次执行时间记在 ~/.mur/fleets/<name>/.last_run。cron fleet 首次被看到时会先盖基准戳记，启用当下绝不误发 — 等到下一个真正的时间点才跑。前回の実行時刻は ~/.mur/fleets/<name>/.last_run に記録されます。cron の fleet は初めて認識された時点でベースラインのスタンプが押されるため、有効化した瞬間に誤発火することはありません — 次の本当の時刻境界を待ってから実行されます。마지막 실행 시각은 ~/.mur/fleets/<name>/.last_run에 기록됩니다. cron fleet는 처음 발견될 때 기준 타임스탬프를 먼저 찍으므로 활성화 순간에 잘못 발화하지 않습니다 — 다음 진짜 시각이 되어서야 실행됩니다.
Each auto-run loop gets its own thread + runtime, so a slow router dial can never stall the daemon. 每次自動執行都有獨立執行緒與 runtime，router 撥號再慢也不會卡住常駐程式。每次自动运行都有独立线程与 runtime，router 拨号再慢也不会卡住守护进程。自動実行のたびに独立したスレッドと runtime が用意されるため、router へのダイヤルがどれだけ遅くてもデーモンが詰まることはありません。자동 실행마다 독립 스레드와 runtime을 가지므로, router 다이얼이 아무리 느려도 데몬이 멈추지 않습니다.

Fleet-scoped skills and roster managementFleet 範圍技能與名冊管理Fleet 范围技能与名单管理Fleet スコープのスキルとロースター管理Fleet 범위 스킬과 명단 관리

●●●○skillsscope

Daily job日常情境日常场景日常のシナリオ일상 시나리오: your triage checklist should only inject for members of the devteam fleet — not for every agent on the machine. And the roster changes: add a reviewer, drop the docs agent. 你的分診檢查表應該只注入給 devteam fleet 的成員 — 而不是機器上所有 Agent。名冊也會變動：加一個 reviewer、移除 docs。你的分诊检查清单应该只注入给 devteam fleet 的成员 — 而不是机器上所有 Agent。名单也会变动：加一个 reviewer、移除 docs。トリアージのチェックリストは devteam fleet のメンバーにだけ注入されるべきです — マシン上のすべての Agent にではなく。ロースターも変わります：reviewer を 1 人追加し、docs を外す、といった具合です。당신의 트리아지 체크리스트는 devteam fleet 멤버에게만 주입되어야 합니다 — 머신의 모든 Agent가 아니라. 명단도 바뀝니다: reviewer 하나 추가, docs 제거.

# Scope a skill to the fleet / 把技能範圍限定到 fleet
$ mur skill scope triage-checklist --fleet devteam

# Other scopes / 其他範圍
$ mur skill scope repo-conventions --project     # current git repo / 目前的 repo
$ mur skill scope triage-checklist --user        # reset to personal / 還原成個人

# Roster management / 名冊管理
$ mur fleet add devteam reviewer
$ mur fleet remove devteam docs

# Delete the fleet (agents survive) / 刪除 fleet（Agent 不會被刪）
$ mur fleet delete devteam --yes

Fleet-scoped skills inject only when the agent's active fleet matches — derived from the fleet-<name> channel id and gated on verified local fleet membership, fail-closed. No spoofing your way into fleet knowledge. Fleet 範圍技能只在 Agent 的作用中 fleet吻合時注入 — 由 fleet-<name> channel id 推導，並經本地成員資格驗證把關，失敗即拒絕。想偽裝混入 fleet 知識是行不通的。Fleet 范围技能只在 Agent 的活动 fleet匹配时注入 — 由 fleet-<name> channel id 推导，并经本地成员资格验证把关，失败即拒绝。想伪装混入 fleet 知识是行不通的。Fleet スコープのスキルは、Agent のアクティブな fleet が一致する場合にのみ注入されます — fleet-<name> の channel id から導出され、ローカルのメンバーシップ検証でゲートされ、失敗すればフェイルクローズドで拒否されます。なりすまして fleet の知識に潜り込むことはできません。Fleet 범위 스킬은 Agent의 활성 fleet가 일치할 때만 주입됩니다 — fleet-<name> channel id에서 파생되고 로컬 멤버십 검증으로 게이트되며, 실패 시 거부(fail-closed)입니다. 위장해서 fleet 지식에 섞여 들 수는 없습니다.
Harvest (job 9) stamps --project scope automatically from the repo root, so harvested workflows stay with their repo. 收割（任務 9）會自動依 repo 根目錄標記 --project 範圍，收割出的 workflow 跟著 repo 走。收割（任务 9）会自动按 repo 根目录标记 --project 范围，收割出的 workflow 跟着 repo 走。ハーベスト（タスク 9）はリポジトリのルートに基づいて自動的に --project スコープを付けるため、ハーベストされた workflow はリポジトリと一緒に移動します。수확(작업 9)은 repo 루트를 기준으로 --project 범위를 자동으로 표시하므로, 수확된 workflow는 repo를 따라갑니다.

Commander governance: signed kill & budget ceilingsCommander 治理：簽章停止令與預算天花板Commander 治理：签名停止令与预算上限Commander ガバナンス：署名付き停止命令と予算上限Commander 거버넌스: 서명된 정지 명령과 예산 상한

●●●○governance

Daily job日常情境日常场景日常のシナリオ일상 시나리오: the operator (maybe not the same person running the terminal) needs authority over every fleet: a cryptographically signed kill order or a spend ceiling that no loop can ignore. 營運者（可能不是敲終端機的那個人）需要凌駕所有 fleet 的權限：加密簽章的停止令，或任何迴圈都無法忽視的花費天花板。运营者（可能不是敲终端的那个人）需要凌驾所有 fleet 的权限：加密签名的停止令，或任何循环都无法忽视的花费上限。運用者（ターミナルを叩いている本人とは限りません）には、すべての fleet に優越する権限が必要です：暗号署名付きの停止命令、あるいはどのループも無視できない支出の上限です。운영자(터미널을 두드리는 사람이 아닐 수도 있음)에게는 모든 fleet를 넘어서는 권한이 필요합니다: 암호 서명된 정지 명령, 또는 어떤 루프도 무시할 수 없는 지출 상한.

# One-time: pin the operator's Ed25519 public key / 一次性：釘選營運者公鑰
$ mur commander pin z6Mk...operatorPubKey
$ mur commander status

# Signed directives into the fleet channel / 對 fleet channel 下達簽章指令
$ mur commander directive devteam kill
$ mur commander directive devteam budget-ceiling --budget-usd 2.50
$ mur commander directive devteam resume

Directives are Ed25519-signed events on the fleet-devteam channel — an immutable, replay-resistant audit trail (folded by issue time). 指令是 fleet-devteam channel 上的 Ed25519 簽章事件 — 不可竄改、抗重放的稽核軌跡（依簽發時間折疊）。指令是 fleet-devteam channel 上的 Ed25519 签名事件 — 不可篡改、抗重放的审计轨迹（按签发时间折叠）。指令は fleet-devteam channel 上の Ed25519 署名イベントです — 改ざん不能でリプレイ耐性のある監査証跡です（発行時刻でフォールドされます）。지시는 fleet-devteam channel 위의 Ed25519 서명 이벤트입니다 — 변조 불가·재생 저항성 감사 추적(발행 시각 기준 폴드).
Priority is absolute: kill halts loops and blocks daemon auto-run; a budget-ceiling of exactly 0 is a hard halt; otherwise the ceiling is min'd with the fleet/CLI budget. Governance read errors fail closed. 優先權絕對：kill 中止迴圈並阻擋常駐自動執行；budget-ceiling 為 0 即硬停止；否則天花板與 fleet／CLI 預算取最小值。治理讀取失敗一律拒絕執行。优先级绝对：kill 中止循环并阻止守护进程自动运行；budget-ceiling 为 0 即硬停止；否则上限与 fleet／CLI 预算取最小值。治理读取失败一律拒绝执行。優先度は絶対です：kill はループを中止しデーモンの自動実行をブロックします。budget-ceiling が 0 ならハードストップ、そうでなければ上限と fleet／CLI 予算の小さい方が採用されます。ガバナンスの読み取りに失敗した場合は必ず実行を拒否します。우선순위는 절대적입니다: kill은 루프를 중단시키고 데몬 자동 실행을 차단합니다. budget-ceiling이 0이면 즉시 하드 스톱이고, 그 외에는 상한과 fleet/CLI 예산 중 최솟값을 취합니다. 거버넌스 읽기 실패 시 실행은 무조건 거부됩니다.
Re-pinning requires --force and preserves the previous key for verification of older directives. 重新釘選需要 --force，且會保留舊公鑰以驗證先前的指令。重新固定需要 --force，且会保留旧公钥以验证先前的指令。再ピン留めには --force が必要で、以前の指令を検証できるよう旧公開鍵は保持されます。다시 고정(pin)하려면 --force가 필요하며, 이전 지시를 검증할 수 있도록 예전 공개 키를 보존합니다.

Share a fleet with a friend (.fleet bundle)把 Fleet 分享給朋友（.fleet 套件）把 Fleet 分享给朋友（.fleet 包）Fleet を友人に共有する（.fleet バンドル）Fleet를 친구에게 공유하기(.fleet 번들)

●●●○exporttrust

Daily job日常情境日常场景日常のシナリオ일상 시나리오: your devteam fleet works great — package it (config + fleet-scoped skills + member profiles) and hand it to a teammate, safely. 你的 devteam fleet 運作良好 — 把它打包（設定＋fleet 範圍技能＋成員設定檔）安全地交給同事。你的 devteam fleet 运作良好 — 把它打包（配置＋fleet 范围技能＋成员配置文件）安全地交给同事。devteam fleet はうまく機能しています — それをパッケージ化して（設定＋fleet スコープのスキル＋メンバープロファイル）同僚に安全に渡します。devteam fleet가 잘 돌아갑니다 — 이를 패키징해(설정＋fleet 범위 스킬＋멤버 프로필) 동료에게 안전하게 건넵니다.

# Export: signed tar.gz bundle / 匯出：簽章的 tar.gz 套件
$ mur fleet export devteam --with-members -o devteam.fleet

# On the teammate's machine / 在同事的機器上
$ mur fleet import devteam.fleet --yes
# variants / 變化型:
$ mur fleet import devteam.fleet --no-members   # fleet config only / 只要設定
$ mur fleet import devteam.fleet --force        # overwrite same-name fleet / 覆寫同名

Import is paranoid by design: verifies the bundle signature, security-scans every skill, installs at the lowest trust tier (peer TOFU), and never copies private keys — member identities are regenerated locally. 匯入天生多疑：驗證套件簽章、逐一安全掃描技能、以最低信任層級安裝（peer TOFU），且絕不複製私鑰 — 成員身分在本地重新產生。导入天生多疑：验证包签名、逐一安全扫描技能、以最低信任级别安装（peer TOFU），且绝不复制私钥 — 成员身份在本地重新生成。インポートは生まれつき疑り深い設計です：バンドル署名を検証し、スキルを 1 つずつセキュリティスキャンし、最低の信頼レベルでインストールし（peer TOFU）、秘密鍵は決してコピーしません — メンバーのアイデンティティはローカルで再生成されます。가져오기는 태생적으로 의심이 많습니다: 번들 서명을 검증하고, 스킬을 하나하나 보안 스캔하고, 최저 신뢰 등급으로 설치하며(peer TOFU), 개인 키는 절대 복사하지 않습니다 — 멤버 신원은 로컬에서 새로 생성됩니다.
Existing agents are never overwritten, and an imported fleet never auto-runs — the receiver must consciously start it. 既有 Agent 絕不被覆寫；匯入的 fleet 也絕不自動執行 — 收件人必須自己有意識地啟動。既有 Agent 绝不被覆盖；导入的 fleet 也绝不自动运行 — 接收者必须自己有意识地启动。既存の Agent が上書きされることは決してなく、インポートされた fleet が自動実行されることもありません — 受け取った人が自分の意思で起動する必要があります。기존 Agent는 절대 덮어써지지 않고, 가져온 fleet도 절대 자동 실행되지 않습니다 — 받는 사람이 직접 의식적으로 시작해야 합니다.

Part 4 · Expert第四部 · 專家第四部 · 专家第4部 · エキスパート제4부 · 전문가

Parallel execution deep-dive平行執行深入篇并行执行深入篇並列実行の深掘り병렬 실행 심화편

You've already used four parallel patterns (DAG fan-out, delegation, broadcast, routed plans). These last four are the heavy machinery: dynamic fan-out from a conversation, best-of-N competition, file partitioning, and N-way merges. The matrix at the end maps every pattern to when you should reach for it. 你已經用過四種平行模式（DAG 展開、委派、廣播、路由計畫）。最後四個是重型機具：對話中動態展開、N 選一競爭、檔案分割、N 路合併。文末的矩陣說明每種模式該在什麼時機使用。你已经用过四种并行模式（DAG 展开、委派、广播、路由计划）。最后四个是重型机械：对话中动态展开、N 选一竞争、文件分割、N 路合并。文末的矩阵说明每种模式该在什么时机使用。ここまでで 4 つの並列パターン（DAG ファンアウト、委任、ブロードキャスト、ルーティング計画）を使ってきました。残りの 4 つは重機です：会話中の動的ファンアウト、N 者択一の競争、ファイル分割、N-way マージ。章末のマトリクスが、各パターンをいつ使うべきかを示します。이미 네 가지 병렬 패턴(DAG 팬아웃, 위임, 브로드캐스트, 라우팅 계획)을 써 봤습니다. 마지막 넷은 중장비입니다: 대화 중 동적 팬아웃, N개 중 하나를 고르는 경쟁, 파일 분할, N-웨이 병합. 글 끝의 매트릭스가 각 패턴을 언제 써야 하는지 설명합니다.

Dynamic fan-out from a conversation: parallel_jobs對話中動態展開：parallel_jobs对话中动态展开：parallel_jobs会話中の動的ファンアウト：parallel_jobs대화 중 동적 팬아웃: parallel_jobs

●●●●Parallel · ephemeral fan-outMCP

Daily job日常情境日常场景日常のシナリオ일상 시나리오: mid-conversation with your concierge you realize three unrelated things need doing. Fan them out to three agents right now — no fleet file, no YAML, one tool call. 跟總管聊到一半，發現有三件不相干的事要辦。立刻展開給三個 Agent — 不用 fleet 檔、不用 YAML，一個工具呼叫搞定。跟总管聊到一半，发现有三件不相干的事要办。立刻展开给三个 Agent — 不用 fleet 文件、不用 YAML，一个工具调用搞定。コンシェルジュと話している途中で、無関係な用事が 3 件あることに気づきました。すぐに 3 つの Agent へファンアウトします — fleet ファイルも YAML も不要、ツール呼び出し 1 つで完了です。컨시어지와 대화하다가 서로 무관한 일 세 가지를 처리해야 함을 깨닫습니다. 즉시 세 Agent에게 팬아웃합니다 — fleet 파일도 YAML도 필요 없이 도구 호출 한 번이면 끝입니다.

# One-time: allowlist the agents this tool may target (DENY-BY-DEFAULT)
# 一次性設定：允許此工具指派的 Agent 清單（預設全部拒絕）
# ~/.mur/config.yaml
parallel_jobs:
  targets:
    - pm
    - qa
    - ghmanager

# The MCP tool call any client (e.g. your concierge) makes:
# 任何 MCP 客戶端（例如總管）發出的工具呼叫：
{
  "jobs": [
    { "description": "audit README for stale commands", "agent": "qa" },
    { "description": "summarize open PRs and CI status", "agent": "ghmanager" },
    { "description": "draft next sprint plan from the backlog", "agent": "pm" }
  ],
  "max_concurrency": 3,      // 1–32, default 8
  "yes": false               // fail-closed: risky steps still gate / 風險步驟仍需核准
}
# → returns { "channel_id": "...", "output": "…all replies…" }

Under the hood MUR builds an in-memory rank-0 DAG — one delegate step per job — and mints an ephemeral channel for the run. Same machinery as jobs 13–14, zero authored files. MUR 底層建出記憶體中的 rank-0 DAG — 每件工作一個委派步驟 — 並為本次執行鑄造一條臨時 channel。機制與任務 13–14 相同，但完全不需撰寫檔案。MUR 底层构建出内存中的 rank-0 DAG — 每件任务一个委派步骤 — 并为本次执行铸造一条临时 channel。机制与任务 13–14 相同，但完全无需编写文件。MUR は内部でメモリ上の rank-0 DAG を構築し — ジョブごとに 1 つの委任ステップ — この実行のために一時的な channel を鋳造します。仕組みはタスク 13–14 と同じですが、ファイルを書く必要は一切ありません。MUR는 내부적으로 메모리상의 rank-0 DAG를 만들고 — 작업당 위임 단계 하나 — 이번 실행을 위한 임시 channel을 발행합니다. 메커니즘은 작업 13–14와 같지만 파일을 전혀 쓸 필요가 없습니다.
The allowlist is out-of-model: a prompt-injected concierge cannot widen the target set — authorization is checked before any channel is created, and an empty list means the tool can't delegate at all. 允許清單在模型之外：被提示注入的總管也無法擴大目標集合 — 授權在建立任何 channel 之前檢查，清單為空則工具完全無法委派。允许列表在模型之外：被提示注入的总管也无法扩大目标集合 — 授权在创建任何 channel 之前检查，列表为空则工具完全无法委派。許可リストはモデルの外側にあります：プロンプトインジェクションを受けたコンシェルジュでもターゲット集合を広げることはできません — 認可はいかなる channel の作成よりも前にチェックされ、リストが空ならこのツールは一切委任できません。허용 목록은 모델 밖에 있습니다: 프롬프트 주입을 당한 컨시어지라도 대상 집합을 넓힐 수 없습니다 — 권한 부여는 어떤 channel이 만들어지기 전에 검사되며, 목록이 비어 있으면 도구는 아예 위임할 수 없습니다.
vs. fleet run: parallel_jobs = N distinct prompts, free assignee per job, one-shot and attended. Fleet = one standing goal, fixed roster, loopable and budgetable. Ad-hoc chores → parallel_jobs; recurring missions → fleet. 與 fleet run 的差別：parallel_jobs 是 N 個不同的提示、每件工作自由指派、一次性且有人看著。Fleet 是單一常設目標、固定名冊、可迴圈可設預算。臨時雜務用 parallel_jobs；例行任務用 fleet。与 fleet run 的区别：parallel_jobs 是 N 个不同的提示、每件任务自由指派、一次性且有人盯着。Fleet 是单一常设目标、固定名单、可循环可设预算。临时杂务用 parallel_jobs；例行任务用 fleet。fleet run との違い：parallel_jobs は N 個の異なるプロンプトで、ジョブごとに自由に割り当てられ、一回限りで人が見守ります。Fleet は単一の常設目標と固定ロースターを持ち、ループ化も予算設定もできます。臨時の雑務には parallel_jobs、定常タスクには fleet を使います。fleet run과의 차이: parallel_jobs는 N개의 서로 다른 프롬프트, 작업별 자유 지정, 일회성이며 사람이 지켜봅니다. Fleet는 단일 상설 목표, 고정 명단, 루프와 예산 설정이 가능합니다. 임시 잡무에는 parallel_jobs, 정례 작업에는 fleet를 쓰십시오.

Speculative tracks: N approaches compete, a judge picks推測賽道：N 種解法競爭，由裁判挑選推测赛道：N 种解法竞争，由裁判挑选投機トラック：N 個の解法を競わせ、審査役が選ぶ추측 트랙: N가지 해법이 경쟁하고 심판이 선택

●●●●Parallel · compete (best-of-N)worktrees

Daily job日常情境日常场景日常のシナリオ일상 시나리오: a gnarly refactor with no obvious best approach. Let two tracks attack it in isolated git worktrees — different philosophies, optionally different models — then compare, judge, and promote the winner. 一個棘手的重構，沒有明顯的最佳解。讓兩條賽道在隔離的 git worktree 裡各自進攻 — 不同哲學、甚至不同模型 — 然後比較、評審、把贏家晉升進主樹。一个棘手的重构，没有明显的最佳解。让两条赛道在隔离的 git worktree 里各自进攻 — 不同哲学、甚至不同模型 — 然后比较、评审、把赢家提升进主树。厄介なリファクタリングで、明白な最適解がありません。2 本のトラックに隔離された git worktree の中でそれぞれ攻めさせます — 異なる哲学、場合によっては異なるモデルで — その後、比較・審査し、勝者をメインツリーへ昇格させます。까다로운 리팩터링인데 뚜렷한 최선의 해법이 없습니다. 두 트랙이 격리된 git worktree 안에서 각자 공략하게 합니다 — 서로 다른 철학, 심지어 다른 모델로 — 그런 다음 비교하고 심사해서 승자를 메인 트리로 승격합니다.

# Add a parallel: block to ~/.mur/fleets/refactor/fleet.yaml (hand-edit)
# 在 fleet.yaml 手動加入 parallel: 區塊
parallel:
  mode: speculative
  tracks:
    - name: track-functional
      approach: "functional style, minimize allocations"
      model: claude-opus-4-8          # optional per-track model / 每軌可選模型
    - name: track-iterative
      approach: "performance first, keep it imperative"
  judge:
    model: claude-opus-4-8
    rubric: { correctness: 0.40, design: 0.30, maintainability: 0.20, security: 0.10 }
  pre_filter: [cargo_check]           # losers that don't compile never reach the judge

# Run with worktree isolation (from the repo root) / 在 repo 根目錄以 worktree 隔離執行
$ mur fleet run refactor --worktree      # or: MUR_PARALLEL_EXEC=1 mur fleet run refactor
.worktrees/track-functional/   ← each track codes + commits in its own tree
.worktrees/track-iterative/      每軌在自己的樹裡寫碼並 commit

# Compare, judge, promote / 比較、評審、晉升
$ mur fleet compare refactor
$ mur fleet judge refactor --stats
$ mur fleet cherry refactor --auto --promote --target ~/code/my-service

Each track gets a detached worktree under .worktrees/ with a .parallel-base sentinel (the base commit). Fan-out is auto-capped at min(tracks, cores−2). Worktrees and tracks.json survive the run — nothing committed is ever auto-destroyed. 每軌各有一個 detached worktree（位於 .worktrees/），並帶 .parallel-base 基準戳記。展開數自動封頂為 min(軌數, 核心數−2)。Worktree 與 tracks.json 在執行後保留 — 已 commit 的成果絕不自動銷毀。每轨各有一个 detached worktree（位于 .worktrees/），并带 .parallel-base 基准戳记。展开数自动封顶为 min(軌數, 核心數−2)。Worktree 与 tracks.json 在执行后保留 — 已 commit 的成果绝不自动销毁。トラックごとに detached worktree（.worktrees/ 配下）が 1 つずつ用意され、.parallel-base のベースラインスタンプが付きます。ファンアウト数は自動的に min(軌數, 核心數−2) に上限が設けられます。Worktree と tracks.json は実行後も残ります — commit 済みの成果が自動的に破棄されることは決してありません。트랙마다 detached worktree(.worktrees/ 아래) 하나와 .parallel-base 기준 스탬프가 붙습니다. 팬아웃 수는 자동으로 min(軌數, 核心數−2)로 상한이 걸립니다. Worktree와 tracks.json은 실행 후에도 보존됩니다 — commit된 성과물은 절대 자동 삭제되지 않습니다.
A collision guard snapshots the main checkout before/after — any agent that strays out of its worktree into the main tree is reported. 碰撞防護會在執行前後對主 checkout 拍快照 — 任何越界跑進主樹的 Agent 都會被回報。碰撞防护会在执行前后对主 checkout 拍快照 — 任何越界跑进主树的 Agent 都会被上报。衝突ガードは実行の前後でメインの checkout のスナップショットを取ります — メインツリーに越境した Agent はすべて報告されます。충돌 가드는 실행 전후로 메인 checkout의 스냅샷을 찍습니다 — 경계를 넘어 메인 트리로 들어간 Agent는 모두 보고됩니다.
--worktree is one-shot only (incompatible with --loop). This is the compete topology: same goal, independent attempts, an independent judge selects. --worktree 僅限單輪（與 --loop 不相容）。這是 compete 拓撲：同一目標、彼此獨立的嘗試、由獨立裁判選出優勝。--worktree 仅限单轮（与 --loop 不兼容）。这是 compete 拓扑：同一目标、彼此独立的尝试、由独立裁判选出优胜。--worktree は単一回のみです（--loop とは併用不可）。これは compete トポロジーです：同一の目標、互いに独立した試行、独立した審査役による勝者の選出。--worktree는 단일 회차 전용입니다(--loop와 호환되지 않음). 이것은 compete 토폴로지입니다: 같은 목표, 서로 독립적인 시도, 독립 심판이 승자를 선정.

Partition one file, merge deterministically分割單一檔案，確定性合併分割单一文件，确定性合并単一ファイルを分割し、決定的にマージする단일 파일 분할, 결정적 병합

●●●●Parallel · partition (coupled-write)

Daily job日常情境日常场景日常のシナリオ일상 시나리오: one big file needs several independent edits (say, implementing three TODO blocks). Split the file into per-track slices, edit in parallel worktrees, then merge back mechanically — no LLM in the merge. 一個大檔案需要多處彼此獨立的修改（例如實作三段 TODO）。把檔案切成每軌一片，在平行 worktree 中修改，再機械式合併回來 — 合併過程不經 LLM。一个大文件需要多处彼此独立的修改（例如实现三段 TODO）。把文件切成每轨一片，在并行 worktree 中修改，再机械式合并回来 — 合并过程不经 LLM。大きなファイルに、互いに独立した複数の修正が必要です（たとえば 3 か所の TODO を実装する）。ファイルをトラックごとに 1 スライスずつ切り分け、並列の worktree で修正し、機械的にマージして戻します — マージの過程に LLM は介在しません。큰 파일 하나에 서로 독립적인 수정이 여러 군데 필요합니다(예: TODO 세 구간 구현). 파일을 트랙당 한 조각으로 잘라 병렬 worktree에서 수정한 뒤 기계적으로 다시 병합합니다 — 병합 과정에 LLM이 개입하지 않습니다.

# fleet.yaml: switch the parallel block to partition mode
# fleet.yaml：把 parallel 區塊切到 partition 模式
parallel:
  mode: partition
  tracks:
    - { name: track-a, approach: "implement the parser TODOs" }
    - { name: track-b, approach: "implement the formatter TODOs" }
  judge: { model: claude-opus-4-8 }
  partition:
    target_file: src/widget.rs        # repo-relative / 相對 repo 根目錄

# Preview how MUR will slice the file (run from repo root)
# 預覽 MUR 會怎麼切這個檔案（在 repo 根目錄執行）
$ mur fleet partition-plan refactor

# Execute in worktrees, then merge slices back / 在 worktree 執行，再把切片合併回來
$ mur fleet run refactor --worktree
$ mur fleet merge refactor --promote --target ~/code/my-service

This is the coupled-write topology done safely: writes to one artifact are only parallelized after being made disjoint by construction (each track owns its slice), so the merge is deterministic reassembly, not conflict resolution. 這是 coupled-write 拓撲的安全做法：對同一產出物的寫入，先從結構上切成不相交（每軌擁有自己的切片）才平行化，因此合併是確定性重組，不是衝突調解。这是 coupled-write 拓扑的安全做法：对同一产出物的写入，先从结构上切成不相交（每轨拥有自己的切片）才并行化，因此合并是确定性重组，不是冲突调解。これは coupled-write トポロジーの安全なやり方です：同一の成果物への書き込みを、まず構造的に互いに素へ分割してから（各トラックが自分のスライスを所有）並列化します。そのためマージは決定的な再組み立てであり、コンフリクトの調停ではありません。이것이 coupled-write 토폴로지의 안전한 방식입니다: 같은 산출물에 대한 쓰기를 먼저 구조적으로 서로소가 되게 분할(트랙마다 자기 조각 소유)한 뒤에야 병렬화하므로, 병합은 결정적 재조립이지 충돌 조정이 아닙니다.
Merged output lands in ~/.mur/fleets/refactor/cherry-result/ before --promote copies it into the live tree. 合併結果先落在 ~/.mur/fleets/refactor/cherry-result/，--promote 才複製進正式樹。合并结果先落在 ~/.mur/fleets/refactor/cherry-result/，--promote 才复制进正式树。マージ結果はまず ~/.mur/fleets/refactor/cherry-result/ に置かれ、--promote で初めて本番ツリーにコピーされます。병합 결과는 먼저 ~/.mur/fleets/refactor/cherry-result/에 놓이고, --promote를 해야 정식 트리로 복사됩니다.

Concurrent N-way merge of overlapping work重疊成果的並行 N 路合併重叠成果的并发 N 路合并重なり合う成果の並行 N-way マージ겹치는 성과물의 동시 N-웨이 병합

●●●●Parallel · concurrent mergeexperimental

Daily job日常情境日常场景日常のシナリオ일상 시나리오: tracks weren't pre-partitioned and touched overlapping files. Merge everything that's disjoint automatically, and get every real overlap reported — never silently merged. 賽道事先沒有分割，改到了重疊的檔案。所有不相交的修改自動合併，真正重疊的區域則被如實回報 — 絕不靜默合併。赛道事先没有分割，改到了重叠的文件。所有不相交的修改自动合并，真正重叠的区域则被如实上报 — 绝不静默合并。トラックを事前に分割しておらず、重複するファイルに手が入りました。互いに素な修正はすべて自動マージされ、本当に重なった領域はありのまま報告されます — 静かにマージされることは決してありません。트랙을 사전에 분할하지 않았고, 겹치는 파일을 수정했습니다. 서로소인 수정은 전부 자동 병합되고, 실제로 겹치는 영역은 있는 그대로 보고됩니다 — 절대 조용히 병합되지 않습니다.

# Experimental — explicitly opt in / 實驗性功能 — 需明確啟用
$ MUR_PARALLEL_CONCURRENT=1 mur fleet merge-concurrent refactor --stats
Spike-1: 1/834 hunk groups overlapped (rate=0.1%)   → concurrent_stats.json

# Promote only when clean; verified by cargo check, reverted on failure
# 只有乾淨時才晉升；以 cargo check 驗證，失敗自動還原
$ MUR_PARALLEL_CONCURRENT=1 mur fleet merge-concurrent refactor --promote --target ~/code/my-service

Disjoint hunks across all N tracks auto-merge with deterministic, order-independent convergence (merged bytes are identical whatever order tracks land in). Overlapping regions are escalated to you or the judge/cherry flow. N 軌之間不相交的 hunk 自動合併，且收斂具確定性、與順序無關（不論賽道先後，合併位元組完全相同）。重疊區域則升級給你或 judge／cherry 流程處理。N 轨之间不相交的 hunk 自动合并，且收敛具确定性、与顺序无关（不论赛道先后，合并字节完全相同）。重叠区域则升级给你或 judge／cherry 流程处理。N トラック間で互いに素な hunk は自動マージされ、収束は決定的かつ順序に依存しません（トラックの順番がどうであれ、マージ後のバイト列は完全に同一です）。重複した領域は、あなたまたは judge／cherry フローにエスカレーションされます。N개 트랙 사이의 서로소 hunk는 자동 병합되며, 수렴은 결정적이고 순서와 무관합니다(트랙 순서가 어떻든 병합된 바이트는 완전히 동일). 겹치는 영역은 당신 또는 judge/cherry 플로우로 에스컬레이션됩니다.
--promote refuses while any overlap is unresolved, runs cargo check in the destination, and reverts the promoted files if it fails. Convergence is guaranteed; correctness is not — the compile check is the backstop. --promote 在仍有未解重疊時直接拒絕，並在目的地跑 cargo check，失敗即還原晉升的檔案。收斂有保證，正確性沒有 — 編譯檢查是最後防線。--promote 在仍有未解重叠时直接拒绝，并在目标位置跑 cargo check，失败即还原提升的文件。收敛有保证，正确性没有 — 编译检查是最后防线。--promote は未解決の重複が残っていれば即座に拒否し、昇格先で cargo check を実行して、失敗すれば昇格したファイルを元に戻します。収束は保証されますが、正しさは保証されません — コンパイルチェックが最後の防衛線です。--promote는 미해결 겹침이 남아 있으면 그대로 거부하고, 대상 위치에서 cargo check를 실행해 실패하면 승격된 파일을 되돌립니다. 수렴은 보장되지만 정확성은 보장되지 않습니다 — 컴파일 검사가 마지막 방어선입니다.
Fun fact: mining real git-merge history through this classifier measured a 0.1% overlap rate — which is why this simple structural merger, not a CRDT engine, is the shipped answer. 冷知識：用這個分類器回放真實 git 合併歷史，量得重疊率僅 0.1% — 所以最終方案是這個簡單的結構化合併器，而不是 CRDT 引擎。冷知识：用这个分类器回放真实 git 合并历史，测得重叠率仅 0.1% — 所以最终方案是这个简单的结构化合并器，而不是 CRDT 引擎。豆知識：この分類器で実際の git マージ履歴をリプレイしたところ、測定された重複率はわずか 0.1% でした — だからこそ最終的な解はこのシンプルな構造化マージャーであり、CRDT エンジンではないのです。여담: 이 분류기로 실제 git 병합 이력을 재생해 측정한 겹침률은 겨우 0.1%였습니다 — 그래서 최종 해법은 CRDT 엔진이 아니라 이 단순한 구조적 병합기입니다.

Reference參考参考リファレンス참고

Parallel patterns at a glance平行模式總覽并行模式总览並列パターン一覧병렬 패턴 개요

Classify the task's topology first, then pick the primitive. Reads parallelize freely; writes serialize unless made disjoint; one-taste design work stays with a single writer. 先判斷任務的拓撲，再挑原語。讀取可放心平行；寫入除非切成不相交否則序列化；需要單一品味的設計工作交給單一寫手。先判断任务的拓扑，再挑原语。读取可放心并行；写入除非切成不相交否则串行化；需要单一品味的设计工作交给单一写手。まずタスクのトポロジーを見極めてから、プリミティブを選びます。読み取りは安心して並列化できます。書き込みは互いに素に分割できない限り直列化します。単一の審美眼が要る設計作業は単一の書き手に任せます。먼저 작업의 토폴로지를 판단한 뒤 프리미티브를 고르십시오. 읽기는 안심하고 병렬화하고, 쓰기는 서로소로 분할하지 않는 한 직렬화하며, 단일한 감각이 필요한 설계 작업은 단일 작성자에게 맡깁니다.

#	Pattern模式模式パターン패턴	Topology拓撲拓扑トポロジー토폴로지	Entry point入口入口エントリポイント진입점	Reach for it when…適用時機适用时机使いどころ적용 시점	Job任務任务タスク작업
1	DAG step fan-outDAG 步驟展開DAG 步骤展开DAG ステップのファンアウトDAG 단계 팬아웃	explore	`mur workflow run` (same-rank steps)（同 rank 步驟）（同 rank 步骤）（同一 rank のステップ）(같은 rank 단계)	independent commands on one machine (lint + test)單機上互不相依的指令（lint＋test）单机上互不依赖的命令（lint＋test）単一マシン上の互いに依存しないコマンド（lint＋test）단일 머신에서 서로 의존하지 않는 명령(lint＋test)	11
2	Delegation fan-out委派展開委派展开委任ファンアウト위임 팬아웃	explore	`delegate_to` + `--channel-new`	independent agent work with signed, attributable replies互不相依的 Agent 工作，回覆需簽章可歸屬互不依赖的 Agent 任务，回复需签名可归属互いに依存しない Agent の作業で、返信に署名付きの帰属が必要な場合서로 의존하지 않는 Agent 작업, 응답은 서명되어 귀속 가능해야 함	13
3	Fleet broadcastFleet 廣播Fleet 广播Fleet ブロードキャストFleet 브로드캐스트	explore	`mur fleet run`	one standing goal, every member's perspective單一常設目標，需要每位成員的視角单一常设目标，需要每位成员的视角単一の常設目標で、各メンバーの視点が必要な場合단일 상설 목표, 각 멤버의 관점이 필요할 때	14
4	Routed plan路由計畫路由计划ルーティング計画라우팅 계획	explore + depsexplore＋相依explore＋依赖explore＋依存関係explore＋의존성	`mur fleet run` (router DAG)（router DAG）（router DAG）（router DAG）(router DAG)	right member for each sub-task, with ordering子任務各找對的人，且有先後順序子任务各找对的人，且有先后顺序サブタスクごとに適任者が異なり、実行順序がある場合하위 작업마다 적임자를 찾고 선후 순서가 있을 때	16
5	Ephemeral fan-out臨時展開临时展开アドホックファンアウト임시 팬아웃	explore	`parallel_jobs` (MCP)	ad-hoc N distinct chores, mid-conversation, no files對話中臨時的 N 件雜務，不寫任何檔案对话中临时的 N 件杂务，不写任何文件会話中に生じた N 件の雑務を、ファイルを一切書かずに処理する場合대화 중 즉석에서 생긴 N건의 잡무, 파일은 전혀 쓰지 않음	23
6	Speculative tracks推測賽道推测赛道投機トラック추측 트랙	compete	`fleet run --worktree` + judge/cherry	no obvious best approach — try N, select with an independent judge沒有明顯最佳解 — 試 N 種，由獨立裁判選没有明显最佳解 — 试 N 种，由独立裁判选明白な最適解がない — N 案を試し、独立した審査役が選ぶ뚜렷한 최선이 없을 때 — N가지를 시도하고 독립 심판이 선택	24
7	Partition分割分割分割분할	coupled-write	`partition-plan` → `merge`	one artifact, edits made disjoint by construction同一產出物，先從結構上把修改切開同一产出物，先从结构上把修改切开同一の成果物に対し、修正を先に構造的に切り分ける場合같은 산출물, 수정을 먼저 구조적으로 분리	25
8	Concurrent merge並行合併并发合并並行マージ동시 병합	coupled-write (post-hoc)coupled-write（事後）coupled-write（事后）coupled-write（事後）coupled-write(사후)	`merge-concurrent`	overlap wasn't prevented — auto-merge disjoint, escalate the rest事先沒防重疊 — 不相交自動合併，其餘升級處理事先没防重叠 — 不相交自动合并，其余升级处理事前の重複防止なし — 互いに素なら自動マージ、残りはエスカレーション사전에 겹침을 막지 않았을 때 — 서로소는 자동 병합, 나머지는 에스컬레이션	26

The fourth topology — coherence-bound: work needing one consistent voice or design taste (an API's shape, a doc's narrative) should NOT be parallelized. Give it to a single agent (murmur, or one delegate_to) and let the parallel patterns feed it inputs. 第四種拓撲 — coherence-bound（一致性受限）：需要單一聲音或設計品味的工作（API 的形狀、文件的敘事）不應平行化。交給單一 Agent（murmur 或一個 delegate_to），讓各種平行模式為它供應素材。第四种拓扑 — coherence-bound（一致性受限）：需要单一声音或设计品味的工作（API 的形状、文档的叙事）不应并行化。交给单一 Agent（murmur 或一个 delegate_to），让各种并行模式为它供应素材。第 4 のトポロジー — coherence-bound（一貫性拘束）：単一の声や設計の審美眼が必要な作業（API の形、ドキュメントの語り口）は並列化すべきではありません。単一の Agent（murmur または 1 つの delegate_to）に任せ、各種の並列パターンにはその素材を供給させます。네 번째 토폴로지 — coherence-bound(일관성 제약): 단일한 목소리나 설계 감각이 필요한 작업(API의 형태, 문서의 서사)은 병렬화하면 안 됩니다. 단일 Agent(murmur 또는 하나의 delegate_to)에게 맡기고, 여러 병렬 패턴이 그에게 재료를 공급하게 하십시오.