Mstar Phase Gates

Load order（必读顺序）

首次 Read 本 skill 前：必须先 Read mstar-harness-core（SKILL.md）。 {PLAN_DIR} / plan 文件落盘见 mstar-conventions。冲突时 以 mstar-harness-core 为准。

Spec-Driven 双阶段门禁（非热修强制）

A. Prepare：specify → clarify → plan

• specify — 问题陈述、用户价值、范围/非目标、DoD 草案。
• clarify — 关键歧义清单与结论；高影响歧义必须收敛，否则 Blocked。
  • 意图核对（Intent gate）：区分用户字面表述与待解决的真正问题；手段与目标混淆须在此收敛。
  • 结构化澄清：宿主提供 question 工具时优先使用；否则用结构化正文选项。宿主细节在各自的 mstar-host skill。
  • clarify 核心纪律（Prepare）：对 plan/方案的每个方面持续核对，直到与用户达成共享理解；沿设计决策树逐枝下行，一次只收敛一个决策点及其依赖，再进入下一枝。
    1. 能查库则查库：若问题可通过探索代码库（实现、配置、{SPECS_DIR}、{KNOWLEDGE_DIR}、{ITERATION_DIR} 等）得到答案，先探索、不向用户提问。
    2. 每问带推荐：每个仍需用户确认的问题，须给出推荐答案（及简短理由），便于快速对齐。
    3. 收口摘要：clarify 结束前列出：已决事项、仍 open 的假设、对 plan 的约束。
• plan — 技术方案、长期目标状态、模块边界/接口契约、风险与回滚点、验证计划。
  • 意图门禁：锁 plan 前须能书面写清真实目标 / 成功判据 / 非目标三项；否则 Prepare 未通过。
  • 长期方案优先：默认先设计目标状态，再裁剪本轮可交付切片；不得以“临时方案 / 混合方案 / 以后再说”替代目标设计。
  • Durable Roadmap Gate：若本轮只做部分范围，plan 必须写明 roadmap（批次、依赖、暂缓项、owner/触发条件、最终完成定义）。只有一句“后续再做 / next plan”视为未通过 plan gate。
  • Recall receipt（锁 plan 前）：记录相关 knowledge/research 输入——复用与被否决策一并注明；无适用输入时如实记空。不做全库扫描、不发明知识；收据缺失不进入 plan lock。语义 → mstar-artifacts/references/plan-workflow-lifecycle-contract.md。

B. Execute：plan(locked) → tasks → implement

• plan(locked) — 冻结基线；实现中出现新约束时先回写 plan 再继续。
• tasks — 含依赖顺序、并行标记、完成判据；每任务可追踪到 plan、roadmap 批次与验收标准。每任务还须满足单轮容量判据（声明 Effort band、单轮闭合其 Files 与验证门、写明 split point）→ mstar-artifacts/references/plan-quality-bar.md item 7（Task shape / session fit）。
  • 并行标签：≥2 条实现轨同时分派 → Dispatch mode: parallel independent tracks；同仓可写并发 → Worktree isolation: required（清单 mstar-branch-worktree → references/parallel-writable-pre-dispatch.md）。
• implement — 按 tasks 顺序执行；多 task plan 默认 Execution mode: sdd（mstar-sdd）；hotfix 可 inline。完成进入 InReview；遵循 mstar-coding-behavior。

可验证编辑与上下文纪律

• 读后再改：修改文件前以磁盘内容为准重读（Read/等价工具）。
• 小步应用：Patch 失败禁止在同一过时锚点连试；重读、缩小变更单元或拆步。
• 多文件改动：逐项核对路径与引用，避免未验证的批量替换。

Hotfix 例外

压缩路径与事后补记见下文 § Hotfix 例外（Playbook 末尾）。

Phase Gate Playbook

执行动作与最小产物见上文 § Spec-Driven 双阶段门禁。本节仅 Playbook 补充（不重复 Prepare/Execute 长文）。

Execute 补充（Playbook 专有）

• plan locked
  • 最小动作：在 plan 或 notes 记录当前锁定版本（日期或 hash）。
  • Plan 质量门（新 plan / 大改）：无 placeholder（...、TBD、etc.）—— 该判定在 plan(locked) 时点执行。Prepare 期间唯一被认可的未完成形态是带 owner 的 TODO(owner: …) marker（语法、owner 词汇与清除口径 → mstar-iteration/references/phase-1-prepare.md §1.3；清除期限按路线取：迭代初稿 = compass status: locked（不是该 plan 的 plan(locked) 时点）；独立 plan（无 compass）= 本节 plan(locked) 时点）；无 owner 的 placeholder 在任何阶段都不被接受。含 Global Constraints 与 per-task Interfaces；PM self-review 四问（每 task 可独立验证？依赖顺序清晰？无隐含假设？每 task 可单轮闭合其 Files 与验证门 — Task shape / session fit？→ mstar-artifacts/references/plan-quality-bar.md item 7）— 见 mstar-artifacts/templates/plan.main.md + mstar-artifacts/references/plan-quality-bar.md（自包含/验证门/STOP 条件/drift check/done criteria）。
• implement
  • 最小产物：实现 diff、自检证据、回报与 handoff；行为准则 → mstar-coding-behavior；编辑纪律 → 上文「可验证编辑与上下文纪律」。
  • 知识库 / 迭代 compass：默认开工前扫 {KNOWLEDGE_DIR}/README.md 索引（若存在）并阅读与当轮相关的 Active 行（即使 metadata 无 knowledge 链接）；若 plans[].metadata 登记了 primary_spec / spec_refs / iteration_compass / iteration_refs，所链接文档仍须阅读；两类阅读均须在回报中说明已对齐 → mstar-conventions · mstar-artifacts/references/knowledge-and-designs.md。该 implement 时阅读是输入变化时的 re-alignment，不替代 Prepare 的锁前 recall receipt（见上文 Prepare plan 节）。

