workflow-deliver

工作流：交付

报告已请求、已构建和已验证的内容，包括缺口。交付阶段绝不修复、构建或批准；缺陷应退回对应阶段。

从同级目录 ../workflow/ 读取共享策略（若缺失：停止并说明；绝不使用其他技能根目录中的副本）。其中的“Always”列表在此同样适用。

开始前，检查：PLAN 检查点是否写明协议和批准，或轻量请求（若没有，报告缺少的内容；不要重建授权）；是否还有工作者正在编写；execute 是否记录了全功能审查，除非任务已停止、暂停、取消或属于轻量任务（workflow/TASK-FOLDER.md）；否则交还给 workflow-execute，不要在此处运行；规则是否涵盖你要重新运行的任何检查（workflow/RULES.md），否则该检查仍为未验证。

使用子代理时，由未参与构建工作的全新子代理进行核对；采用小规模路径时，可以由工单的审查者核对，并注明身份。否则说明核对由自己完成。TODO 勾选项和摘要都需要证据。

1. 冻结状态

只读：记录 HEAD，以及相对于起始 git status 的暂存、未暂存和未跟踪更改。每项判定都基于此状态。

2. 要求

对于每项已约定的要求、验收项、各参与者条目和假设，以及已批准的更改，记录其工单、V-ID 和一项判定。若对协议的解读偏离其字面内容，则这是 workflow-clarify 的缺口，不能作为判定：

判定（报告值）	所需条件
已验证（verified）	实际运行过的检查已通过；检查针对的文件此后未变；且没有未解决的审查发现
部分完成（partial）	已观察到其中一部分；注明缺口
失败（failed）	检查未通过
未验证（unverified）	未进行检查、检查已过时（报告检查状态为 stale），或环境不可用；说明原因
已豁免（waived）	有记录的用户决定；绝不能显示为已通过
已取代或已取消范围（superseded）	说明取代它的决定；不引用检查

3. 检查

对于每项必需检查：是否运行、针对哪一状态、结果如何？只有在工作仍处于活动状态，且执行已获批准、安全并符合 workflow/ARTIFACTS.md 限制时，才能重新运行已过时或缺失的检查。任务停止、暂停或取消后，不得启动任何检查：记录缺口。绝不跳过或弱化必需检查。

4. 文件

将每个更改的文件对应到工单；报告无法解释的更改、承诺修改但未触及的文件，以及遗留脚手架。

5. 审查

每个工单审查和全功能审查都必须存在、涵盖 Standards 和 Spec、针对最终文件运行，并且所有发现都已关闭或有限定范围；报告缺失的审查或仅由自己完成的审查。

6. 记录

TODO 状态、检查点和台账必须一致（workflow/scripts/open_items.py 会列出缺乏证据的勾选项）。列出每条标记为 by: agent 的 DECISIONS 条目，供用户查看。两个门禁都已记录，或被归类为 legacy、waived 或 lightweight。

7. 退回缺陷

每项不一致都应成为一条带负责人的发现：代码、测试或审查缺陷退回给 workflow-execute；协议缺口退回给 workflow-clarify；工单缺口退回给 workflow-specify。不要在此处修复；若任务已停止、暂停或取消，则将其列为遗留问题。代码或测试修复后，重新核对；仅修改记录后，重新检查这些记录。若用户要求按现状交付，或已停止任务，则以部分完成状态交付。

所有要求、必需检查、更改文件和审查都已在冻结状态下作出判定后，方可完成。

8. 撰写交付报告

使用 workflow/scripts/record.py 将 ## Outcome 写入 PLAN，并更新检查点：已询问、已达成一致、已构建；工单及其状态；已更改的文件；检查及结果；两个评审维度；验收结论；对于 UI，列出用到的每个类及其定义文件，并在差异中确认“未添加 CSS”；限制；已保留的证据和剩余的临时文件；下一步安全操作。

然后使用 ../simple-english/SKILL.md 用文字告知用户：现在有哪些功能可用、哪些不可用或尚未检查，以及他们仍需接受哪些内容；随后提供证据。冷读者检查：未参与对话的人能否说出目标、改了什么、保留了什么、需要他们做什么，以及检查方式？是否接受应由负责人或设计人员记录，这是用户的责任。

只有以下三项都存在，任务才算完成：PLAN 中的 Outcome；只要任务有任何 HTML 报告，就要有交付快照，或由用户记录“无快照”；以及聊天报告。在聊天报告中提供快照路径。内容未变的核对结果沿用现有交付快照；仅状态变化则留在记录中。首次交付或有实质性变化的结果（结论、检查、文件或完成情况发生变化）必须生成新的带日期快照，绝不覆盖旧快照：运行 codebase-map/scripts/task_report.py scaffold <approved review.json> <new delivery.json>，然后根据记录填写每个 FILL: 文本和所有状态；在安全的情况下，可见变化应使用构建结果的真实截图。保留要求：workflow/VISUAL-REVIEW.md。

轻量编辑：按实际规模处理：一条记录及其检查、单次评审和已更改文件，并附简短报告。不需要工单或完整功能评审，也不需要 HTML 快照。

绝不暂存、提交、推送、部署或发布。