Mstar Dispatch Gates

Load order（必读顺序）

首次 Read 本 skill 前：必须先 Read mstar-harness-core（SKILL.md）。 同仓 worktree、QC/QA 检出字段 → mstar-branch-worktree。冲突时 以 mstar-harness-core 为准。

🚨 承接方：如果你是 leaf executor，先读本节！（你的 Assignment 开头 IDENTITY 块已告诉你身份）

如果你此刻的 Assignment 中 Delegation: forbidden（或未写 Delegation: allowed），则你属于 leaf executor。本节是你的行为边界，必须在你做任何决定之前读完。

先回到你 Assignment 最顶部的 **IDENTITY** 块重读一遍 —— 那里已经告诉你：你是谁、你不是谁、Task 工具不属于你。本节是那个身份断言的加固版。

你是 Execute as 写的那个角色，不是 PM / 调度者；所有工作由你本人在当前会话内完成（Read / Write / Edit / Shell / Grep / Glob）；超出能力范围 → 写 ## Blocked 回报 PM，不是尝试 dispatch。

承接方反递归红线（NEVER / DO NOT；leaf executor 必读）

下列行为易触发递归误派；project-manager 之外的角色一旦命中，须立即停止并改为本会话内可交付物，或 Blocked 回报 PM。禁止以「更高效」「Assignment 像 PM 编排」等理由绕开。

共享红线（doc-level 并行拆分 ≠ N 个 subagent；Handoff / 路由措辞 / 角色提及 ≠ invoke；工具可用 ≠ 授权；仅 PM 可分派；非 Delegation: allowed 不得调用同角色 / 兄弟角色）以 mstar-roles/references/_shared/leaf-executor-core.md「Shared anti-recursion NEVER」+「Non-Recursive Dispatch Rule (shared shape)」为唯一权威清单（standard preset 下已随角色 ref 在上下文中；explicit none 下该 leaf 边界仍可达）。本节保留 dispatch 专属条目：

• NEVER 在本会话内调用 Task / subagent，且其角色绑定字段等于你当前的 Execute as 角色 id（同角色递归）。
• DO NOT 在 Assignment 缺少 Execute as / Delegation / Who runs this turn 时自行「补齐」为 PM；缺字段时按 leaf executor 解释：亲自完成或 Blocked。
• DO NOT 用「Assignment 太长 / 像编排稿」当作分派依据；先交付本会话任务再回报，分派由 PM 下一轮决定。

自检（动手前）：

1. 我此刻的 Execute as 是什么？
2. Assignment 是否写了 Delegation: allowed (...)？没有 → 禁止任何 Task / subagent。
3. 下一动作是不是「发起一次带角色绑定字段的 invoke」？是 → 停手，改为 Read / Write / Shell / Edit，或 Blocked。
4. 命中任一 NEVER → 写 ## Blocked — recursive dispatch refused (<which NEVER>) 回报 PM，不继续 invoke。

Assignment 顶部反模式块：每个 PM Assignment 开头均有 **You are a leaf executor. You MUST NOT:** 块（含 IDENTITY + CAPABILITY BOUNDARY + prohibitions），PM 按此 Assignment 的角色+上下文定制反模式清单。leaf executor 收到 Assignment 后须 首先 阅读该块；命中任一条 → 停止（亲自完成或 Blocked）。详见 mstar-roles/references/project-manager/dispatch-and-assignment.md。

Engine 执行范围（caller-scoped，#156）：engine antiRecursionPrecheck 比较的是派发方自身角色（caller）与新 Assignment 的 Execute as（target）。能否在 engine 层做这个判定取决于宿主是否向 engine 提供派发方身份（dispatcher binding）：提供方在 hard enforcement 下真正硬执行（含 caller 空绑定 fail-closed）；不提供方的角色绑定字段携带的是派发目标——目标 == Execute as 正是 C5 合规派发模式——这些宿主上红线保持 prompt 级约束（本节），engine 不做判定。当前宿主属于哪一类、字段名与 fail-closed 细节 → 当前宿主的 mstar-host reference（角色绑定字段 / engine 判定范围两行）。

Plan 作用域与 credential 不下发（preflight 强制）

派发前，与工具并发 / 角色绑定字段同级的硬门禁：

