根据证据审查 Taiga 交付

从 initiative 的目标结果开始

虚构设备服务现在允许员工查看自己的申请。从 initiative 的目标结果和范围开始审查。识别哪些条件必须成立，以及变更必须保留哪些行为。

本次交付中，员工不得读取其他员工的申请。经理必须保留已定义的访问权限。仅打开页面的测试，不能证明任何一项条件。

连接各项记录

Runs 页面记录各次尝试，包括失败。每次 run 都标识所执行的计划。Run 页面用于检查记录；改变工作的决定应在 initiative 上作出。

阅读测试与格式检查的步骤证据。Taiga 会显示失败或未执行的检查。不要在审查摘要中把“未执行”变成“已通过”。

检查假设与边界

查找关于访问模型、数据模式、环境和外部服务的假设。将它们与已发布意图和实际代码比较。

对于设备服务，检查在哪里核验申请所属员工。测试获授权申请、另一名员工的申请，以及不存在的申请。检查日志是否泄露机密申请内容。

也要审查测试变更。如果变更移除了本可发现缺陷的断言，通过结果的价值就有限。将工作流和测试配置变更纳入审查范围。

提供可执行反馈

指出行为、预期结果和所需证据。例如：“端点检查了登录，却没有检查申请归属。添加服务端访问检查，以及使用另一名员工申请的测试。”

Taiga 可以针对 pull request 审查反馈和失败检查，在同一分支上作出修改。更新后，检查新提交及其检查结果。早先证据可能不覆盖已变化的制品。

如果 run 因计划未完成或检查被削弱而停止，阅读说明的原因。不要仅因可见的检查摘要全绿，就取消草稿状态。

作出正确验收决定

记录哪些标准已验证，哪些仍未解决。让代码仓库的必需审查和检查落实合并边界。保留任何单独的发布决定。

Taiga 观察由你的流水线执行的部署。告诉用户变更已经可用前，先验证环境和制品。部署失败时，可能仍由上一个成功版本处理流量。

用服务层面的检查确认结果：员工能使用功能，未授权访问被拒绝，运维负责人能观察到故障。继续学习处理中断。