[enhancement] cross-file-impact: resolve variable-receiver method calls via x/tools type info - conservative miss accepted by #2163 review (follow-up to #2100)

[topcheer]

文件和行号

internal/agent/cross_file_impact.go referencesAnyImpactSymbol（PR #2163 重构后 visitor）

问题描述

#2100 修复（PR #2163）采用 go/parser 单文件级 AST 做范围甄别，变量 receiver 的真引用成为保守漏报：删除 (*Server).run 后，兄弟文件中 s.run()（变量 receiver 调用）不会触发 cross-file-impact 通告——探针表只将 Server.run 方法表达式形态（Type.method / (*T).method）计为真阳性，因为无类型信息时无法判定变量 s 的静态类型。

为什么当前可接受（PR #2163 复核裁定摘录）

• 失败模式不对称：该通告是「这些文件可能编译失败」的启发式提示。漏报的兜底是编译器本身（工作流中 go build/test 是 ground truth）；误报（修复前的 6 类误报面）则直接把 agent 引向无关文件——严格更差。
• 净变化：修复前 6 类误报 + 1 类真阳性命中；修复后 0 误报 + 1 类真阳性命中（方法表达式）。

建议方案（后续增强）

升级为 golang.org/x/tools/go/packages 类型信息：packages.Load 目标包后用 types.Info.Selections[selectorExpr].Obj() 精确解析 receiver 类型与方法归属，覆盖变量 receiver 形态。代价是引入包加载开销与依赖——对当前启发式定位属重武器，故独立立案而非阻塞 #2163。

优先级：low（编译器兜底，纯通告质量增强）。

（来源：PR #2163 复核轮方向性权衡判定，reviewer；修复本身已合并且正确。）

[topcheer]

可行性定性（复核轮）：

1. 依赖现状：golang.org/x/tools 非当前直接依赖（go.mod 无行）——建议方案落地即新增重依赖，与仓库最小依赖原则冲突。
2. 零依赖替代路线：仓库已有自建 LSP 基建（internal/lsp + lsp_definition/lsp_hover 工具）——可经 LSP 解析变量 receiver 的静态类型（hover 给声明类型→方法归属），不引 packages.Load。约束：LSP 可用性（语言服务器启动延迟/不可达时需回落现启发式）。
3. 优先级复核确认 low：失败模式不对称论证成立（编译器是 ground truth，漏报只降通告质量，误报才误导）。建议保持 enhancement 池不动，待 LSP 基建有闲置容量时再评估。无可执行技术案，本轮不修。

[topcheer]

产品裁定（owner 直裁）：搁置再议。x/tools 重依赖引入与零依赖 LSP 替代路线均暂不启动（222 的定性评论为再议基础：非直接依赖+low 确认）。保持 open 不关，待后续优先级复评。

[topcheer]

认领本轮处理：复核现状后留成本/收益分析评论（PR #2163 复核已接受的保守漏报权衡，属通告质量增强，是否引入 packages.Load 重武器交维护者决策）。

[topcheer]

复核结论（本轮治理轮留档）

判定：维持 low 优先级，不建议近期实施，交维护者产品决策。

现状确认

• referencesAnyImpactSymbol（PR fix(agent): exploration-frag counts before the clear; impact scope discrimination (#2100, #2103) #2163 重构后 visitor）确实仅将方法表达式形态（Type.method / (*T).method）计为真阳性；变量 receiver 调用 s.run() 是保守漏报。
• 该漏报已被 fix(agent): exploration-frag counts before the clear; impact scope discrimination (#2100, #2103) #2163 复核明确接受，理由成立且依然成立：通告是「可能编译失败」的启发式提示，漏报兜底是编译器（go build/test 是 ground truth），误报则直接误导 agent。失败模式不对称性是判定的核心。

升级成本（若实施 packages.Load 方案）

1. 性能：packages.Load 需加载目标包及其依赖的类型信息，单次典型数百 ms～秒级（大模块更差），而 cross-file-impact 在每次编辑后触发——对交互延迟有实质影响，需缓存层与失效策略，复杂度远超现有 100 行级 visitor。
2. 依赖：golang.org/x/tools/go/packages 传递依赖较重（golang.org/x/mod、x/sync 等），对零新增依赖原则是显著例外。
3. 收益边界：仅提升通告召回（提示质量），不改变任何行为正确性——编译器兜底始终存在。

建议

• 维持 low，挂起为「若未来 cross-file-impact 升级为阻塞式检查（如 pre-commit 集成）再评估」的前置条件。
• 若维护者认为召回率可接受（当前 1/2 形态命中 + 编译器兜底），可直接关闭本 issue 作为 wontfix-by-design。
• 中间路线（低成本）：在 visitor 中对「selector 表达式且 selector 名与被删符号的方法名相同」的调用追加一条低置信度提示文案（不判真阳性），零类型信息成本，覆盖部分场景——但这会重新引入 fix(agent): exploration-frag counts before the clear; impact scope discrimination (#2100, #2103) #2163 裁定要避免的误报面，需维护者权衡。

（本轮治理轮复核，非实施认领。）

[topcheer]

@topcheer 决策请求（issue 闭环治理轮）：本 issue 是 #2163 复核明确接受的保守漏报权衡，上轮已留成本/收益分析（packages.Load 单次数百 ms~秒级 + 重依赖 vs 编译器兜底不变；中间路线会重开 #2163 裁定避免的误报面）。当前 open issue 仅剩本单，请裁定：① 维持 low 长期挂起 ② wontfix-by-design 关闭（编译器兜底 + 方法表达式形态已覆盖）③ 接受中间路线排期。治理轮建议倾向 ②（设计决策已有书面依据），但裁定权在维护者。

[topcheer]

实现 PR #2470 已提交并通过技术复审（见 PR review）：纯 stdlib go/types 第四路线，对照 #2163 review 的三顾虑（依赖/成本/FP 面）逐项核验消解成立——零新依赖、near-miss 门控 ms 级、四重类型提升条件保守（unresolved 恒 miss，#2100/#2163 零 FP 不变量保持）。

issue 维持 open 等 owner 复评：搁置裁定时的优先级顾虑是否被此路线改变，属 owner 决策。复审结论仅提供技术依据，不代替采纳裁定。