loom-omission-hunter

遗漏猎人（omission-hunter）

触发条件

• executing 已产出代码与 test-report.md，但 loom-converge 之前或之后需要一次专门寻找"应存在但不存在"的对抗式审查。
• 怀疑实现只覆盖了 happy-path，边界/权限/失败/禁止行为可能被漏掉。
• 需要独立视角，不依赖实现 agent 的自我报告。

非触发条件

• 还没有代码或测试可审查。
• quickfix / chore 等无 spec 的流程。

执行流程

Step 1：运行遗漏猎人

调用 loom MCP 工具 loom_omission_hunt（参数 spec_dir）。

工具只读检查 requirements.json、traceability.json，对每个 behavior 做负空间检查，输出 findings/omission-hunter.json。返回 ok:false 表示有 blocker，需回流到 loom-converge。

说明：scripts/omission-hunt.mjs 是该工具的实现，运行在 loom MCP 服务器进程内。不要在用户项目里用 node skills/... 调用（部署后路径会断裂）。

Step 2：对每个 Behavior 做负空间检查

对每个 REQ-xxx-Bnn，对照 requirements.json 的 category 与 acceptance，检查以下"应存在但不存在"：

1. 代码符号：behavior 应在某个代码符号中实现。若 traceability.json 无 code_refs 或引用的符号不存在，报 missing code reference。
2. 测试：behavior 应有对应测试。若 traceability.json 无 tests 或测试文件不存在，报 missing test。
3. 预期副作用：涉及写/状态变更的 behavior 应有可观察的副作用（日志、事件、DB 记录）。若代码没有对应日志/事件/写入，报 missing expected side effect。
4. 禁止副作用：forbidden-behavior category 的 behavior 应有保护代码（权限检查、限流、输入校验）。若保护缺失，报 missing forbidden-behavior guard。
5. 失败场景：涉及外部依赖的 behavior 应有超时/重试/回滚。若没有，报 missing failure handling。
6. 公共 API 变更：若 diff 修改了公共 API，但 requirements.json 没有 compatibility 类型 behavior，报 unrequested public API change。
7. 不变量保护：涉及并发/原子性的 behavior 应有锁/事务/CAS。若没有，报 missing invariant guard。
8. 可观测性：observability 类型的 behavior 应有指标/日志/trace。若没有，报 missing observability。

Step 3：生成 findings

每条 finding 形如：

{
  "id": "F-omit-001",
  "kind": "missing",
  "severity": "blocker",
  "message": "REQ-001-B03 (authorization) expects a permission check, but no guard code found in UserService.update",
  "requirement_id": "REQ-001",
  "behavior_id": "REQ-001-B03",
  "artifact": "src/services/user-service.js",
  "location": { "file": "src/services/user-service.js", "symbol": "update" },
  "suggested_fix": { "action": "create_task", "details": "add authorization guard to UserService.update" }
}