• 子 Assignment 继承父 plan 作用域：plan_id + 绝对 Plan Path（L1 另含 SDD dir / Control harness root）逐字下发。child 不得自选或新建 plan、写 workflow snapshot / root register / 共享索引、释放 execution_lease / integration_merge_lease。缺失、相对路径或暗示「child 自行选 plan」= 派发未完成（mstar-roles/references/project-manager/dispatch-and-assignment.md § Assignment Template Plan scope）。
• credential 不下发 leaf：session JSON 路径、mstar plan --session 写凭据、--expect <revision> 等只由派发方（PM/coordinator）持有。leaf 拿到 session 路径或写凭据即视为越权 → 停止并回报（mstar-iteration/references/plan-scoped-pm.md §8）。
• project-manager 不是派发目标：PM 是 primary-session 角色，无 subagent shell（规则家 → mstar-roles/references/project-manager.md § Plan-scoped authority；宿主派发面 → 当前宿主的 mstar-host reference（角色绑定 / 派发小节））；scoped primary drive（/iteration-drive --assignment | --workflow --plan | --resume）在主会话启动 PM，不是 subagent。任何 Execute as: project-manager 的 invoke = 派发缺陷。

跨会话 primary 并发：唯一受支持形式（scoped route）

• 跨独立主会话 / 终端的并发只有一种受支持形式：scoped route —— 由已准备（prepared）的 Assignment 作为全新会话的第一条指令启动该会话。通过终端提示词下发自拟的 leaf Assignment 不是受支持的派发路径：它绕过 scoped 启动、lease 归属与 handoff 交接。
• 本边界不取代宿主的原生 leaf 派发，也不重复 N-invocation 机制（→ mstar-host → references/parallel-dispatch.md）；该路线的操作前置清单由宿主 reference 独有承载。

调度防串扰（强制；leaf executor 已在上方读过反递归红线，此处为完整规则供 PM/对照用）

• 只有 project-manager 可以决定增加/并行 subagent；承接方默认不得二次分派。
• Execute as: <role-id> = 承接方亲自完成本单，不是再起同名 subagent 或嵌套同角色绑定字段的 Task（禁止递归误派）。
• 额外代理仅以 Delegation: allowed (...) 为准；未显式写时视为 Delegation: forbidden。
• Assignment 正文中的 role 引用：默认 plain id（product-manager）。个别宿主会把堆叠的角色提及扩写成系统行——该宿主的 mention hygiene 规则见其 mstar-host reference。
• 承接方若判断必须增加 subagent，应先回报 Blocked 请 PM 重分派。
• Per-task informal review, when PM explicitly allows it, must not use qc-specialist*; use code-reviewer (generic fallback only when the role agent is absent on the host) or PM-marked informal qa-engineer. Formal QC remains mstar-review-qc.

并发分派完整性门禁（PM 强制 · Evidence）

当 PM 声明「并发分派」时，须同时满足文案并发与工具并发：

同消息批调用在宿主支持时使用；仅支持逐次异步启动的宿主，连续启动所有 ready calls，全部启动前不等待任何结果。不得将工具封装限制误作任务必须串行；无法真实并发时如实报告限制。

