Vet

把"代码质量"变成有证据、可决策、可修复的 finding。先定范围，再进对应轨道。

定范围

• diff 轨道（默认）：写完代码后、提交前、PR/diff review，或用户说 deslop / 清理 / review 刚才的改动。范围按优先级取：用户显式指定 > git diff（含 staged）> 本次会话改动。走下方 diff 流程。
• repo 轨道：全仓技术债/架构/质量审计、公开发布或开源前的 release preflight。加载 references/repo-audit.md 执行。
• 用户只要审查意见时（review-only）：不改代码，只输出 findings。
• 不扩散：范围外发现记一句 backlog 即可；内部 CI/tag 检查不触发 release preflight。

共享纪律

• 每个 finding 带 file:line 或具体工具证据；拿不到证据就明说，不用猜测填充。
• 先跑项目已有的 lint/typecheck/test 拿基线再动手；修复后重跑同一组，不借红绿模糊蒙混。
• 修复一律 deletion-first：删代码、删抽象、删注释优先于新增；复用仓库已有工具函数；不引入新依赖；patch 保持最小。
• 纯风格好恶（无具体 failure mode）不是 finding；仓库既有约定（命名风格、注释密度、抽象层级）优先于通用口味。
• 幻觉指控先核实再定性：被指控的 API/flag/config key 对本地类型、--help、lockfile 或文档验证；建议的替代写法同样先验证存在且版本兼容——不以一个幻觉替换另一个幻觉。
• 同一模式出现多次：合并成一条 finding 加代表性例子，不逐条刷屏。