角色职责

• @project-manager
  • 负责门禁判定与 Assignment 中的 Phase Gate Checklist。
  • 在 Status Update 汇报当前 gate 状态。
• 开发角色（@frontend-dev / @fullstack-dev / @fullstack-dev-2）
  • 仅在 Execute gate 放行后开始实现。
  • 发现新约束时先回报并请求回写 plan。
• @qa-engineer — when QA gate: mandatory, L4 per mstar-roles/references/qa-engineer/acceptance-gate.md; pm-acceptance is PM-only (qa-trigger-matrix.md).

迭代级活动

per-plan 门禁通过后，PM 在迭代层面管理以下活动（不计入 per-plan gate）：

• 迭代启动（mstar-iteration § Phase 1）：锁定迭代范围、显式 branch policy（iteration_base_branch / target_branch）、产出 compass。
• 迭代驱动（mstar-iteration § Phase 2 Autonomous Execute）：per-plan 派发循环（分支→实现→QC→QA gate→Done→合并），跨 plan 进度追踪，更新 compass 中各 plan 状态。
• 迭代收口（mstar-iteration § Phase 3 iteration-close）：迭代内所有 plan Done 后，执行一轮知识结晶（mstar-compound）沉淀迭代经验，更新 roadmap，标记迭代完成。

per-plan Done 是 per-plan 的闭环终点；compound 是迭代级收口活动，不影响 per-plan 状态判定。此句不否定独立交付 plan 的 disposition 义务——它在交付 PR head 定稿前运行（迭代内 plan 行不各自触发）；语义权威 → mstar-artifacts/references/plan-workflow-lifecycle-contract.md。

Engine check (when available): run mstar iteration gate --workflow <id> --compass <delivery-compass.md> (or import { evaluatePhaseGate } from "@mstar-harness/engine" in a host hook) to evaluate the iteration phase-transition gate (Phase 2 → 3 → 4) against the workflow snapshot when iteration-level activities above are reached — per-plan Prepare/Execute gate judgment stays prompt. On fail (gate-blocking violations) -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

Plan 目录与审查证据（启用 {PLAN_DIR} 时）

• 进入 InReview 后，QC/QA 原始过程报告默认落入 {SDD_DIR}/review/（SDD 默认 tri qc1…qc-consolidated；inline 单席 qc.md）。fix 后默认 targeted re-review。SDD per-task review 在 implement 波次内完成（mstar-sdd task reviewer）。PM 将 durable gate summary 回写主 plan / workflow snapshot，而不是把 raw reports 作为默认 git 产物。
• 非阻断项与后续技术债：PM 汇总后写入 project register {PROJECT_DIR}/<id>/residuals.json → entries[<plan-id>]（open，默认 {HARNESS_DIR}/projects/<id>/；canonical 见 mstar-artifacts SKILL.md）；关闭时在 register 内 in place 置 lifecycle / closed_at / closure_note，与 mstar-review-qc 一致。每条 severity 遵守 mstar-artifacts/references/status-and-residuals.md「Residual findings：severity（SSOT，机器字段）」。

快速判定（PM）

1. specify 是否完成？
2. clarify 是否完成（高影响歧义是否收敛）？
3. 意图门禁是否满足（真实目标 / 成功判据 / 非目标已写明）？
4. plan 是否完成并可引用？
5. 若 plan 涉及 UI 工作：DESIGN.md 是否存在且满足声明的 completeness level（见 mstar-design-md）？
6. 若分批/暂缓/临时绕行，roadmap 是否落在 plan/status 中，而不是只在对话里？
7. tasks 是否完成？
8. Assignment 是否含 Task category（实现类任务）并与 Owner 一致？
9. 若中途出现 plan drift，是否先回写再继续？
10. 实现说明中是否体现"最小耐久切片 + 手术式改动 + 可验证检查"？
11. 每个任务是否满足容量判据：声明 Effort band、单轮闭合其 Files 与验证门、写明 split point（Task shape / session fit → mstar-artifacts/references/plan-quality-bar.md item 7）？

任一项为「否」时，Gate decision 必须是 blocked。

迭代级活动（compound / iteration-close）见 mstar-iteration；不属于 per-plan gate 判定项。独立交付 plan 的 compound disposition 属交付尾段义务（PR head 定稿前），见 mstar-harness-core「最小交付循环」。

Hotfix 例外

• 允许路径：specify(min) -> plan(min) -> implement
• 必须补记：
  • 事后 clarify/RCA
  • 触发条件、影响范围、修复与回滚摘要

最小证据要求

• Prepare 阶段证据：问题定义、歧义结论、plan 链接。
• Execute 阶段证据：tasks 清单、实现自检、审查/验证证据。
• 结论证据：不得仅写"done"，必须可复核（命令、输出、截图或复现步骤）。
• 证据与变更同层。 单测/集成测试是 plan task 的默认证据；开发 plan 中，真实浏览器、真机、安装/部署 E2E 不写成 task，也不构成任何 gate 的证据义务——各层自行测试，缺环境如实记为未验证。这类验证的唯一落点是用户显式请求的独立 mstar-e2e workflow：该 workflow 自身以 plan 注册并承载命名场景，是此边界的合法例外（授权来源见 mstar-harness-core § 定向执行与验证边界）。issue/需求/验收文本中出现的端到端场景不构成在开发 plan 中加 task 的授权。

References

• plan 文件落盘与路径符号 → mstar-conventions
• 多 task 默认 Execution mode: sdd 的 implement 波次 → mstar-sdd
• QC / QA 审查链与 residual 登记 → mstar-review-qc