merge-decision-package

name	merge-decision-package
description	BoardGame 保留/合并/真相源决策包。用于多 worktree、双边归并、UI 基线、历史候选收口和正式版本认定。

保留与合并决策包

概览

把“有两边内容要不要保留/合并”的混乱问题，压成普通人能直接判断的决策包。默认先说明哪些能全保留、哪些只是正式入口不能双生效，再给一句用户可直接回复的推荐方案。

先决条件

开始前先锁定四件事：

1. 当前真相源
   • 哪套截图、artifact、已提交版本、规则书或已认可实现是真正基线。
2. 实施落点
   • 当前实际改的是哪棵 worktree / 分支 / 工作区。
3. 候选范围
   • 到底是哪几批内容在争夺正式入口，哪些只是过程材料。
4. 用户当前真正要决定的问题
   • 是选正式实现、还是决定删不删候选、还是只要一份能看懂的判断说明。

以上四项有一项没锁定，就先补证据，不要先写结论。

决策分类

先把内容归到下面四类，再决定是否需要用户拍板：

1. 正式实现单选
   • 同一路由、同一运行时入口、同一正式导出、同一正式测试真相，只能先认一边。
2. 候选实现可保留
   • 暂时不翻正，但可以继续留在 worktree、分支或工作区里，后续再审。
3. 过程材料双保留
   • 截图、evidence、审计文档、草稿、设计说明、比较文档可以一起留。
4. 独立小项可单独吸收
   • 不直接改正式 UI/交互真相的小项，可以脱离主冲突单独收口。

只要还有一种“先都保留、暂不删除、只冻结正式入口”的路径，就必须先告诉用户，不能直接问“删哪边”。

先自己裁决，不要滥问用户

若现有证据已经足以单边裁决，就直接做：

1. 真相源已被用户明确认可。
2. 某一边只是过程文档或历史候选，不会影响正式入口。
3. 某几个小项已经证明与正式 UI 基线不冲突。

只有在下面情况才进入“需要用户拍板”：

• 正式实现真要换基线。
• 两套正式候选都自洽，但证据不足以单边淘汰。
• 接受某一边就会连带切换文案合同、验证合同或运行入口。

生成决策包的固定顺序

面向用户的正文固定按这个顺序写：

1. 一句话总结
   • 先说当前不是在删哪边，而是在决定正式版本先认哪边。
2. 先回答三件事
   • 这是不是只能二选一。
   • 哪些部分可以全部保留。
   • 哪些部分只是同一正式入口不能双生效。
3. 用户现在只需要决定的一句话
   • 给出推荐句，用户可以直接回复“同意/不同意”。
4. 为什么推荐这个
   • 用现实影响解释，不先上文件名。
5. 如果选另一边会发生什么
   • 直接翻译成产品后果、UI 后果、验收后果。
6. 最后才放技术附录
   • 批次、文件、证据路径放最后，不要放在开头。

决策包必须回答的最小问题

无论场景如何，正文里至少要明确回答：

1. 现在是不是所有内容都只能二选一。
2. 如果不是，哪些能保留，分别怎么保留。
3. 当前最低风险路径是不是“先不删任何一边，只冻结正式入口”。
4. 用户真正需要决定的，究竟是不是只有“正式版本先认哪一边”。
5. 我推荐哪一边，为什么。

禁止行为

• 不要把“同路径有 diff”直接表述成“只能删一边”。
• 不要把正式实现、候选实现、过程材料、旧草稿压扁成一个二选一问题。
• 不要先报 11 个文件、4 个批次，再让用户自己翻译现实含义。
• 不要让用户先看代码才能判断。
• 不要在还存在“全部先保留”的低风险路径时，直接推动删除。

大任务与 OpenSpec

如果这次决策会引出新的长期流程、跨模块治理变更、或后续要按正式方案持续实施一整批任务，先回到 openspec/AGENTS.md 判断是否要补 change proposal / tasks，把大任务拆成小任务后再继续实施。这个 skill 负责“把决策说清楚”，不替代 OpenSpec 的长期规划职责。

输出模板

# <主题> 决策包

## 一句话结论
<先说当前推荐，不先说文件名>

## 先回答三件事
1. 这是不是只能二选一：<是/不是，为什么>
2. 现在可以全部保留的：<候选实现 / evidence / 审计 / 说明 ...>
3. 现在不能两边同时生效的：<正式入口 / 正式 UI / 正式合同 ...>

## 你现在只需要决定的一句话
<给出一条用户可直接回复“同意/不同意”的推荐句>

## 为什么我推荐这个
- <现实影响 1>
- <现实影响 2>
- <现实影响 3>

## 如果改选另一边，会发生什么
- <直接说产品后果>

## 附录：技术映射
- <批次 -> 文件 -> 证据路径>