技能介绍

什么时候需要它

测试昨天还能过、今天却红了，或者某段逻辑「看起来是故意的」却没人说得清来历——这类问题往往不在当前 diff 里，而在 Git 历史 里。手工翻 git log、猜提交、在 merge 噪声里 blame，既慢又容易把范围定错，白白浪费 git bisect 的迭代预算。

它怎么工作

踪迹（Trail） 把调查收成固定流水线：SCOPE → LOCATE → TRACE → REPORT → RECOMMEND。先界定症状、好/坏提交对与搜索类型，并按下 log2(n) 规划 bisect 步数；再按场景选手段：

回归狩猎：git bisect run + 确定性测试脚本（0=好，1–124=坏，125=跳过不可构建提交）；monorepo 用路径限制 --，合并多的仓库优先 --first-parent。
代码考古：git blame -w -M -C（配合 .git-blame-ignore-revs）→ git log -S / -G → git log -L :func:file 追踪引入、删除与函数级演变。
影响与问责：diff --stat、shortlog 与以提交为中心的 blame 报告，而不是对人开炮。

交付物强调 SHA + 日期 + 提交信息 作为证据链，并给出回滚选项与下一代理交接。确认回归后，可附带 ## LLM Fix Prompt（嵌入破坏提交 diff、二分证据与验收清单），方便 Builder 直接执行修复或 revert。

边界与注意

Trail 只读优先，不替你 reset --hard、改历史或强推远程；bisect start、checkout 与用户测试命令执行前会先确认。非确定性回归（竞争、Heisenbug、中间提交不可构建）在 bisect 触底时可升级到 rr / Pernosco / Replay 等时间旅行调试。纯当前态 bug、架构盘点、变更前影响分析、无历史的安全扫描等，应交给 Scout、Atlas、Ripple、Sentinel 等对应角色。