用途：在把其他分支（通常是 main）整合进当前功能分支时使用，也适用于 git status 显示存在未合并路径（合并或 rebase 之后）。适用于任何基于 Git 的团队协作流程，Flows/React 应用是冲突常见集中于应用外壳与共享库的典型场景。
目标：保留当前分支上有意为之的改动，未分析前不假设“以 main 为准”或“以本方为准”；在任何冲突解决编辑之前，让取舍对用户可见；讨论按影响排序，结构/功能/API/数据模型变更优先于样式、文案与间距。
主要规则：不得静默解决——用户同意方案（或明确表示按其建议执行）之前，不得删除冲突标记，也不得对冲突文件执行 git add；遇到冲突即停下并报告，除非用户明确要求，否则不通过整段选边来“硬推”大文件。冲突按影响分级：P0 结构/产品（移除路由、删除模块、丢失功能、数据或 API 契约、SDK 或 schema、鉴权或路由外壳）；P1 行为（逻辑、hooks、查询、过滤、错误处理、加载状态）；P2 UI 结构（布局区域、区块增删、导航）；P3 呈现（token、间距、类名、文案微调）。
流程：1）获取并整合或诊断，优先 git fetch 后 git merge origin/main（或指定分支），除非用户要求 rebase；若合并已在进行，运行 git status 并列出所有未合并文件。2）明确向用户报告冲突，包括当前分支、目标分支、merge 还是 rebase、未合并文件路径（可选 git diff --name-only --diff-filter=U），以及每个文件一行说明分歧点。3）编辑前分析：结合对话历史、仓库信号（如 PRD.md、当前分支近期提交、文件归属）、冲突块（合并时 git show :2:path 为本方、:3:path 为对方）；将冲突分类为正交（可安全合并）、重叠（需选择或手动合并）、损坏风险（疑似重复块，建议从一侧重建后手动重新施加另一侧意图）。4）给出建议与问题：文件→建议侧或“手动合并”→一句话理由，按 P0 到 P3 排序，先指出任何删除功能或改变公开行为之处，明确提出歧义问题并请求指示（如按建议执行、某文件保留分支、某文件保留 main、中止合并）；用户确认后才应用解决，优先小范围外科式编辑，尽可能保留双方意图，随后重跑 git status 确认无冲突标记，并对涉及区域运行用户关心的测试或 lint。5）用户想中止时执行 git merge --abort 或 git rebase --abort，并确认将丢失该次整合的进行中状态。
反模式：未经用户批准对整个仓库选 --ours/--theirs；因 main 触及同一文件就删掉功能分支的成果；把冲突清单埋在长代码输出中而无简短摘要；先修低影响样式冲突而让 P0 决策悬空。
快速参考：合并中 stage 2 为当前分支（HEAD），stage 3 为传入方（MERGE_HEAD），需要时可用 git checkout --conflict=merge <file> 验证；全栈或 Flows 应用的常见高触碰路径为根应用外壳、顶部导航、路由模块及共享 lib/ 或 hooks/。可选命令片段与合并消息模板见 reference.md。具体价格、平台支持等信息暂未提供。