设计：同层冲突交给 LLM 仲裁会破坏确定性

[TbusOS]

背景

SPEC §8.4 的 conflict resolution decision tree 定义了 scope/enforcement 的决策顺序。其中第 4 条写到：相同 enforcement、相同 hierarchy position、不同来源时，两条 asset 都进入上下文，由 LLM 选择更适用的一条。

同一节末尾又声明：相同 asset set 和相同 pools.toml 必须产生相同结果，不能依赖随机性或 session state。

问题

LLM 仲裁不能作为协议级决策规则。即使输入完全相同，不同模型、不同版本、不同 temperature、不同上下文窗口压力都可能让选择变化。

这会让下面几件事变得不可验证：

• engram validate 无法输出唯一 effective winner。
• Relevance Gate 的 packed context 无法保证“同输入同输出”。
• 第三方实现无法实现同样的 conflict semantics。

建议

把第 4 条改成确定性协议：

同 enforcement、同 effective hierarchy、不同来源且存在冲突时，系统返回 ambiguous_conflict，不产生 winner。

LLM 可以做三件事：

• 向用户解释冲突。
• 根据当前任务给出临时建议。
• 提议添加 overrides:、调整订阅优先级、或取消订阅某个 pool。

但 LLM 不应成为“最终生效规则”的一部分。

可选补充：在 pools.toml 中加入显式来源优先级，例如：

[source_priority]
team = ["native", "pool/design-system", "pool/kernel-work"]

没有显式优先级时，冲突保持 ambiguous，并由 engram review 处理。

参考

• SPEC.md §8.4 rule 4：同层不同来源由 LLM 仲裁。
• SPEC.md §8.4 invariant：相同输入必须相同输出。
• DESIGN.md §8.1 invariant 7/8/12：MCP stateless、CLI idempotent、cross-process safety 都依赖确定性。

[TbusOS]

接受。SPEC §8.4 自身就有 contradiction,这条必须改。

核对结论:SPEC §8.4 打架

• SPEC §8.4 rule 4 (line ~等同于 issue 引用): "Same enforcement level, same hierarchy position, different sources → LLM arbitrates. Both assets are loaded into context, and the LLM selects the most applicable one."
• SPEC §8.4 末尾 invariant: "Given the same asset set and the same pools.toml, the decision algorithm always produces the same result. No randomness or session state enters the resolution. Same input → same output."

这两条放在同一节互相否定。LLM 的选择不是确定性函数,跨模型 / 跨版本 / 跨 temperature / 跨 context 压力都会变 —— invariant 直接被 rule 4 破坏。

engram/core/scope_conflict.py 当前 T-39 的实现(resolve_conflict() -> Resolution 在 rule 4 时返回 winner=None)其实已经是事实上的 ambiguous_conflict 语义,它没有把 LLM 选择写进协议;但 SPEC 文本仍然把 LLM 仲裁写成 "决议方式",两边没对齐 —— 实现保守,SPEC 激进。改 SPEC 对齐实现,而不是反过来。

engram 的核心使命之一是 "换平台 / 换大模型行为不变",rule 4 直接破坏这条。issue 提的修法保住了这条承诺。

接受方案

完全采纳:

同 enforcement、同 effective hierarchy、不同来源且存在冲突时,系统返回 ambiguous_conflict,不产生 winner。

LLM 在 ambiguous_conflict 里的角色明确为三件事:

1. 解释冲突(把两条 asset 的差异讲给用户听)
2. 针对当前任务给临时建议(不是 "决议",是 "我建议在这次任务里用 A,因为...")
3. 提议持久化解法:写 overrides: 字段、调整 pools.toml 优先级、unsubscribe 某 pool

LLM 不进入 packed context 的 "selected winner" 字段。两条 asset 都进 context,但 Relevance Gate 输出会显式标 ambiguous_conflict: true + 列出冲突项,渲染端(prompt template)负责展示给 LLM。

也接受 source_priority 显式优先级

pools.toml / ~/.engram/<scope>/pools.toml 加可选段:

[source_priority]
team = ["native", "pool/design-system", "pool/kernel-work"]
user = ["native", "pool/my-dotfiles-notes"]

• 没声明时:ambiguous_conflict
• 声明了:按列表顺序确定 winner,确定性恢复
• engram review 在 ambiguous 持续 N 天 / N 次 trigger 时建议用户加显式 priority

影响面

• SPEC §8.4 rule 4 改为 ambiguous_conflict 协议(SPEC-AMEND)
• SPEC §8.2 / §9.2 加 source_priority 段说明(SPEC-AMEND)
• engram/core/scope_conflict.py 加 AmbiguousConflict 类型 + source_priority 解析;原 winner=None 升级为显式 ambiguous_reason 字段
• engram/relevance/gate.py Stage 6 输出加 ambiguous 标记,packed prompt 渲染加 conflict 展示模板
• engram review 统计 ambiguous 频次

下一步

• 进 SPEC-AMEND v0.2.1(跟 设计：全局 graph.db 的 asset identity 会在多项目间冲突 #4 设计：MEMORY.md 既要轻量入口又要求直连所有资产，语义冲突 #5 设计：pool notify 模式会先应用再通知，规则类 pool 风险偏高 #7 设计：mandatory 全量入上下文会与无容量上限冲突 #8 设计：confidence 计数需要事件证据模型，避免自证 #9 一批)
• M5 实现修改 + 加 source_priority 解析。engram review 的 ambiguous 计数器后续驱动 wisdom metrics 一条曲线("决议确定性比率")。

DESIGN §8.1 invariant 7/8/12 的 cross-process 确定性依赖 issue 写得很对,这条本质上是 "保证 engram 在任何 LLM 下行为一致" 的护栏,接受意见。