team-qa

团队 QA

调用此技能时，通过结构化测试周期协调 QA 团队。

决策点： 每次阶段转换时，使用 AskUserQuestion 将子 Agent 的提案作为可选项呈现给用户。将 Agent 的完整分析写入对话，然后用简洁标签记录决策。 在 collaborative 模式下，用户必须先批准，才能进入下一阶段。 在 guided 模式下，除非某个阶段处于 BLOCKED 状态，否则流水线会自动推进；在 autonomous 模式下，整个流程会端到端运行，并通过 log_decision 记录每个阶段的结果。automation_always_ask 类别（is_always_ask_category helper）中的决策始终会触发询问，不受模式影响。请参阅 .claude/docs/automation-modes.md。

阶段 0：解析配置

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,qa.level

上方已解析 — 按原样使用；--review 会覆盖 review_mode。没有阻塞 → 默认值见 .claude/docs/config-resolution.md。

qa.level 决定 Logic、Integration 或 Config/Data 故事的证据是什么： 在 standard 和 full 下是自动化测试；在 minimal 下，测试可豁免 （.claude/docs/coding-standards.md），证据则是阶段 5 中对验收标准的逐项检查 — 此时没有测试的故事属于已豁免，而不是缺少证据。所有级别都必须提供 UI 和 Visual/Feel 截图。

review_mode 决定 director gate 的深度，而本流水线没有 director gate： 无论 review_mode 如何，以下阶段都不会生成 CD-、TD-、PR- 或 AD-PHASE-GATE。它的 阶段 gate 是流水线自身的决策点（见下方 team.size 部分的定义），参与这些决策点工作的 Agent 是团队成员，而非 director gate。

automation 控制上方的 Decision Points 说明。有关各模式如何改变流水线行为，请参见上方的 Decision Points 说明和 .claude/docs/automation-modes.md。

team.size：哪些 Agent 处于活动状态（与 review_mode 的 gate 深度和工作流文档无关）。

• individual（默认）：仅 qa-tester；仅在阶段 gate 调用 qa-lead。
• small：qa-lead + qa-tester 流水线（如文档所述）。
• studio：qa-lead + 按故事生成 qa-tester + 签署确认。 在 individual 下需要的非核心 Agent，会转由最近的活动核心 Agent 处理，并附带说明性备注。“阶段 gate”指本流水线本身列出的、以 AskUserQuestion 决策点结束的任何阶段 — 即上方 Decision Points 中的转换，或写在下方流水线中的 Gate 步骤 — 无论 automation 模式如何：在 guided 或 autonomous 中，即使跳过或记录了该问题，该阶段仍然是 gate。并非每个阶段都是 gate。按字面规则判断：如果下方阶段没有列出决策点，它就不是 gate；仅限“阶段 gate”的 Agent 不会为该阶段生成。此活动集范围规则适用于下方整个流水线：任何阶段指定了活动集之外的 Agent 时，都会转由最近的核心 Agent 处理，而不是生成该 Agent。

在阶段 1 之前公布活动集 — 绝不能默默缩减。 生成任何内容之前，用一行说明本次运行实际会生成哪些 Agent，以及下方流水线点名但在解析得到的 team.size 下不会生成哪些 Agent。例如：

Active set (team.size: <resolved>): <the agents listed for that size above>. Not spawned this run: <every other agent this pipeline names> — consulted through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.

直接根据上方的 team.size 列表和本文件流水线中点名的 Agent 填写 — 不要照搬示例。 不同编排器的两组内容各不相同。 如果解析出的规模规定某个 Agent 仅在阶段 gate 时生成（individual 下的 qa-lead）， 则在活动集中注明这一限定 — 它会被生成，而不是通过其他 Agent 咨询。

下方流水线看起来是一个多 Agent 扇出流程，但在发布时的默认设置下，实际只有一两个 Agent — team-release 点名十个 Agent，却只运行一个；team-narrative 在五个阶段中点名六个 Agent，却只运行 writer。这种缩减是正确的： team.size 优先考虑严谨性，而较窄的默认设置是控制 token 用量的手段。 若不说明这一点，读者就无法区分正确缩减的运行和损坏的流水线；而上方“转由最近的核心 Agent 处理并附带说明性备注”规则只会在路由时触发，绝不会说明整个运行的总体情况。

