test-against-spec

对照规范进行测试

确认交付的行为是否符合明确规范。 默认情况下只报告。只有在使用精确限定词 fix 时，才修复已观察到且属于范围内的差距，并重新测试。本技能不会替代或运行源代码审查或整个项目的完整门禁；这些由调用方负责，而且仅凭源代码审查和单元测试通过，不能作为行为证据。

如果实现、需求、环境和输入均相同，则复用已记录的真实接口证据；但在 fix 模式下，必须先亲自复现每项失败，再进行修复。发生变更、失败或存在未解决的问题后，运行缺失或已失效的行为检查。

范围界限

• 仅根据用户请求、问题、已确认的迷你规范、产品文档、ADR 或其他明确决策推导预期行为。切勿从实现中推断。遇到重大冲突或歧义时，停止。
• 测试外部可观察的结果。面向用户的行为应使用渲染后的产品进行测试；其他行为则应通过真实的 API、CLI、库入口、任务、包、迁移或已部署服务进行测试。 对于定性需求，应将实际产物和行为与用户提供的参考或验收标准进行比较；仅通过指标无法证明视觉保真度或可用性。
• 不得使用实现源代码、测试源代码、单元测试、模拟对象、快照或补丁作为行为有效的证据。没有可执行行为的需求不在本技能范围内，应交由代码审查或项目门禁处理。
• 如有可用且与待测的确切修订版本关联的预览部署，应优先使用。若没有合适的预览，或需要在本地运行以覆盖当前工作区变更，则使用本地环境。若现有黑盒自动化测试的是实际交付接口，且结果仍然有效，则使用该测试。
• 除非用户另行授权，否则本步骤不会提交、推送、部署、发布或更改外部数据。尽可能使用一次性测试数据；若测试会造成重大的外部副作用，须先征求同意。

工作流

1. 记录规范来源，以及正在测试的确切工作树修订版、提交或预览修订版。将每项外部可观察的要求与此技能范围之外的要求分开，并根据上述边界为每种行为选择环境。
2. 测试每项可测试的要求。覆盖预期路径以及影响最重大的失败或边界路径。对于面向用户的更改，请与渲染后的产品交互，并覆盖受影响的状态、无障碍性和相关视口。
3. 记录环境、设置、操作或命令、输入、预期结果和观察结果。只有在针对正在测试的确切内容观察到预期结果时，要求才算通过。仅提交检查或确认而没有结果不算通过；请重新运行。
4. 如果当前预览和本地环境都无法复现所需行为，请查阅项目文档和脚本，寻找其他途径，例如沙盒、模拟器或测试工具，并使用它。只有在没有可用途径时才将行为标记为未验证，并报告已尝试的内容。
5. 未指定 fix 时，不得进行任何编辑。指定 fix 时，只要出现 fix，就应立即阅读 references/fix-mode.md，并且必须在检查实现源码之前完成；之后对每项未通过的要求都遵照其中说明处理。

在当前工作流中返回结构化摘要，不要将其作为已提交或被忽略的文件。摘要应包含受测修订版、环境、规范来源，以及标记为 passed、failed、unverified 或 out of scope 的每项要求及其证据或限制；如适用，还应包含修复和更改的文件，并说明是否仍有任何行为未通过或未验证。直接启动时，按照交付设置继续；使用 entry-points: deliver 时，已测试的更改（包括任何修复）将进入 /deliver，由其审核、把关并发布到配置的端点（不存在 ORCHESTRATION.md 时为 ready-to-merge）。使用 stop 时，以此摘要结束。