质量保证计划
通过苏格拉底式盘问为用户故事推导基线测试计划：包含带有已声明设计技术的测试条件，仅在规格支持时声明预期结果，并向能够解决其余问题的人员提出问题。你不会问“这个故事写得好吗？”，那是 /refine-story 的职责。你要回答的是：哪些地方可能出问题，如何证明它正常工作，以及为了执行该证明必须具备什么条件。
中级 QA 工程师应能直接从此工件实现测试；高级 QA 工程师应认同其优先级划分。
用户故事：$ARGUMENTS
三层边界
推导未明确写明的条件是 QA 的本质，前提是遵循既定方法。因此，这里的边界跨越三个层面运作；其基础仍然是 requirements-rigor。计划中的每个条件恰好属于一个层面：
[已指定: 原文摘录]：条件和预期结果直接来自文本。请引用来源。[已推导: 技术名称]：条件源自应用于已指定内容的测试设计技术。始终指明技术名称；没有声明技术的条件属于猜测，不得纳入。预期结果仅当它们逻辑上遵循于规范时才可断言。[未定义 → 问题 n]：一个合法的条件，但其预期结果规范未定义。该条件进入矩阵；结果变为一个编号的问题。
快速测试：“哪个技术生成了这个条件，它源自哪段摘录？”如果两者中任何一个无法回答，将其从计划中排除。
开始之前
读取工作区中的 docs/agents/refinement.md：它定义了操作模式（有代码或无代码）、语言（en-US 或 pt-BR，默认为 en-US）以及发布路径。模式决定了谁负责回答架构问题：有代码模式下，你通过检查代码库来解决它们；无代码模式下，工程团队通过问卷解决问题。苏格拉底式盘问和质量保证计划使用配置的语言编写。如果文件缺失，请求 /configure-refinement 并停止。
步骤
-
加载。 读取用户故事、
CONTEXT.md、领域 ADR、TEST-DESIGN.md，并调用requirements-rigor的技能工具。如果.scratch/<slug>/spec.md存在（来自/refine-story），则从它开始：该会话的决策已经回答了许多问题。如果没有此文件，则将用户故事视为未精炼，即使Status:显示为 READY。 完成条件：在一行中声明可测试性分类：可测试（每个预期结果都有观察点，且没有依赖项待确认）、带保留意见可测试（可以推导条件，但至少一个结果缺少观察点或依赖于未确认的依赖项）、或不可测试。 -
分类。 不可测试（标准未能描述可观察行为：完全是任务，或所有标准中的主观术语缺乏度量）：解释缺失的内容，列出 3 到 5 个最少问题，并建议
/refine-story。在此停止；分析不可测试的材料会产生表面化的计划。如果用户故事尚未经过精炼，请说明此情况并继续，同时指出/refine-story可以解决许多问题。 完成条件：声明了分类。 -
推导条件。 对于每个标准，应用 TEST-DESIGN.md 中适用的技术，避免强行应用不适用的技术；审查潜在盲区，仅报告适用的部分。构建矩阵：条件、来源、预期结果或
[未定义 → 问题 n]、优先级、层级。未定义的条件保留在矩阵中：可见的未来覆盖范围远胜于隐藏的缺口。对产品和开发问题统一编号，这样[未定义 → 问题 n]可以无歧义地解析。优先级理由（每个条件半行）放在风险分析部分的列表中，而不是在表格内。 完成条件：每个条件都有声明的来源，且每个[未定义]都有分配的问题编号。 -
在提问之前搜索事实。 按接收人分离问题。产品负责人：未定义的业务行为。开发人员：架构、可观测性、测试层次、外部依赖隔离、时间控制、测试数据供给、API 错误响应、故障后持久性、技术幂等性。在代码模式下，派遣子代理通过阅读代码来回答开发问题：通知是同步还是异步？审批是否存在锁？外部系统是否存在模拟对象？找到的事实成为预期结果或已定义的层级，并附上来源引用。在无代码模式下，搜索仅限于工作区文件，不派遣子代理；如果未找到任何内容，在第 1 轮顶部用一行说明。 完成条件：每个问题都被标记为通过来源回答或未解决，并分配了接收人。
-
检查产品负责人。 调用
socratic-examination的技能工具。问题轮次伴随当前矩阵，因为问题引用了特定条件。前沿是产品负责人问题，首先是阻塞项（那些解除 P1 条件阻塞的），每个问题在规范提供依据时附带推荐答案；当依据缺失时，提供“无推荐”以及选项。产品负责人的回答立即更新矩阵。对照术语表质疑术语，但仅将产品负责人解决的内容记录到CONTEXT.md中。 完成条件：产品负责人问题前沿为空，或产品负责人请求关闭。 -
综合。 按照 TEMPLATE.md 编写计划：矩阵、风险分析、带自我审计的 Gherkin 格式 P1 场景、可自动化审计、严格基于现有系统文档的回归影响（若无上下文，则列出影响问题给开发人员）、按接收人分类的剩余问题、覆盖范围结论。 完成条件：文件存在于
docs/agents/refinement.md定义的路径，并包含最终免责声明。 -
路由未解决项。 无代码模式下的未解决开发问题以及未能回答的产品负责人问题：按照
requirements-rigor中的QUESTIONNAIRE.md，为每个接收人编写一份问卷，与计划一同存放，并从未解决问题链接文件。 完成条件：没有未解决问题未分配接收人或问卷。 -
报告。 结论、计划发布位置、可执行的 P1 条件数量、以及每个问卷解除了什么阻塞。
最终声明
⚠️ 此输出提供了测试计划的分析基线，而非最终测试计划。关于覆盖范围、优先级和工作量的决策属于 QA 团队，并需经过产品负责人（未定义行为）和开发人员（架构和层次）的验证。