最终验收

判断实际结果是否满足原始目标和有效约定，以及证据是否足以支持交付。可在原型、核心路径可运行或最终交付时使用，不必等所有设计与实现完成才发现方向问题。

何时用与边界

• 需要判断一个可运行结果是否可交付，或复核“已经完成”的声明。
• 测试全绿但实际不好用，需要区分实现缺陷、错误要求与未验证部分。
• 需要判断某个遗留问题是否阻塞本次使用。

具体实现和排障用 engineering-practice；规则、体验或技术决定有误时按问题使用相应能力，不机械退回上一阶段。验收不是新增需求的渠道，也不默认包含合并、发布或部署。

判断依据

采用 software-lifecycle-principles 的协作与证据约定。在任务指定的共同位置读取原始目标、当前有效决定、产物和已有验证结果；发现缺口就补相应信息，不要求补齐各域交接文档。

验收同时考虑：

• 目标：用户在约定场景下能否完成任务，原有阻碍是否得到解决。
• 要求：业务、体验、安全和运行约束是否兑现；不因呈现要求没进入某张表就忽略它。
• 事实：产物在目标环境中的实际行为，及清单没有预见的使用障碍。

条款与目标或事实冲突时先指出并修正判断依据。不能一边保留错误要求，一边把绕过它的实现判为通过；涉及用户重要取舍时等待其决定，其他检查可继续。

按问题检查

当前问题	方法	得到什么
技术、界面或证据能否支持完成声明	交付底线与证据检查	按交付形态选择的检查结果、缺陷及证据边界
做出来是否解决了实际问题	目标与实际使用回看	主路径使用结果、重要偏差与交付判断

两类检查可以穿插，已有可靠证据不必重复采集。测试通过不代替目标判断；用户说“可以”也不抹掉未验证风险。仅提供反馈或代码审阅时，明确没有完成实际运行验收。

收口

直接更新共同记录中相关要求的验证结果，或在简单任务的对话中说明：交出了什么、凭什么认为可用、还有哪些限制。不新建自己的验收报告。

结论可为满足本次约定、有明确限制待接受、存在阻塞问题或证据不足，按实际情况说明即可，不要求填状态表。缺陷交给对应能力修正；新需求另行决定。通过只代表本次检查范围内的判断，合并、部署、发布仍按授权执行；持续使用价值未观察时不能宣称已成立。