这与本文件其他地方关于报告跳过检查的规则相同：对于阅读输出的人来说，已执行但从未显现的约束，与从未执行的约束无法区分。

团队分工

• qa-lead — QA 策略、测试计划生成、故事分类、签核报告
• qa-tester — 编写测试用例、编写 Bug 报告、手动 QA 文档

如何委派

使用 Agent 工具将每位团队成员作为子 Agent 启动：

• subagent_type: qa-lead — 策略、规划、分类、签核
• subagent_type: qa-tester — 编写测试用例和 Bug 报告

向每位 Agent 提供简要说明，不要倾倒上下文。 只读取一次共享输入，并在提示中传递提炼后的简要说明：仅提供每位 Agent 实际需要的内容，绝不要提供你已经读过的文档路径（收到路径的 Agent 会重新读取整个文件）。仅当你尚未读取某份文档且只有该 Agent 需要时，才传递路径。

每条 Agent 提示都必须以返回约定结尾：“将完整输出写入 [path]——该指定路径即为你在下述有限例外范围内的写入授权，因此请直接写入，无需另行征求批准。仅返回：(1) 已写入的路径，(2) 不超过 5 条的决策摘要，(3) 任何 BLOCKED/CONCERNS 项，每项一行。不要复述你读过的文档。”缺少此约定时，Agent 会把它读过的所有内容都返回到当前会话中。

为什么这不违反协作协议。 CLAUDE.md 要求 Agent 在使用 Write/Edit 前询问“可以将其写入 [filepath] 吗？”。此处启动的子 Agent 无需询问即可写入，这是有意设置的有限例外，并非疏忽——这与对 consistency-check 追加写入 active.md 的调用相同。只有以下三项全部满足时，例外才适用：(1) 路径由你在提示中指定，因此用户在批准该阶段时也批准了目标位置；(2) 这是 production/、docs/ 或 tests/ 下的新产物，绝不能是对现有源文件或配置的编辑；(3) 产出该文件的阶段属于上述阶段门，即流水线规定必须以 AskUserQuestion 结束并在此之后才会推进的阶段，无论采用何种自动化模式。若不满足这三项，Agent 必须先询问。不要通过逐个向子 Agent 询问来“修正”此问题——每个阶段都要对每个 Agent 单独发起一轮提示会让编排器无法使用，这正是设置该例外的原因。

当 team.size: studio 时，Phase 4 会为每个故事并行启动一个 qa-tester；低于该规模时，则只启动一个 Agent 负责整个组。

流水线

阶段 1：加载上下文

在开始任何操作之前，先收集完整范围：

1. 根据参数检测当前冲刺或功能范围：

   • 如果参数是冲刺标识符（例如 sprint-03）：Glob production/sprints/sprint-*.md，并按冲刺编号匹配——sprint-3、sprint-03 和 sprint-003 都表示冲刺 3（/sprint-plan 会写入 sprint-NNN.md）。读取匹配的文件。如果有多个匹配项，使用最近修改的文件。
   • 如果参数是 feature: [system-name]：Glob 标记了该系统的故事文件
   • 如果没有参数：读取 production/session-state/active.md 和 production/sprint-status.yaml（如果存在），以推断当前活跃冲刺。如果没有冲刺——在 rigor: minimal 时不会有冲刺——询问要覆盖哪个 Epic，并使用 feature: [epic-slug]；不要自行编造冲刺

2. 从 project.yaml（若无则从 production/stage.txt）读取 project.stage，确认当前项目阶段。

