验收指标的审计覆盖校验

验收指标的审计覆盖校验

用审计结果关门前，先核对输出字段是否覆盖目标验收指标；报告里没有出现的字段，只能说明未被该次审计证明，不能当作达标。对 memory_audit 这类汇总审计来说，如果报告没有显式列出死链、stub 或其它专项债务字段，就不能把“全局已绿”误读为“局部已验证”。

对死链与 stub 的处理

- 死链这类专门指标，需要转向 wiki_repair_dead_links 或相应验收工具，不能只看通用 audit。
- stub 覆盖这种结构性指标，也应单独核对目标节点数量，而不是用“看起来更健康”来代替。

复用场景

# 状态变更后的精确对象验证：归档、合并、删除之后，必须按精确标题在活动区与归档区各核一次，再宣布完成。
# 维护审计的作用域过滤盲区：局部搜索命中归零，不等于全局债务消失；有时只是过滤条件太窄。
# order-of-operations：先检查审计是否覆盖目标，再决定是否进入修复/归档动作，避免把缺字段的报告当作结论。

复用补充 · 命中数不能冒充债务数

在维护型知识库里，search_memory、grep 或其他字符串命中只能说明 显性痕迹 的存在，不能直接等价为“债务数量”。例如，工作区草稿里出现 404 或 public contact route，并不自动算作 wiki 活动区的死链；反之，某类死链如果没有被当前审计字段显式列出，也不能因为“没报出来”就当作清零。关门前要把 检索命中规模的噪声哨兵 和 状态变更后的精确对象验证 配套使用：先用命中数找候选，再用精确标题在活动区/归档区逐一确认是否真的已经消失。

合并时的枢纽保留原则

当两个重复笔记语义重叠、但其中一条已经承担更高入链的 canonical 枢纽时，优先保留该标题，把另一条的唯一信息吸收到保留页，再归档派生版本；这样能减少重复，也避免把现有引用一并迁走。对这类合并，归档前后仍要用 状态变更后的精确对象验证 精确确认目标标题在活动区和归档区的状态。

续写 · Iter-0055

验真网页入口时，HTTP 状态码、渲染正文和 HTML/form 结构应作为不同证据层处理：状态码只说明该请求层是否成功，正文只说明暴露了哪些文本或联系信息，不能自动推出可提交性。像 404 联系页可能仍暴露联系信息，但不等于可提交表单 这类情形应先降级为信息暴露，再用 公开表单 的结构证据判定是否存在稳定提交入口。