qa

QA 编排入口（qa）

把"帮我测试这个需求"翻译成一条可断点续跑的流水线。本 skill 是薄编排：不含任何测试方法与框架知识（全部在阶段 skill 与 core/），不替用户做裁决。

When to Use

• "帮我测试这个需求 / 功能"、"把这个功能完整过一遍"、"从需求到报告走一遍完整测试"
• 之前的流水线中断了，需要从落盘产物续跑

When NOT to Use

• 只要单阶段产出 → 对应阶段 skill：需求建模 requirement-analysis、测试策略 test-strategy、写用例 test-case-writing、审查已有用例 test-case-review、E2E 执行 automated-e2e-testing、API 执行 api-testing、探索会话 exploratory-testing、Bug 根因 bug-analysis、回归范围 regression-testing
• 编写/修改某个阶段 skill 自身的方法论 → 不经过本 skill

编排会话模型（阶段间上下文隔离）

• 每个阶段运行在独立上下文中（宿主支持子会话/子代理时）：只加载当前阶段 skill 的 SKILL.md + 按需 references + 上一阶段的落盘产物文件；任一时刻活跃指令 ≤ 1–2 个 skill（当前阶段 + 本编排）
• 主会话只持有流水线状态：阶段清单、各产物文件路径、检查点状态——不加载任何阶段 skill 的领域知识
• 降级路径：宿主不支持子会话、或用户在单会话内手动走流水线时，退化为顺序会话 + 落盘文件衔接——正确性不受影响（状态全在文件里），损失的只是上下文卫生
• 反模式：单会话内顺序累加加载全部 SKILL.md（9 个 × 数百行指令同时在场）
• 注入式形态的例外：预注入部署（评测或宿主一次性注入全部指令）下本节隔离机制不存在——此时靠阶段顺序防串扰：任一时刻只执行当前阶段的指令，其余在场文件视为未加载；"文件即流水线状态"的原则两形态通用（双形态声明见 ../core/evidence.md 第 6 节）

流水线与落盘产物（文件即流水线状态）

旁路触发条件：文档缺失 / 系统陌生时，阶段 0 在阶段 1 之前先行，探索产出（系统理解 + 风险清单）作为需求建模输入。 手动执行路径无 skill 与自动产物——执行后按 ⏸ 结果回收检查点向用户索取结果，落盘 手动执行记录_{日期}.md（TC 编号 × 结果〔通过/失败/阻塞〕，失败附 Bug 编号或现象）：作为阶段 8 报告 §2 执行统计与 §3 Bug 清单的数据来源，防"未执行"列成为永久状态。 阶段 6 的 Bug条目_{日期}.md 是中转中间产物：最终报告在阶段 8 才生成，此期间 Bug 条目无处追加——先落中转文件，阶段 8 拼装进报告 §3 后以报告为准，该文件归档留痕，不形成双数据源。阶段 2 生成的 专项移交_{轴}_{日期}.yaml 同样进入主会话的状态跟踪：后续任一阶段产出或用户反馈使移交轴状态变化时同步更新 yaml 内 execution_status，防移交包生成即失联。 跨会话知识：阶段产出命中值得跨会话沉淀的 QA 知识（环境怪癖 / flaky 判定 / 缺陷模式等）时，按 qa-memory 判定写入项目 .qa/ 知识库；会话内状态仍以落盘产物为准，两者不可互替。

工作流

1. 启动：意图识别与路由

• 用户意图是端到端流水线 → 继续本 skill
• 用户意图是单阶段产出 → 移交对应阶段 skill，本 skill 退出
• 开工先收输入（用户提供或指路，产物对应位置留 TODO 指明"找谁拿什么"）：需求材料、代码仓库与对比基线（base 分支/tag/commit——阶段 7 回归范围凭它划界，落盘进需求模型文件头，防续跑时凭据缺失）、测试环境与账号

2. 断点检查（续跑）

续跑先读 {项目}/流水线状态.md：未决区存在用户已回填的裁决时，先按裁决增量修订受影响阶段的产物（更新需求模型假设、在 budget_review 补 approved_by: 用户 等——不重跑阶段），再按下述判据续跑；未回填的未决项维持保守分支并保持未决标记，不得当作已裁决。然后检查 {项目}/ 下已有哪些落盘产物，从最后一个完整阶段之后继续，不重做已完成阶段。阶段完成判据（阶段 3/4 产物同名，凭判据区分，不凭文件存在性猜测）：

