用途：在持续开发之后定期巡检仓库架构，回答“哪里越来越难改、如何深化”。它是 loft 的维护孪生：loft 在构建前回答一个设计问题，survey 在构建后做架构体检。
何时使用：每隔几天活跃开发后，或一批工单落地后；也可在仓库明显变难改时临时触发，例如改动牵涉文件过多、接口为单个调用方膨胀、无关测试被迫同步更新。可选参数可把巡检范围收窄到某目录或区域，无参数则巡检整个仓库。
主要能力：先读架构原则（CLAUDE.md、ADR）与 docs/standards/architecture.md 中的接缝词汇（seam、deep module 定义）；遍历目标区域的模块图，无方向时先读一段提交历史，让高频出现的区域牵引巡检。寻找三类发现：浅模块（接口宽、行为薄，调用方知道得比模块隐藏的多）、假设性接缝（仅一个适配器跨越、无第二调用方，可用调用方计数核查）、错位接缝后的逻辑（行为位于不拥有其数据的边界另一侧）。对每个嫌疑对象做拆除测试：移除后复杂度消失（穿制服的直通）还是转移到调用方（承重）？只有承重的浅薄才算发现。
报告：按杠杆对风险排序，每个候选含证据（接口、调用方、行为的 file:line）、一句话深化动作（深化、合并或移动什么）、风险说明（触及什么、可能破坏什么），并标注严重度、置信度（启发式类，天然偏低；机械可查部分归 drydock --check）、可行动性。结尾给出首要建议：先深化哪一个及原因。与现有 ADR 冲突的候选仅在摩擦真实时提名，并说明 ADR 与水域变化原因；理论冲突不列入。可用仓库的 diagram 技能可视化，但文字报告始终是事实来源。
交接：报告是决策输入而非工作本身，候选可喂给 mission brief（launch 第一阶段）或后续评审材料。船长可当场对首要候选做设计树访谈（launch 第一阶段前沿协议）：深化涉及什么、成本多少、解锁什么。被船长以承重理由拒绝的候选按 ADR 测试（难以逆转、无上下文会意外、真实权衡）提议为 ADR，避免下次重复提名；无理由拒绝则沉没。
限制：不做任何代码编辑，从不重构；不是门禁，没有东西阻塞在报告上；不并入 drydock 漂移审计，--check 保持严格机械可查、仅高置信发现，架构判断属低置信启发式，混入会稀释契约。完成定义：报告存在且每个发现都有证据、排序与风险说明，且未修改任何文件。