复查 cloudflare security-audit 的审计结果时，先把上一轮的 coverage-ledger.json 和 findings.json 与当前源码对照。对相关源码或条件已变化的记录重新验证，把未完成和受阻的检查列入本轮计划。结束时校验新台账，并对照两轮输出确认哪些检查已补齐、哪些仍缺证据。

回看上一轮覆盖台账

先分出已经有证据的检查、尚未完成的检查，以及依赖旧源码的记录。保留上一轮输出，方便对照。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

先按当前源码重新分组

例如，上一轮检查过租户列表接口。本轮若改动了查询过滤条件，原有覆盖证据需要重新核对。如果只是界面文字变动，可以先确认审计涉及的代码和条件是否仍然相同，再考虑沿用已有证据。

按变更和缺口安排复查

先对照当前代码与上一轮证据，找出新增入口和变化的信任边界。再把待验证项里的未决事实列出来，分别安排补测或独立复核。能确认仍适用于当前源码的证据可以沿用，变化的路径需要重新验证。

把每个缺口变成可检查的任务

为变更路径记录要确认的主体、资源和边界。若上一轮受阻是因为缺少受控的本地环境，本轮仍无环境时，继续保留未决事实。若已补齐条件，则由独立验证者重新验证，避免把之前的判断直接写回。

核对本轮补齐了什么

更新台账后，用项目提供的 validate-coverage-ledger.cjs 检查结构，并对照新旧 findings.json 核对结论是否变化。重点看哪些入口已经补查、哪些候选已有新证据、哪些仍被环境限制阻断。保留具体阻碍原因，下一轮才知道要补什么。

从技能目录验证新台账

将下例路径替换为本轮实际文件。若校验未通过，先按错误提示核对字段和记录关系，再做新旧台账对照。本次另外运行了官方的覆盖台账验证器测试，31 项均通过。

node validate-coverage-ledger.cjs /path/to/coverage-ledger.json
node --test validate-coverage-ledger.test.cjs