• 阶段 1：需求模型.md 存在
• 阶段 2：测试策略.md 存在且 ../core/scripts/validate_schema.py V1–V5 通过（typescope 含 handoff/blocked 轴或外部执行器时，对应 `专项移交{轴}_{日期}.yaml` 应已生成）
• 阶段 3：用例双轨落盘且 ../core/scripts/validate_schema.py {用例文件}（用例 Schema 单文件校验）通过
• 阶段 4：用例文件末尾含 test-case-review 落款的审查记录节「## 审查记录（test-case-review …）」且 Schema 已重新抽取校验——阶段 3 写时自审的同名「审查记录」节不算数（那是阶段 3 的完成标志，区分两者防续跑时静默跳过独立审查）
• 阶段 5：测试报告_{来源}_{日期}.md（自动路径）或 手动执行记录_{日期}.md（手动路径）落盘
• 阶段 6：Bug条目_{日期}.md 中转文件落盘；无 Bug 则在 {项目}/流水线状态.md 追加一行「阶段 6：无已确认 Bug，跳过」（跳过/未决等流水线状态统一记此文件——硬规则 3"状态全在文件"的续跑凭据，缺该行视为阶段未到）
• 阶段 7：回归清单_{日期}.md 落盘；无代码变更则在 {项目}/流水线状态.md 追加一行「阶段 7：无变更，跳过」

产物缺失/损坏则从该阶段重跑。

3. 按流水线顺序调度阶段 skill

• 每个阶段：在独立上下文中调用对应 skill（或降级为顺序调用），输入 = 上一阶段的落盘产物文件路径（不是会话记忆）
• 检查点暂停：遇到 ⏸ 环节，向用户呈现该阶段 skill 汇总的问题/提案，等待用户答复后再进入下一阶段；用户在澄清环节的明确答复具有最终裁决力（见 ../core/evidence.md 裁决规则），后续阶段不得推翻
• headless / 非交互运行（CI 流水线等无对话场景）：⏸ 检查点不等待、不代答，按 ../core/pipeline-integration.md（此时加载）约定一降级为未决项落盘——有保守默认值的取保守分支并记录依据，其余记未决项；未决项与跳过标记统一落 {项目}/流水线状态.md 未决区，人工回流回填裁决后由断点检查（§2）增量消费；带留痕要求的裁决产物（如 budget_review）按约定一第 4 条如实记 headless 未决，不得写成用户已批准
• 阶段产出落盘失败（文件未生成）→ 该阶段重跑，不进入下一阶段

4. 收尾：生成测试报告

全部阶段完成后（或用户要求提前收尾），按 ../core/report-template.md（此时加载）汇总生成 {项目}/测试报告_{日期}.md：范围、执行统计（自动运行结果与手动执行记录合并）、Bug 清单（拼装阶段 6 的 Bug条目_{日期}.md 并逐条同步状态——有回归结果的按结果更新为已验证关闭/已修复待验证，未回归的保持新建）、风险残留、回归摘要、类型域专项结果按 report-template §7 逐轴归一化回收（handoff / 外部执行 / blocked / exclude）、未闭环事项（含移交 yaml 各轴当前状态与去向）、各阶段产物路径索引、机读摘要片段（按 report-template「机读摘要片段」节生成，供报告聚合系统消费）。

5. 交付

向用户报告：最终报告路径 + 各阶段产物清单 + 未闭环事项（TODO 归属）。

硬规则

1. 不做裁决：澄清、执行策略、Bug 定性、预算裁决一律呈现问题与建议后等用户，不代替用户决定
2. 不含领域知识：测试方法、框架知识全部在阶段 skill 与 core/；本 skill 失败的唯一合理原因是编排错误，不是测试判断错误
3. 状态全在文件：任何会话中断后，凭 {项目}/ 落盘产物即可续跑
4. 阶段产物消费走文件：跨阶段传递的是产物路径，不是会话内转述

Common Mistakes