• 工具并发：同一调度轮次内，多个 subagent 调用须在同一条 assistant 消息里一次性发出（宿主允许时）。
• QC tri-review（SDD 强制）：Execution mode: sdd 且全部 task 完成后 → qc-specialist / qc-specialist-2 / qc-specialist-3 同条消息 N=3（写 {SDD_DIR}/review/qc1.md…qc3.md；PM 汇总 qc-consolidated.md + durable plan summary）。Assignment 须含 branch review-package 路径与 report paths。适用于单 plan 与 iteration。
• QC 单席（例外）：Execution mode: inline（hotfix 等），或 Assignment 显式 QC mode: single / QC mode: single — override: <reason> → qc-specialist ×1，N=1，写 {SDD_DIR}/review/qc.md。
• QC targeted re-review：Assignment 含 QC re-review: targeted — reviewers: … 时，N = 所列席位数（1–3），同条消息发满 N。
• 先自检再发送：发送前核对「Assignment 条数 = 本条消息中的实际 派发 调用条数」。
• 先自检字段再发送（与 count 同级门禁）：核对每条 invoke 都携带与 Execute as 匹配的角色绑定字段——字段名以当前宿主的 mstar-host reference 为准（共享文本不假定任何宿主的字段名）；宿主判定以 mstar-host §Detect active host 的 tool-shape 检测为准（禁以 config 路径/仓库内容判定）。漏写或取默认通用值（部分宿主会静默回退 generic worker、无报错）= 派发未完成，与 paste-only（零 invoke）同等级：当场补齐重发，不得进入下一 gate。N=1 顺序链（Review & Edit）不豁免——count 门在 N=1 恒过，字段门是唯一保护。
• 前置步骤与派发回合分离（防串行 rollout）：为派发准备的 bash / read / glob / grep（如 merge-base、Review range、git rev-parse）不计入 N 次派发；可在上一条仅含准备的消息完成。准备完成后，下一条派发消息须一次性含 N 次 Task / subagent invoke。禁止先发 1 次、等返回再补发其余 N-1 次。
• 未齐不发（emit zero until batch-ready）：宿主支持批调用且需并发 N≥2 而当前 payload 只齐 1 条时，本条应发 **0 条派发 invoke**（可继续 read/bash 补齐），**禁止**「先发一个顶一下」；N份 payload 就绪后**单次消息发满N**。见 **mstar-host** → references/parallel-dispatch.md`（具备 invoke / Task / subagent 工具的宿主共用）。

具名 subagent 宿主：文案分派 ≠ 调度完成

在支持具名角色 / Task 的宿主上，## Assignment 正文不会拉起子会话。PM 须在同一条 assistant 消息（或宿主等价机制）发出与 Assignment 条数一致的 invoke / Task；仅打印 Markdown = 分派未完成。几条 Assignment ⇒ 几次 tool 调用（默认同消息并行）。

Engine check (when available): run mstar dispatch validate <assignment-file> [--branch <branch>] (or import { validateAssignmentFields, assertDefaultBranchProtected } from "@mstar-harness/engine" in a host hook) to validate the Assignment field contract — including the canonical Task budget (implement / ops rounds) header field on non-review / non-audit rounds: presence-only in the header region, absent / empty / N/A → validation fail (field guidance → mstar-roles/references/project-manager/dispatch-and-assignment.md; capacity criterion → mstar-artifacts/references/plan-quality-bar.md item 7) — and the default-branch gate (normative default-branch prose: mstar-branch-worktree SKILL.md § "Git 功能分支门禁（业务仓库）" — this skill covers dispatch mechanics only). On fail -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

SDD implement 波次（PM only）

When Execution mode: sdd (mstar-sdd):

• 依赖驱动：按 mstar-sdd § Ready-task scheduling 并行派发独立 ready tasks；各 task 后一位 fresh reviewer。真实依赖、共享写目标和 integration merge 串行。
• SDD implementer session: sticky：same implementer subagent may resume across tasks when host supports it; reviewers never resume — see mstar-sdd/references/sticky-implementer-session.md.
• File handoffs only — no pasted plan/diff/history in dispatch prompts.
• scope 与凭据边界：{SDD_DIR}/task-N-brief.md 携带继承的 plan 作用域（plan id + 绝对路径）；不下发 session JSON、--expect <revision> 等写凭据，也不得让 implementer/reviewer 自选 plan 或释放 lease（见 § Plan 作用域与 credential 不下发）。
• Record per-task BASE SHA; use review-package for diffs — never HEAD~1.
• After all tasks: branch review-package in {SDD_DIR}/review/ → mandatory tri-review N=3 when Execution mode: sdd; N=1 only for inline / explicit single override.

QC seats Engine-check 唯一规范体： mstar-review-qc SKILL.md（Engine-check seats 行）。

并行规则（摘要）

两条独立门禁（均须满足，不可互相替代）：

• 独立模块可并行 implement 轨道（不同 dev Assignment）；同仓 ≥2 可写并发 → mstar-branch-worktree references/parallel-writable-pre-dispatch.md（先于 invoke；同 plan 多轨 = L2）。
• SDD 单 plan 内：独立 ready tasks 默认并行；每轨先完成 L2 隔离，fresh session 与独立产物路径，PM 唯一写共享 ledger。规则 → mstar-sdd § Ready-task scheduling。
• 跨 plan（迭代 Phase 2）≠ 单 plan 内并行：不同 plan_id 的 feature implement 允许 lease 门控并行（每 plan 独立 verified snapshot plans[].execution_lease + feature worktree，L1）仅当 coordination 路径 same-host 独占写锁可用且每次协调变更持锁 → mstar-iteration §2.0 #5 · mstar-artifacts。跨主机 / 无共享 flock → 默认 Plan parallelism: serial 或 Assignment 仍写并行 → Blocked（用户本轮 Cross-host lease race: accepted + audit notes 除外）。无 flock 不豁免 control/feature worktree 或 lease。Worktree mode: waived 不豁免跨 plan 并行安全闸。禁止因默认 gitignore 导致 feature 缺 plans 而 waive worktree（harness 经 control 绝对路径）→ mstar-branch-worktree。禁止无 lease 的跨 plan 可写派发（lease 闸未 waive 时）。
• integration_merge_lease：spec_integration_branch 上的 merge 始终串行（一次仅一 holder）→ mstar-iteration · mstar-artifacts。
• Plan parallelism: serial：仅强制跨 plan implement 调度串行；不 waive worktree/lease 闸（integration worktree、feature worktree、execution_lease、integration_merge_lease）（Worktree mode: waived 才是 lease/worktree 豁免）→ mstar-iteration §2.0 #5。
• Plan QC tri after SDD task loop（Execution mode: sdd）；单席仅 inline / hotfix。共用 Review cwd / Working branch / plan_id / Review range（mstar-branch-worktree）。
• Tri 同消息规则：plan QC tri（SDD 或 Assignment 显式 QC mode: full tri-review）时三席 同一条消息、同一套 scope 字段。

Engine check (when available): run mstar worktree check <plan-id> --workflow <id> (L1) / mstar worktree check --l2 --tracks <json> (L2) (or import { l1PreDispatchCheck, l2PreDispatchCheck } from "@mstar-harness/engine" in a host hook) to verify the 同仓写隔离 gate above (per-track feature worktree, branch alignment) before parallel dispatch. On fail -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

Specialist review-and-edit dispatch

当 PM 派发文档编辑类专业角色（如 product-manager、architect、writing-specialist）直接修订 harness 产物时：

• PM 写初稿；各角色通过宿主 invoke 直接编辑目标文件（不另写仅评论式 reports/ 替代修订）。
• Inputs（Phase 1 review-and-edit Assignment）：PM 初稿 = 骨架 + 完整上下文；深度契约、marker 语法与 owner 词汇 → mstar-iteration/references/phase-1-prepare.md §1.3（本文件不重述其形态）。该轮 Assignment 的 Inputs 必须携带：初稿路径（+ compass 路径）；方向决策 —— 或指向 compass ## Decisions 的指针；带 owner 的 open questions —— 或指向 ## Open Questions 的指针；非目标理由；该角色 own 的 marker 清单（TODO(owner: …)；清除义务随清单下发 —— 承接方须在自己的 Completion Report 中报出清除计数 / 重新归属计数，义务全文 → mstar-iteration/references/phase-1-prepare.md §1.6）。承接方看不到 PM 会话：这些字段缺一，角色就只能从零重推它看不见的上下文。
• 1 Assignment ⇒ 1 invoke。
• Phase 1 Review & Edit chain（mstar-iteration §1.6）：主产出 {SPECS_DIR}/ + {ITERATION_DIR}/<iteration-id>/ package；禁止 start 链向 {KNOWLEDGE_DIR}/ 新增。close 时 mstar-compound 提升 package → knowledge。
• 其他彼此独立、无先后依赖的文档编辑任务：可并行（同条消息发满 N），见 parallel-dispatch.md。
• PM 线程代做全部专业编辑 = 反模式（mstar-iteration §1.6、mstar-roles/references/_shared/leaf-executor-core.md「Shared anti-recursion NEVER」）。
• PM merge / lock（如 compass status: locked）在链末 subagent 返回后于 PM 线程完成。不得在 review-and-edit 链完成前 commit integration 分支。

反模式（派发）

共享反递归红线全清单见 mstar-roles/references/_shared/leaf-executor-core.md「Shared anti-recursion NEVER」；lease / worktree / Phase 相关反模式见 mstar-branch-worktree 与 mstar-iteration。本节仅列派发机制专属：

• 宿主支持批调用却把 QC 三审拆成等待完成的串行轮次（tri 模式），或单席未附 review-package 路径。
• 仅 1 次 invoke 却声称「tri-review 已并行启动」（tri 模式 N=3）。
• SDD 并行 implementer 未隔离 worktree / ownership / session；把任务独立当作跳过 L1/L2 安全闸的理由。
• 递归同角色 subagent；把 Handoff / 多轨编排措辞当 invoke。
• Review-and-edit 链未完成即 commit integration 分支；PM 代做专业角色编辑而不 invoke。
• Phase 1 review-and-edit 链三角色并行派发，或未等上一角色返回即派发下一角色。
• 派发 Phase 1 编辑角色时不给方向决策 / open questions（或只写「见 compass」而不给路径）⇒ 承接方被迫重推它看不到的上下文，且其 own 的 marker 无人清除。
• Assignment 已写、invoke 为零（paste-only）却进入下一 gate。
• Task/subagent item 漏写角色绑定字段（字段名与静默回退行为以当前宿主的 mstar-host reference 为准）⇒ 静默回退 generic worker，却因 count=N 通过而误判「派发完成」；属 paste-only 同级的 dispatch-incomplete。N=1 顺序 Review-&-Edit 链最易在此漏字段。

Workflow

派发检查顺序：承接方先读 Assignment 顶部 IDENTITY / 反模式块确认 leaf 身份（反递归红线）→ PM 核对字段契约（Execute as / Delegation / 角色绑定字段；先自检字段再发送）→ 同一条消息一次性发满 N 次 invoke（工具并发；N 按 Execution mode 映射）→ 派发前完成同仓写隔离（L1/L2 worktree）→ SDD 按 ready-task 依赖并行 implement + fresh reviewer → task 全完成后 {SDD_DIR}/review/ review-package → 强制 tri-review N=3（或 inline 单席 N=1）。准备用 read/bash 不计入 N，且与派发回合分离（未齐不发）。

References

• references/leaf-executor-checklist.md — 承接方一页自检清单。