3. 读取范围内的未关闭 Bug——这些是 QA 发现新 Bug 之前已记录的 Bug：按 /bug-triage 的做法，grep production/qa/bugs/*.md 中的 **Severity**、**Status** 和 **System** 行。除非 Status 为 Closed 或 Verified Fixed，否则 Bug 均视为未关闭；当其 System 属于范围内故事所涉及的系统之一，或它指明了范围内的某个故事时，该 Bug 就在范围内——不确定时也要列出。这些内容要作为 范围内的未关闭 Bug 写入阶段 2 和阶段 6 的简报：此处已有的未关闭 S1 或 S2 Bug 已足以使签核结果为 NOT APPROVED（阶段 6），无论 QA 发现什么。如果没有 Bug 文件，则写为“范围内的未关闭 Bug：当前无记录”。

4. 统计找到的故事数量并向用户报告：

   “QA 周期即将开始：[冲刺/功能]。找到 [N] 个故事。范围内的未关闭 Bug：[N — S1：n，S2：n，或当前无记录]。当前阶段：[stage]。准备开始制定 QA 策略了吗？”

第 2 阶段：QA 策略（qa-lead）

通过 Agent 启动 qa-lead，审查所有范围内的故事并制定 QA 策略。

向 qa-lead 提供第 1 阶段的范围内未解决 Bug（ID、严重程度、故事或系统），然后提示它：

• 阅读每个故事文件

• 按类型对每个故事分类：逻辑 / 集成 / 视觉/感受 / UI / 配置/数据

• 确定哪些故事需要自动化测试证据，哪些需要手动 QA — 在 qa.level: minimal 下，没有故事需要测试：没有测试的逻辑、集成或配置/数据故事，在“需要自动化”一栏标记为 WAIVED，并在手动 QA 中逐项核对其验收标准

• 标记任何缺少验收标准或测试证据、会阻碍 QA 的故事

• 估算手动 QA 工作量（所需测试会话数）

• 评估冒烟测试状态前，先检查是否已有冒烟检查报告：Glob production/qa/smoke-*.md，并读取修改时间最新的文件（如果找到）。如果存在报告，直接采用其判定和结果 — 不要再次询问用户。如果没有报告，请注明：“未找到之前的冒烟检查报告 — 继续前请运行 /smoke-check sprint。”并将冒烟检查状态设为 UNKNOWN（为便于继续，将其视为 PASS WITH WARNINGS）。给出冒烟检查判定：PASS / PASS WITH WARNINGS [列表] / NOT ASSESSED [未运行的内容] / FAIL [失败项列表] / UNKNOWN（未找到报告）

• 生成策略摘要表和冒烟检查结果：

  故事	类型	需要自动化	需要手动测试	阻碍项？

  冒烟检查：[PASS / PASS WITH WARNINGS / NOT ASSESSED / FAIL / UNKNOWN] — [来源：production/qa/smoke-[date].md 或“未找到报告”] — [非 PASS 时填写详情]

  范围内未解决 Bug：[BUG-ID — S[n] — 故事或系统，每项一行；或“无记录”] — 未解决的 S1 或 S2 应在此列为已知故障

如果冒烟检查结果为 FAIL，qa-lead 必须醒目地列出失败项。冒烟检查失败时，QA 不得越过策略阶段。

向用户完整展示 qa-lead 的策略，然后使用 AskUserQuestion：

question: "QA Strategy Review"
options:
  - "Looks good — proceed to test plan"
  - "Adjust story types before proceeding"
  - "Skip blocked stories and proceed with the rest"
  - "Smoke check failed — fix issues and re-run /team-qa"
  - "Cancel — resolve blockers first"

如果冒烟检查结果为 FAIL：不要继续第 3 阶段。展示冒烟检查报告中的失败项并停止。用户必须修复问题、重新运行 /smoke-check sprint，然后重新运行 /team-qa。 如果冒烟检查结果为 UNKNOWN：提示警告 — “未找到冒烟检查报告。建议在 QA 前运行 /smoke-check sprint。谨慎继续。” 如果冒烟检查结果为 NOT ASSESSED：展示报告中说明的未运行内容 — “上次冒烟检查无法评估[未运行的内容]。建议条件允许时重新运行 /smoke-check sprint。谨慎继续。” — 并按 UNKNOWN 的处理方式继续；第 6 阶段的签核不得为 APPROVED。 如果冒烟检查结果为 PASS WITH WARNINGS：在签核报告中注明警告并继续。 如果存在阻碍项：明确列出。用户可以选择跳过受阻故事或取消本轮。

阶段 3：生成测试计划

根据阶段 2 的策略，生成一份结构化测试计划文档。

测试计划应涵盖：

• 范围：迭代／功能名称、故事数量、日期
• 故事分类表：来自阶段 2 的策略
• 自动化测试要求：哪些故事需要测试文件，以及 tests/ 中的预期路径（qa.level: minimal 时不需要；应将豁免的故事列在「手动 QA 范围」下）
• 手动 QA 范围：哪些故事需要手动演练，以及需要验证的内容
• 范围外内容：本轮明确不测试的内容及原因
• 入场标准：开始 QA 前必须满足的条件。始终包括：(1) production/qa/smoke-*.md 中存在状态为 PASS 或 PASS WITH WARNINGS 的冒烟检查报告；(2) 构建稳定（启动时不会崩溃）；(3) 在迭代范围内，production/sprint-status.yaml 中所有 Must Have 故事的状态均为 in-progress、review 或 done；在 feature: 范围内，每个范围内故事文件的 Status 均为 In Progress、In Review 或 Complete。添加该迭代特有的其他条件。
• 出场标准：QA 周期完成的判定标准（所有故事均为 PASS，或为 FAIL 且已登记缺陷）

询问：“我可以将 QA 计划写入 production/qa/qa-plan-[sprint]-[date].md 吗？”

收到批准后再写入。

阶段 4：编写测试用例（qa-tester）

冒烟检查作为阶段 2（QA 策略）的一部分执行。如果阶段 2 的冒烟检查结果为 FAIL，则周期在此处停止。本阶段仅在阶段 2 的冒烟检查结果为 PASS、PASS WITH WARNINGS、NOT ASSESSED 或 UNKNOWN 时运行。

对于每个需要手动 QA 的故事（视觉／感受、UI、没有自动化测试的集成；以及在 qa.level: minimal 时被豁免测试且没有测试的每个逻辑、集成和配置／数据故事：其用例应逐项覆盖验收标准）：

通过 Agent 启动 qa-tester——在 team.size: studio 时，每个故事并行启动一个；在 small 和 individual 时，为整个故事组启动一个；并为每个故事提供：

• 故事文件路径
• QA 计划中与该故事相关的部分
• 被测系统的 GDD 验收标准（如有）
• 编写详细测试用例并覆盖所有验收标准的说明
• 输出路径：production/qa/test-cases/[story-slug]-cases.md。 在提示中明确指定该路径，每个故事一个文件。

为何在此指定路径，而不是交由编排器决定。 上述有限写入例外仅适用于“路径由你在提示中指定”的情况。本阶段会并行启动 Agent，因此未指定目标路径会造成最大问题：每个 Agent 都会自行决定路径，两个运行可能会将同一产物写入不同位置。直到两个 Agent 需要存放输出的地方出现分歧之前，本阶段的说明看起来都没有问题。

每组测试用例应包括：

• 前置条件：开始测试前所需的游戏状态
• 步骤：编号明确、含义清晰的操作
• 预期结果：应发生的情况
• 实际结果：留空供测试人员填写
• 通过／失败：留空

执行前将测试用例交由用户审核。按故事分组。

按每个故事组使用 AskUserQuestion（每批 3-4 个）：

question: "Test cases ready for [Story Group]. Review before manual QA begins?"
options:
  - "Approved — begin manual QA for these stories"
  - "Revise test cases for [story name]"
  - "Skip manual QA for [story name] — not ready"

阶段 5：手动 QA 执行

逐一检查已批准的手动 QA 列表中的每个故事。

将故事分成每组 3–4 个，并对每组使用 AskUserQuestion。等待测试人员回答，且只记录他们说过的内容：测试人员未提供的结果绝不代为填写。无人回答的故事保持未执行状态，这会使签核结论为“未评估”——除非测试人员明确表示，否则不能标记为“已阻塞”。

question: "Manual QA — [Story Title]\n[brief description of what to test]"
options:
  - "PASS — all acceptance criteria verified"
  - "PASS WITH NOTES — minor issues found (describe after)"
  - "FAIL — criteria not met (describe after)"
  - "BLOCKED — cannot test yet (reason)"

每次出现 FAIL 结果后：使用 AskUserQuestion 收集失败描述，然后通过 Agent 启动 qa-tester，按照 /bug-report 的格式在 production/qa/bugs/ 中撰写正式的 Bug 报告。严重性和优先级标签必须与该模板列出的标签完全一致（S2-High、P1-Fix this sprint 等），因为 /bug-triage 会解析这些标签。

每次视觉/感受或 UI 故事获得 PASS 或 PASS WITH NOTES 后，都要在 production/qa/evidence/ 中记录其证据。 保留的截图就是证据：请测试人员为该故事涉及的每个屏幕或效果各保存一张截图到 production/qa/evidence/[story-slug]/ 下，并确认文件已写入磁盘——/story-done 检查的是保留的图像，而不只是文字记录。UI 故事通过这些截图关闭；视觉/感受故事还需要负责人签核。然后询问“是否可以将 [story titles] 的证据写入 production/qa/evidence/？”，每组故事询问一次，并根据 .claude/docs/templates/test-evidence.md 创建证据文件 production/qa/evidence/[story-slug]-evidence.md，完整保留签核表并引用截图。如果未保存截图，请在阶段 5 总结中指出该故事缺少保留的证据，而不要撰写一份会暗示截图已存在的文档。

这不是可有可无的记录工作，而是下一项技能设置关卡所需的文件。 /story-done 会在视觉/感受和 UI 故事中搜索 production/qa/evidence/，并读取签核表；/story-readiness、 /test-evidence-review 和 gate-release 也会读取同一目录。如果写到其他位置，故事可能在此处通过完整的手动 QA 流程，之后却被 /story-done 告知不存在视觉证据。视觉/感受和 UI 关卡默认会阻塞流程，因此这会造成死锁——QA 已通过，故事却无法关闭。只有在明确将 testing.strict.ui 或 .visual 设置为 false 时，这才只是一个容易造成困惑的标记。

除非本次会话中确实完成了签核，否则请勿勾选签核行。带有预先勾选审批项的证据文件比没有证据文件更糟：它会把缺失的签名记录成已签署。

Bug 报告的命名方式：BUG-[NNNN].md，编号方式与 /bug-report 相同——取 production/qa/bugs/ 中最大的 ID 加一，并补齐为四位数字，以便 /bug-report verify 和 close 能通过 ID 找到报告。

收集完所有结果后，进行总结：

• PASS 的故事：[数量]
• PASS WITH NOTES 的故事：[数量]
• FAIL 的故事：[数量] — 已提交的 Bug：[ID]
• BLOCKED 的故事：[数量]

阶段 6：QA 签核报告

通过 Agent 启动 qa-lead，使用阶段 2–5 的所有结果起草签核报告。此处的返回约定是回复中的报告文本，而不是文件： 协调者会在本阶段末尾询问后写入签核报告，因此 qa-lead 不写入任何内容。

向 qa-lead 提供证据和下方的判定规则——绝不提供判定结论。 逐字传递策略表、冒烟检查的判定及其来源、每个故事的结果、阶段 5 中提交的 Bug、阶段 1 中的范围内未解决 Bug，以及下方的判定规则。不要指定判定结论，不要预先填写 ### Verdict: 行，也不要说明哪条事实决定结论：由 qa-lead 根据证据应用规则。然后，在询问是否写入之前，依据相同规则检查其判定；如果两者不一致，请同时展示并询问——绝不要默默替换成自己的结论。

签核报告格式：

## QA Sign-Off Report: [Sprint/Feature]
**Date**: [date]

### Test Coverage Summary
| Story | Type | Auto Test | Manual QA | Result |
|-------|------|-----------|-----------|--------|
| [title] | Logic | PASS | — | PASS |
| [title] | Logic | WAIVED (qa.level: minimal) | PASS — criteria walked | PASS |
| [title] | Visual | — | PASS | PASS |
| [title] | Integration | — | BLOCKED | BLOCKED — [reason]; no executed evidence |

### Bugs Found
| ID | Story | Severity | Status |
|----|-------|----------|--------|
| BUG-0001 | [story] | S2 | Open |

[every open bug in scope — those Phase 1 found on file and those filed in Phase 5]

### Verdict: NOT ASSESSED / APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED

**Conditions** (if any): [list what must be fixed before the build advances]

### Next Step
[guidance based on verdict]

范围内的每个故事都要有一行测试覆盖率摘要——包括 BLOCKED 和未执行的故事，并在 Result 中说明原因——这样从未运行过的故事也不会从报告中漏掉。

判定规则：

**顺序。**先检查 NOT APPROVED：范围内任何未解决的 S1/S2 Bug——无论是在 Phase 1 已记录的 Bug，还是在 Phase 5 新记录的 Bug——或者任何未记录解决方法却 FAIL 的故事，都会使判定结果为 NOT APPROVED，无论还有什么未执行的内容——已知失败的优先级高于未知，将其降为 NOT ASSESSED 会掩盖失败（.claude/rules/skill-authoring.md，义务 1）。

然后检查前提条件。APPROVED 和 APPROVED WITH CONDITIONS 都要求范围内的每个故事都有已执行的证据——运行过的测试，或实际走查过的手动用例。在 qa.level: minimal 时，Logic、Integration 或 Config/Data 故事的验收标准走查就是其已执行的证据：其测试是 WAIVED，而不是缺失。如果有任何故事处于 BLOCKED 状态、未执行或没有证据，判定结果就是 NOT ASSESSED，而不是任何一种 APPROVED。Phase 2 中状态为 UNKNOWN（未找到报告）或 NOT ASSESSED 的冒烟检查，也会导致结果为 NOT ASSESSED：构建的健康状况从未经过检查。

• NOT ASSESSED — NO EVIDENCE：一个或多个故事没有产生已执行的证据（处于 BLOCKED 状态、未按 qa.level 的 standard/full 标准编写测试、未走查用例，或冒烟检查为 FAIL / UNKNOWN / NOT ASSESSED）。这不是通过，也不是失败；这表示 QA 尚未执行。说明具体是哪些故事，以及原因。
• APPROVED：所有故事均为 PASS 或 PASS WITH NOTES；没有未解决的 S1/S2 Bug
• APPROVED WITH CONDITIONS：存在未解决的 S3/S4 Bug，或已记录 PASS WITH NOTES 问题；没有 S1/S2 Bug
• NOT APPROVED：存在任何未解决的 S1/S2 Bug；或有故事 FAIL 且未记录解决方法

为什么需要此前提。以下三条规则都假设每个故事的结果都是 PASS 或 FAIL。如果一个迭代中没有任何内容被执行，就不会触发任何 NOT APPROVED 条件，而且会因空集而满足“没有未解决的 S1/S2 Bug”——因为零个已执行测试意味着零个已观察到的失败。按字面理解，如果没有此前提，这些规则会让一个完全未经测试的构建达到 APPROVED——即使 qa-lead 本意是判定为 NOT APPROVED，规则的字面内容也无法支持这一判定。签署表示质量已验证；没有此前提，这些规则就无法区分“已验证良好”和“从未检查”。

各判定结果对应的后续步骤：

• NOT ASSESSED：“QA 未完整执行。补齐缺失的证据——编写 Logic 测试（达到 qa.level 的 standard/full 标准），或走查被豁免故事的验收标准（minimal），走查手动用例，运行 /smoke-check——然后重新运行 /team-qa。判定为此结果时，不要推进构建。”
• APPROVED：“构建已准备好进入下一阶段。运行 /gate-check 验证是否可以推进。”
• APPROVED WITH CONDITIONS：“推进前先解决条件。S3/S4 Bug 可以推迟到完善阶段处理。”
• NOT APPROVED：“解决 S1/S2 Bug，并在推进前重新运行 /team-qa 或进行针对性的手动 QA。”

询问：“我可以将这份 QA 签署报告写入 production/qa/qa-signoff-[sprint]-[date].md 吗？”

获得批准后再写入。

错误恢复协议

首先，核实产物。 如果返回约定指定了路径，在将阶段视为完成之前，先检查该路径是否存在——指定的产物若不在磁盘上，无论回复读起来多么流畅，该阶段都算失败。 Agent 可能耗费整个阶段，却只返回一段看似合理的开场白，实际什么也没写；这既不是 BLOCKED，也不是错误，更不是“无法完成”，因此下面的触发条件永远不会触发。请明确指出未满足的约定并恢复执行；上下文通常还在。

如果任何已启动的 Agent 返回 BLOCKED、出错或无法完成：立即说明情况，不要越过其阻断的依赖项继续执行，并始终生成部分报告。 完整流程见：.claude/docs/error-recovery-protocol.md。

常见阻塞因素：

• 缺少输入文件（未找到故事、缺少 GDD）→ 转至负责创建该文件的技能
• ADR 状态为 Proposed → 不要实施；决策通过后，使用 /architecture-decision accept ADR-NNNN 接受该 ADR
• 范围过大 → 使用 /create-stories 将其拆分为两个故事
• ADR 与故事之间的指示相互冲突 → 指出冲突，不要猜测

输出

摘要需涵盖：范围内的故事、冒烟检查结果、手动 QA 结果、已提交的 bug（含 ID 和严重性），以及最终的 APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED / NOT ASSESSED 结论。

结论：COMPLETE — QA 周期已完成。 结论：BLOCKED — 冒烟检查失败，或关键阻塞因素导致周期无法完成；已生成部分报告。

会话状态更新

最终阶段完成后（签核报告已写入或已得出 BLOCKED 结论），静默追加到 production/session-state/active.md：