fishzjp 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 节）
流水线与落盘产物（文件即流水线状态）
| # | 阶段 | skill | 落盘产物 | 人工检查点 |
|---|---|---|---|---|
| 0 | （旁路，可选）探索先行 | exploratory-testing |
{项目}/探索笔记_{主题}.md |
— |
| 1 | 需求理解 | requirement-analysis |
{项目}/需求模型.md（含澄清记录） |
⏸ 澄清检查点：模糊/矛盾项等用户裁决 |
| 2 | 测试策略 | test-strategy |
{项目}/测试策略.md（Risk Map + 两域 scope 含 type_scope）+ 专项移交_{轴}_{日期}.yaml（有 handoff/blocked/外部执行器轴时） |
⏸ 预算裁决：full 预算裁剪触及 Critical 轴时呈现排序提案等用户裁决 |
| 3 | 用例编写 | test-case-writing |
{项目}/测试用例_markmap.md + 测试用例.schema.yaml |
— |
| 4 | 用例审查 | test-case-review |
修订后用例文件 + 审查记录（重新抽取 Schema） | — |
| 5 | 执行 | automated-e2e-testing / api-testing / 手动 |
自动路径：执行代码或脚本（playwright/ 或 API 测试脚本）+ 执行分报告 测试报告_{来源}_{日期}.md（命名见 ../core/report-template.md 头注；至少 §2 执行统计 + §3 Bug 清单条目，字段按 report-template）；手动路径 手动执行记录_{日期}.md |
⏸ 执行策略裁决：确认 automation_plan 提案（手动/e2e/api）；手动路径执行后 ⏸ 结果回收（TC × 结果） |
| 6 | Bug 分析 | bug-analysis（有已确认 Bug 时） |
中间产物 {项目}/Bug条目_{日期}.md（条目结构与根因分析等五个扩展字段按 report-template §3）——此阶段禁止新建或改写最终测试报告 |
⏸ Bug 定性检查点：预期 vs 缺陷 |
| 7 | 回归验证 | regression-testing（有代码变更/Bug 修复时） |
{项目}/回归清单_{日期}.md |
— |
| 8 | 收尾报告 | 本 skill（按 ../core/report-template.md） |
{项目}/测试报告_{日期}.md |
— |
旁路触发条件：文档缺失 / 系统陌生时，阶段 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存在且validate_schema.pyV1–V5 通过（type_scope 含 handoff/blocked 轴或外部执行器时，对应专项移交_{轴}_{日期}.yaml应已生成） - 阶段 3：用例双轨落盘且
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 归属）。
硬规则
- 不做裁决：澄清、执行策略、Bug 定性、预算裁决一律呈现问题与建议后等用户，不代替用户决定
- 不含领域知识：测试方法、框架知识全部在阶段 skill 与
core/；本 skill 失败的唯一合理原因是编排错误，不是测试判断错误 - 状态全在文件：任何会话中断后，凭
{项目}/落盘产物即可续跑 - 阶段产物消费走文件：跨阶段传递的是产物路径，不是会话内转述
Common Mistakes
| 错误 | 后果 | 正确做法 |
|---|---|---|
| 把所有阶段 skill 的 SKILL.md 都加载进同一会话 | 指令冲突、上下文爆炸 | 阶段间上下文隔离，主会话只持状态 |
| 单阶段意图也启动流水线 | 过度执行、浪费 | 意图识别后移交对应阶段 skill |
| 检查点自答（替用户裁决） | 裁决失效，后续阶段基于错误假设 | ⏸ 环节必须等用户答复 |
| 凭会话记忆续跑（不读落盘文件） | 中断后状态丢失/不一致 | 断点检查只认文件 |
| 编排层塞入测试方法论 | 破坏薄编排、难以维护 | 方法论全部下沉阶段 skill 与 core/ |
| 阶段 6 提前新建/改写最终测试报告 | 与阶段 8 收尾同名双写、双数据源 | Bug 条目先落 Bug条目_{日期}.md 中转文件，收尾统一拼装 |
| 跨会话知识与流水线产物混写 | 知识不沉淀 / 流水线状态被污染 | 会话内状态看落盘产物，跨会话知识看 .qa/（qa-memory） |