三层按需付费：默认快路 ≈ 直接修 + 30 秒记账；只有要推翻一个「可能是有意的行为」时才取证；只有定位不了才深挖。对一个 typo，本 skill 的开销趋近于零——任何不触发的层都不存在。
\n必须能找到 .eo-project.json。同目录存在 .eo-project.local.json 时顶层字段覆盖合并（local 优先）。找不到 → 报错退出，提示运行 /eo-project-init。
| 现象特征 | \n走 | \n
|---|---|
| 「坏了 / 报错 / 崩了 / 数据不对」——对错无需文档裁决 | \n快路（第二步 → 第三步） | \n
| 「这里应该… / 为什么会… / 这个行为不对吧」——行为疑似有意实现、涉及业务规则或数值 | \n取证路（第二步 → 第四步） | \n
| 描述弥散、无从下手 | \n第二步定位；仍无果 → 深挖（第五步） | \n
同时按 ../eo-shared/lessons.md §1 消费 lessons——同类坑踩过的，「规则」节直接给答案或作假设先验。
\n.codegraph/ 索引存在则 codegraph explore 定位模块入口，不存在则按目录收敛直读源码git log --oneline -n 20 -- <嫌疑文件> 看 commit 前缀——[<change-id>]（slug 或存量数字前缀）→ 相关 change 直达；fix: / ui: → 直改历史（无书面期望）；无前缀 → 存量代码辅路（代码反查不灵时才用）：扫 eo-doc/changes/INDEX.md——活跃 change 置顶且通常只有 0-3 个，先看它们（刚做完的最容易坏）；不中再按关键词扫 archived 区。候选 >3 或全无匹配 → 追问用户。
最小变更修复 → 用户给的复现步骤转成回归验证跑通 → 跳到第六步落点记账。中途发现行为其实可能是有意的 → 转第四步。修复代码注释零溯源：change/AC/finding 标记与修复辩护不进注释（项目级完整纪律见 eo-doc/agent-handbook/comments.md，如已启用）。
复现与回归都取最低成本层：修前先在该层复现失败（这是根因判断的依据，也是「改完看起来对了」之外唯一的证据），修后在同层验通过。层的选法——纯逻辑用单测 / node -e 等价复刻（秒级），接口契约用一次请求，确属集成 / UI 态才起环境（环境纪律见 ../eo-shared/ac-spec.md）。不要每改一行就重新 build + 起环境。
证据瀑布——期望行为不是单一锚点，按可得性降级取证：
\n| 优先 | \n证据 | \n作用 | \n
|---|---|---|
| 1 | \n用户当下的口述 | \n最高权威，永远存在 | \n
| 2 | \n相关 change 的 §2 AC（若有） | \n最优书面期望 | \n
| 3 | \neo-doc/state/ 现状篇（若 state.enabled 启用） | \n意图佐证：行为被现状篇记为规则 = 曾被认为正常（state 是代码派生快照，只能佐证不能裁决）；篇≠码 → 文档陈旧，提示可跑 /eo-doc-manager sync | \n
| 4 | \n<project_root>/decisions/ 与 brainstorm/ 的记录 | \n意图佐证：行为被钉为决策 = 曾被认为正常（只能佐证意图，不能裁决代码对错） | \n
| 5 | \ngit 归属（commit 前缀） | \n追溯行为来源 | \n
判定与动作：
\n| 取证结果 | \n动作 | \n
|---|---|
| 行为查无出处（无 AC 声明、decisions 无记载）且按口述明显是缺陷 | \n按快路修（第三步） | \n
| 行为是有意设计（AC 声明过 / decisions 钉为规则 / change 意图明确） | \n停手告知：「这是 | \n
| AC 写漏且 change 未 archived | \n确认后先补 §2/§3 再修（Update preserves context） | \n
| 记录与代码矛盾 | \n以代码为准重判 | \n
修复范围守界：预估改动超出 trivial 量级（需方案权衡、动对外接口，判据见 ../eo-shared/granularity.md §2）→ 停手建议开 change，不硬修。
\n触发即向用户宣告：「常规定位失败，进入深挖模式：会临时插桩/加日志/git bisect，结束后还原现场。」
\ntmp/eo/fix/<date>-<slug>.md（可丢弃工件）/eo-project-record 沉淀[<change-id>] 前缀；改动影响其 acceptance.md 人工项的入口/行为 → 按 ../eo-shared/acceptance.md「失效与重置」取消该项勾选并注明原因；改动影响其 evidence.md 的入口/行为/截图事实 → 按 ../eo-shared/evidence.md「刷新与失效」同步刷新对应段；顺带更新其 frontmatter 的 brief（写法见 ../eo-shared/summary.md；写不出留空）fix: 前缀（见 ../eo-shared/conventions.md）state.enabled 且 eo-doc/.sync-cursor 已存在时才顺带报 sync 游标落后量（last_commit..HEAD commit 数）：落后 >10 个 commit → 建议顺手跑一次 /eo-doc-manager sync（直改提交会被 sync 按路径增量收割）。未启用 state 或游标未建立（尚未首次同步）→ 不报，零打扰修复完成：<一句话根因>\n- 改动：<file:line 级别的简述>\n- 验证：<复现步骤回归结果 / AC 核对结果>\n- 落点：计入 <change-id> / 直改（fix: commit <hash>）\n- （取证时）行为出处：<AC-x / decisions 记载 / 查无出处>\n- （深挖时）调查记录：tmp/eo/fix/<file>；建议沉淀 lesson：<是/否>\n适用：test.md 有未决失败项，review.md 有 open P0/P1，或 acceptance.md 有「不通过」项。由 /eo-loop 派发到原 impl worker 执行（worker 复用纪律不变——本分支只是换方法论，不换人），或循环会话内直接调用。status 为 reviewed 时（产出阻塞结果的 skill 正常已按回退边置回；没置则此刻补）→ 先置回 implementing。
与口喷路径的差异只有两条：免定位（反馈报告即定位输入，跳过第二步）；带核销职责（第 1/5 步与交接速报）。分诊三路由原样生效——明显缺陷走快路；finding 与已确认 AC / 已钉决策冲突（「这个行为本来就不对」类）走取证路，防静默推翻；定位不了或链路连环失败走深挖，链路类缺陷用「全链审查」变体（见 references/investigation.md）。
\ntest-asset 的 finding 不由本分支消费，交 /eo-test；本分支只处理业务实现项fixed 并填修复 commit——verified 由复审方核销，本分支不写[<change-id>] 前缀反馈来源、修复 commit、受影响 AC、局部验证、下一节点spawn 一个新鲜上下文 subagent（执行者自述不作数——修了 3 轮的 agent 是判断自己为何修不好的最差人选），输入按 manifest 给，禁止默认通读报告全史：
\n[<change-id>] 提交列表与涉及文件的 scoped diff、本 change 相关的未提交脏 diff产出五分类根因 + 建议出口：
\n| 根因 | \n出口 | \n
|---|---|
| change 方案/架构不合理 | \n转 /eo-change 回炉子流程 | \n
| 链路失败语义残缺（向前写链，恢复面的洞逐次暴露） | \n走深挖「全链审查」变体：枚举链上全部可死点 + 逐点恢复证明矩阵，按矩阵批量修 | \n
| AC 口径漂移（各轮按不同理解打回） | \n回 /eo-change 钉死口径（意图不变的精化，不必回炉） | \n
| 纯实施质量问题 | \n方向没错，建议豁免一轮继续修 | \n
| 测试基建/环境假失败 | \n修基建；报告未决清单注明假失败供用户裁决 | \n
结论一行写入 change.md 末尾：卡点检查：<根因>，<日期>。失败关闭：subagent 起不了（槽位/工具不可用）→ 不得用执行者自述替代，记「卡点检查未执行」，用户在「稍后重试 / 直接回炉 / 单轮豁免」中裁决。
| 约束 | \n说明 | \n
|---|---|
| 明显缺陷不查文档 | \n快路不做任何取证，速度对齐「直接修」 | \n
| 推翻行为前必取证 | \n语义分歧不取证就改代码 = 可能静默推翻已确认决策，禁止 | \n
| 落点记账不豁免 | \n三层里唯一的必做项 | \n
| 验证取最低成本层 | \n能复现该缺陷的最便宜的层就是对的层（纯逻辑 → node -e / 单测，秒级）；起环境是最后手段，不是默认 | \n
| 定位禁全局 grep eo-doc | \n代码反查为主，INDEX 辅路 | \n
| 修复范围守界 | \n超 trivial 量级 / 需方案权衡 → 转 change，不硬修 | \n
| 深挖必宣告、必还原 | \n插桩/日志/bisect 结束后全部还原 | \n
| 需求变更不伪装成 fix | \n功能语义 / 交互逻辑的期望变更就是 /eo-change 的事，哪怕改动很小；纯外观 / 样式 / 文案的期望变更不算——按 granularity §2 trivial 直改（前缀选择见 conventions §2.5） | \n
| 注释纪律 | \n一切流程溯源标注（change 编号/slug、TODO/AC、finding P0-x/P1-x、FAIL-x）严禁进代码注释（溯源走 commit 前缀）；不写「为何正确」的辩护；提交前对新增注释自检一眼；存量过时/误导注释顺手清理。项目启用 eo-doc/agent-handbook/comments.md 时以该篇为准 | \n
| 循环内修复归本 skill | \ntest/review/acceptance 反馈的修复走循环内分支（原 impl worker 执行）；eo-implement 无独立修复模式 | \n
场景 1 · 明显缺陷（快路，全程不碰 eo-doc）：「导出报错了」→ grep 报错文案锁定文件 → 修 → 回归验证 → git log 见 [batch-export] 且该 change 活跃 → 勾 AC、[batch-export] 前缀提交。
场景 2 · 有意设计被误报（取证路的价值时刻）：「列表怎么把已归档的也显示出来了，去掉」→ 反查归属 [list-archive-view] → 该 change 的 AC-3 白纸黑字「归档项默认可见」→ 停手：「这是 list-archive-view 特意做的，要推翻它就是需求变更」→ 用户确认后转 /eo-change。没有这一步，这个已确认决策就被静默推翻了。
场景 3 · 需求变更伪装：「积分过期改成 90 天了」→ decisions 记载 30 天规则、代码一致——有意设计 → 转 /eo-change。
\n场景 4 · 难缠 bug：「偶发卡死，复现不稳定」→ 定位无果 → 宣告深挖 → 四阶段 → 根因回分诊 → 修复 + 还原 + 建议沉淀 lesson。
\n场景 5 · 循环内打地鼠（全链审查）：记账链 Test 连续 FAIL 且各轮触发点互不相同（终局等待面 / 锁权限 / 重试误判已入账）→ loop 打地鼠信号命中，用户选全链审查 → 原 impl worker 走深挖链路变体：枚举链上全部可死点，配不出恢复证明的点 = 洞 → 按死点矩阵批量修 → 台账置 fixed，回原 tester 复验。