modify-theory-system
指导 AI 正确修改①公理体系或②体系结构（A-C-B三粒子）。当用户提到「修改公理」「修改体系结构」「发现规则漏洞」「增加粒子」「修改规则」时触发。对应 AGENT_RULES.md RULE-13~16 和 08_技术体系修改规范.md。
技术体系修改技能
警告：修改①②是最高优先级操作，必须严格按7阶段流程执行。任何绕过本流程的修改都是违规的。
最小修改原则（动手前先判断）
按优先级从高到低，只有当前选项无法解决时才考虑下一级：
优先级1：给已有粒子增加状态变量维度（最低冲击）
优先级2：修改已有规则的条件或动作（不增加新规则）
优先级3：增加新规则（仅当存在"规则漏洞"时允许）
→ 规则漏洞：合法初始状态 + 合法事件 → 现有规则无法给出唯一合法结果
优先级4：增加新粒子类型（极端情况，需专项论证）
必须在 ISSUE 文档中写明"为什么当前优先级无法解决"才能选更低优先级。
7 阶段执行流程
阶段 0：触发确认
明确触发来源：
- 沙盘推演发现实现缺口（场景D）
- 沙盘推演发现理论缺口（场景E）
- 开发过程主动发现
阶段 1：建立 ISSUE 文档（动手前必须完成）
在对应仓库的 issues/ 目录创建：ISSUE-YYYYMMDD-NN.md
文档必须包含：
- 问题描述（现象、复现步骤、根因层定位）
- 优先级判断过程（逐级排查，说明为什么选当前级别）
- 方案描述（精确到字段/规则级别）
- 逻辑自洽性证据（T层目标 + 相关PA层公理逐条核查）
检查清单（全部勾选才能进入阶段2）：
- 问题描述清晰，可被复现
- 根因定位到具体层（T/PA/G）
- 方案选择过程完整（按优先级从高到低排查）
- 逻辑自洽性证据逐条写完
- 最小修改原则的判断结论已写明
阶段 2：版本复制
# 在修改之前先保留旧版本
cp 三粒子体系结构_v2.1.md 三粒子体系结构_v2.2.md
# 在新版本上修改，旧版本永久保留
版本号规则：
| 修改类型 | 版本位变化 |
|---|---|
| 增加变量维度（向后兼容） | PATCH（+0.0.1） |
| 修改规则条件/动作 | MINOR（+0.1.0） |
| 增加新规则或修改PA层 | MINOR（+0.1.0） |
| 修改T层目标或增加粒子 | MAJOR（+1.0.0） |
阶段 3：执行修改
严格按 ISSUE 文档中的方案执行。
每改一处，立即在 ISSUE 文档的「修改过程记录」追加（不是改完汇总）：
### 修改点 [序号]：[位置简述]
**文件**：xxx_vA.B.D.md
**位置**：第X节
**修改前**：（精确引用）
**修改后**：（新内容）
**原因**：与方案的对应关系
阶段 4：回归沙盘验证
必须验证的范围：
| 修改类型 | 验证范围 |
|---|---|
| 增加粒子变量维度 | 所有涉及该粒子的现有场景 |
| 修改G层规则 | 全集扫描（标注"无关"的需说明） |
| 修改PA层公理 | 全量场景（无一例外） |
| 修改T层目标 | 全量场景 + 专项论证 |
阶段 5：自洽性声明
在 ISSUE 文档中逐条声明：
- 每条 T 层目标：无影响 / 正向加强 / 修改但仍满足
- 相关 PA 层公理：逐条核查
- 其他G层要求：是否有冲突或适配措施
不允许模糊表述（"整体上不违反"不可接受，必须逐条引用）。
阶段 6：联动触发
| 修改类型 | 必须触发 |
|---|---|
| 修改了①公理体系 | 场景F → A（通知②） + B（通知③） |
| 修改了②体系结构 | 场景G（通知TF架构合规层） |
| 修改了②且影响Bᵢ | 场景K（通知④⑤分身系统） |
执行联动通知，参见技能 trigger-linkage-rules/SKILL.md。
阶段 7：ISSUE 归档
在 ISSUE 文档末尾填写完成记录：
- 完成日期
- 最终版本号
- 通过的沙盘场景列表
- 已触发的联动场景编号
- 遗留事项
然后在 任务日志.md 追加一条日志记录，参见技能 write-task-log/SKILL.md。