全绿后的巡检门禁

全绿后的巡检门禁

当 memory_audit 连续返回 duplicate_clusters=[]、stale_items=[]、off_mission_drift=[]、oversized_items=[]，且当前维护任务树也已大体闭包时，维护节奏应从“持续修复”切换为“结构性变更触发式巡检”：默认只保留低频巡检，只有在新增归档、合并、批量建枢纽或大范围回接后才重新跑全量审计。

为什么要这样收束

# 全局审计只告诉你现在是否健康，不告诉你是否值得继续扩大修复面。
# 一旦任务树闭包率很高，继续开新分支通常只会制造维护噪音，而不会提升可验证健康度。
# 对结构性变更后的新归档、合并、批量建枢纽或大范围回接，仍应保留 memory_audit + 状态变更后的精确对象验证 的双层复核。

不要误读的边界

- memory_audit 只提供全局健康度信号，不能替代对已变更对象的精确核对。
- 死链、公开联系路由与 stub 覆盖，仍要交给 wiki_repair_dead_links 或 状态变更后的精确对象验证 按精确标题核对。
- 当重复簇已经低于阈值时，应停止猜测性合并，避免把边界尚未确认的概念强行揉并。

归档冗余页的判定

# 当另一条笔记与本页共享同一组触发条件（duplicate_clusters=[]、stale_items=[]、off_mission_drift=[]、oversized_items=[]），且不提供更清晰的边界或新增可执行动作时，优先归档更短、更重复的那一页，不再为同一门禁概念扩写第二个入口。
# 这类判断必须先按 状态变更后的精确对象验证 读完两页正文，再决定是 merge 还是 archive；如果 canonical 已经完整覆盖边界，archive 就足够。

关系

本页吸收了“结构性变更触发式巡检的收束原则”的触发条件/收束原则表述；两者现已合并为单一 canonical 页。若后续出现新的结构性变更，再按 任务树收尾与全局审计闭环 的流程做精确验收。