Maestro 后台 agent 处理任务的当前实现规则（非设计提案，是线上真实行为）。按复杂度路由分四类执行路径：① 任务拆解（HARD）· ② 方案撰写（MEDIUM）· ③ 任务执行（executor）· ④ 解冲突（conflict），外加跨类通用规则与模型档位。
任务按 complexity（可由 auto 让模型判定）走不同路径；只有产生代码改动的任务才过 exec_review（双复审 + 合并）。
| 复杂度 | 路径 | 人审闸 | 谁来做 |
|---|---|---|---|
| EASY | init → ready → queued → executing → exec_review → done | exec_review | executor（直接执行） |
| MEDIUM | init → speccing → spec_review → ready → … → exec_review → done | spec_review + exec_review | planner 写方案 → executor 执行 |
| HARD | init → analyzing → plan_review → decomposed →（子任务各自跑）→ done | plan_review +（各子任务的闸） | planner 拆解 → 子任务递归 |
runs.kind）：planner（拆解 HARD / 写 MEDIUM 方案，只读）· executor（worktree 内改代码）· reviewer / security（执行后双复审，只读）· conflict（解合并冲突，本会话新增）。analyzing 态，起一个 planner run。Read / Glob / Grep + Bash(git log/diff/show)。claude-opus-4-8（项目可配）；maxTurns=90。done · 项目 autonomy ≠ manual。depth ≤ 4（根=1），prompt 注入「剩余可拆层数」；子任务只有在剩余层数 > 0 时才允许再标 hard（防无限拆）。title · complexity(easy/medium/hard) · priority(0/1/2) · deps(依赖本列表的 0-based 序号) · files(文件范围 glob)。files = 该子任务预计改动的文件范围；执行时改越界文件会被硬闸拦截，故须尽量精确，不确定留空数组（不限）。{plan, subtasks:[…]}——给机器解析。解析失败 = planner 失败、退避重试。plan（一句话理由）→ 存父任务 plan 字段（即评审界面的「说明」）；priority、files→scopeFiles 直接落库；deps 先全建好子任务再做「序号→taskId」二次映射写依赖；plan_review 人审。auto-approved + autoApprovePlan 开 + 拆解结果全 easy + 子任务数 ≤ 5，四条全满足才跳过人审直接 decomposed。plan_review / analyzing 期间，子任务被冻结（不可领取，UI 显示「待拆解确认」）。failPlanAttempt 退避重试，超 maxRetries（默认 2）→ 转 needs_attention 待人工；decomposed 后，子任务全 done → 父任务自动 done。speccing 态，起 planner run（与拆解同为 planner kind，但只读写「方案」不拆子任务）。maxTurns=60。spec 字段。spec_review 人审；批准后 → ready 进执行队列。reject 须带意见，回流 speccing 重写。maestro/<taskId>，从 defaultBranch(main) 拉出）；permissionMode=acceptEdits。Read/Edit/Write/Glob/Grep + git(status/diff/log/add/commit，无 push) + 测试/构建（npm/go/pytest/make…，仍关在 worktree、不发包）；maxTurns=100。project.model 也覆盖 executor）。ensureCommitted 兜底）。origin/main 并进 worktree；若撞上本任务声明范围内的文件改动 → 转 needs_attention 待重评估（不盲目硬解）。verifyCmd 在 worktree 内跑（10min，exit 0 才过；未配=视为通过）。exec_review 人审；accept 触发 --no-ff 自动合并回 main（merge:false 可跳过合并）。auto-approved + autoApproveExec 开 + 双复审均 approve → 跳过人审自动合并。runKind=conflict 跑。git merge <原分支> 触发冲突态，再交 CC 逐个解（白名单额外含 Bash(git merge:*)）。| 规则 | 说明 |
|---|---|
| 执行期锁 | 任务一旦有在途 run（planner/executor/reviewer/conflict）→ 锁定只读：禁改 title/spec/complexity/deps、禁再调度；run 结束（finish/fail/reap）解锁。 |
| worktree 隔离 | 写类 run 只在自己 worktree 内改动，禁碰 worktree 外文件；planner/reviewer 只读、不建 worktree。 |
| 不 push / 不部署 | 任何 run 都不得 git push / 对外发布；解冲突的 merge 是受控本地合并。 |
| commit 含 task ID | 所有产出 commit message 必带任务 ID，ensureCommitted 兜底。 |
| 重试退避 + 升级 | 失败按退避重试，超 maxRetries（默认 2）→ needs_attention 转人工（planner 留原态、executor 走 failed）。 |
| 自动放行默认关 | 所有「跳过人审」（plan/exec）默认关闭，须项目级开关 + auto-approved 才生效。 |
| reject 必带意见 | plan/spec/exec 的驳回必须带 reason，按状态机回流重做。 |
| 复审独立性 | 复审只读、与执行分离、用最强模型、不被 project.model 降档；verdict=reject 是硬闸。 |
| daemon 唯一 DB 写者 | worker 不碰 DB，只读 job.json、写 outbox.ndjson；状态变更只经 transition() 守卫。 |
| 超时分层 | planner/executor 30min（可配）· verify 10min · 复审 15min（并行）· conflict 给足强档时间。 |
内置默认：每个角色 × 每个复杂度都是 claude-opus-4-8（DEFAULT_MODEL）。可按项目经 projects.models(JSON) 配置。
解析优先级（高→低）：① project.models[role]（per-role，含 reviewer/conflict）→ ② 旧 project.model（仅 executor/planner）→ ③ env（MAESTRO_MODEL_* / _REVIEW_* / _PLAN_*）→ ④ DEFAULT_MODEL。
四角色：executor / planner / reviewer / conflict。不可用回退链：opus-4-8 → sonnet-4-6 → fable-5（单 run 内只重试一次）。
claude-fable-5 在部分环境不可用，已移出内置默认；原「按复杂度分档（hard=fable / medium=opus / easy=sonnet）」的设计因此改为统一 opus-4-8 + 项目可配。| 从 | 到 | 触发 |
|---|---|---|
init | analyzing / speccing / ready | 按 hard / medium / easy 路由 |
analyzing | plan_review | 拆解完成 |
plan_review | decomposed / analyzing | accept / reject(+意见) |
speccing | spec_review | 方案完成 |
spec_review | ready / speccing | accept / reject(+意见) |
ready | queued / blocked | 领取 / 依赖未满足 |
queued | executing | worker 起跑 |
executing | exec_review / failed | 执行完成 / 失败 |
exec_review | done / ready | accept(合并) / reject(返工) |
failed | queued / needs_attention | 重试 / 超阈值 |
decomposed | done | 子任务全 done |
完整合法转移表见 src/model/status.ts 的 TRANSITIONS；状态机/ER 全图见 优化方案文档 ⑤⑥ 节。