解合并冲突

合并 feature/login 到 main，auth.ts 第 40 行附近报冲突。靠肉眼在 <<</===/>>> 之间挑代码，往往把其中一方的意图整个丢掉——要么回退掉刚加的会话刷新，要么覆盖掉对方对 token 存储的重构，而且自己还不知道丢了什么。

它解决什么问题

解冲突的真实难点不在合并标记，而在不知道每一段改动为什么存在。这个技能把冲突当成一次需要还原作者意图的考古，而不是一次要赶紧糊上的修补。

核心做法

1. 先确认状态，再动手

看 git 历史与冲突文件，确认自己确实处于 merge 或 rebase 进行中，而不是误判了工作区状态。

2. 回溯一手来源

读提交信息、查 PR、查原始 issue/ticket。目的是搞清楚 ours 和 theirs 各自在解决什么。比如一次冲突里，ours 加了会话刷新，theirs 重构了 token 存储——两件事本该并存，而不是二选一。

3. 逐 hunk 解决，保留双方意图

能兼得就兼得：让会话刷新调用重构后的 token 存储接口。只有当两个改动确实指向同一处且无法并存时，才选择符合本次合并既定目标的一方，并明确记下权衡。绝不臆造冲突双方都没做过的新行为。

4. 跑项目的自动化检查

通常按 typecheck → tests → format 的顺序执行，修复合并破坏的东西。这一步能暴露肉眼看不出来的语义冲突——类型能过，不代表逻辑对。

5. 完成并收尾

全部暂存并提交。若是变基，继续处理直到所有提交都变基完，不留半途状态。

输出与边界

结果以 ConflictResolution 工件形式返回，包含冲突文件清单、每个 hunk 的取舍（both / ours / theirs 及理由）和检查是否通过，可交给 code-review 继续评审。

适用边界很清楚：只处理进行中的 merge/rebase 冲突。它不会用 --abort 逃避问题，不会忽略项目的自动化检查，也不会凭空发明新行为——如果你要的是绕过冲突直接强推，这个技能不适用。