done

任务后验证（/done）

done 是任务收尾的唯一入口。将每项检查发送到用户将实际使用的界面，并且仅将仓库检查作为其覆盖界面的证据。

1. 绑定本次运行并选择验收通道

记录原始请求的稳定、完整摘要。继续之前，将用户后续提出的更正合并到该摘要中。

对于初始 Git 运行，记录 git rev-parse --abbrev-ref HEAD 的确切输出作为分支，并记录 git rev-parse HEAD 的确切输出作为验证前的 HEAD。重命名或切换分支会使卡片失效。发布后的运行恢复同一张卡片，并保留其分支、验证前的 HEAD、基线和已验证快照，但以下现有 PR 基线重新绑定路径明确规定的情况除外。

对于绑定 PR 的工作，在此处一次性确定预期基线。存在仓库策略时，遵循该策略。否则，查看默认分支和集成分支候选项：

gh repo view --json defaultBranchRef -q .defaultBranchRef.name
git ls-remote --heads origin 'refs/heads/dev*' 'refs/heads/develop*'

选择一个明确活跃的 dev 或 develop 集成分支；如果没有，则回退到默认分支。如果仍有多个候选项看起来合理，则停止并询问。仅刷新确切选定的 origin 引用，然后记录其名称、远程基线提示 SHA、合并基准 SHA，以及运行过的确切命令：

git fetch --no-tags origin "+refs/heads/<base-ref>:refs/remotes/origin/<base-ref>"
git rev-parse "refs/remotes/origin/<base-ref>"
git merge-base HEAD "refs/remotes/origin/<base-ref>"

对于仅涉及外部系统的工作，应改为将时效性绑定到权威目标。记录每个稳定的目标 ID 或 URL、环境，以及系统提供时的版本或修订号，并记录确切的回读台账。Git 字段和提交不适用。混合 Git 与外部系统的工作须同时记录两种时效信息。

根据原始请求、已更改的制品和已执行的操作，确定所需通道。在运行检查前，列出六个通道的选择，并为每个必需或不适用的通道说明一个理由。对于常规确认，无需暂停；并且须在最终判定前应用用户提出的任何更正。

通道	在以下情况下选择
代码	源代码、测试、脚本、构建行为或运行时逻辑发生更改
UI	面向用户的界面或交互发生更改
文档	文档、生成的制品、链接、资源或导航路径发生更改
全局配置或技能	Agent 规则、配置、注册、发现或调用发生更改
外部元数据或数据	看板、问题、PR、数据库、远程记录或计算得出的外部结果发生更改
发布或部署	发布、部署、推送、已发布的软件包、托管制品或在线使用方发生更改

未选择的通道标记为 not-applicable，并说明排除理由。已选择的通道即使无法访问其边界，仍为必需项。

门槛。 请求摘要和适用的时效信息准确无误；六个通道均有选择和理由；每个用户要求的结果都映射到所有适用的通道。不得要求无关通道。

2. 验证每个必需通道

使用能够触及实际验收边界的最精简检查。对于不涉及代码的任务，不要运行代码检查；也不要将内部代理用作其他通道的证明。

当需要 Code 或全局配置或技能时，在完成适用的审查和解析检查后运行一次 simplify。如果它编辑了内容，则丢弃所有依赖于已更改内容的验收观察结果，涵盖所有通道和证据方面。重新运行受影响的代码和全局检查、审查覆盖检查、浏览器/UI 流程、渲染后的文档/资源/链接、外部数据或元数据回读，以及发布或实时使用方检查。受影响的审查覆盖必须经由 converge-reviews，之后才能将任何受影响通道标记为 verified。

通道	最低边界证据
代码	运行受影响仓库原生的类型、lint、构建和测试检查。适用 TypeScript 时使用 fix-ts-errors；允许先进行限定范围的检查，但必须至少运行一次完整工作区检查。以记录的合并基准 SHA 作为比较基准运行 parallel-review，应用其 converge-reviews 结果，并根据差异核查请求。simplify 的新增注释扫描在此处具有阻断作用：它打印的任何注释若仍在差异中，此通道就不能标记为已验证。以扫描模式运行 reuse-first 并记录其返回结果，包括无结果的情况：simplify 根据自身门槛，只检查变更引入的重复，因此其他所有通道检查都无法发现已存在的重复。
UI	通过 browser-qa 运行受影响流程；要求每个受影响步骤都通过，并记录浏览器输出、截图、网络结果和控制台状态。
文档	检查最终渲染或生成的产物，并测试受影响的链接、资源和导航。仅检查源文本无法验证渲染结果。
全局配置或技能	解析最终配置，验证注册和发现情况，然后根据变更影响检查选择器可见性、手动调用或实际使用方行为。
外部元数据或数据	从权威系统重新获取每个已更改目标，并将确切 ID、字段、数量或总计与请求及变更台账进行比对。
发布或部署	在准确的版本和环境中检查已发布的使用方或实时目标；仅成功执行上传或部署命令并不足够。

对于代码通道，修复审查发现的 Critical 和 Serious 问题，并应用 converge-reviews：仅在结果为 continue 时继续，在结果为 converged 时推进，在结果为 blocked-at-cap 时停止，并呈现任何 follow-up-proposed 审批边界。修复后仅重新运行已失效的检查。

对于已完成的共享状态变更，沿用其执行工作流生成的准确权威回读计划和已落地项目台账。当通道结论依据的是推断而非直接观察时，运行 verify-claims 并遵守其证据上限。

修复失败的检查，并仅重新运行其结果失效的证据。若问题仍未解决，则将该通道标记为 blocked。

门槛。 每个必需通道都有直接边界证据或具体缺口，且每项适用通道指定的检查都有记录结果。

3. 分配状态

对每个请求项、泳道和证据维度使用以下词汇：

• verified：最低限度的边界证据支持所请求的结果。
• pending：所需工作或证据尚未尝试，或正在等待尚未满足的前置条件。PR 尚不存在时，依赖 PR 的 CI 或审查属于 pending。
• assumed：只有间接证据支持该结果；请注明假设。
• deferred：有意推迟验证；请注明由谁或什么在何时恢复验证。
• blocked：已尝试具备前置条件的操作，但失败或无法继续；请注明阻碍因素。
• not-applicable：仅当某个泳道或证据维度确实不属于请求范围和已变更的表面时才允许使用；请重复说明排除原因。请求项不得使用此状态。

缺少边界证据会形成证据上限。即使其他泳道已通过，也不能因此将其变为 verified。

门槛。 每种状态都必须由记录的证据得出，并且每个非 verified 的必需行都必须注明确切缺口和下一步操作。

4. 构建就绪卡

声明范围内的集合，将其封存为隔离快照，然后按照 ${CLAUDE_SKILL_DIR}/references/readiness-card.md 生成卡片。现在加载该文件。它包含工作树清单、隔离快照流程、两种卡片模板、文件 PR 交接、发布后重新验证，以及无 PR 的提交路径。未加载该文件，不得执行以下任何操作。

完成条件。 你已记录卡片时效性；每个请求项均恰好出现一次，并包含所有适用的泳道；你已报告全部六个泳道和五个证据维度；确切的下一步操作已满足依赖条件；判定结果不超过最弱的必需行。ready-to-publish 将任务交接给 file-pr；只有 ready 才允许报告任务完成。