复制事实，而不是覆盖状态：hoshi-data 的 Commit DAG

hoshi-data 的核心思路是：节点复制不可变的事实，再按明确的规则推导当前状态。 这篇摘要介绍截至 2026 年 9 月 12 日的工程成果与作用；算法、示例和参考文献见英文技术正文：Replicate Facts, Not Overwrites。

做到了什么

对已采用 operation log 的数据集，hoshi-data 使用 Commit DAG 保留操作及其因果关系，而不只是交换当前值。节点可以识别重复提交与历史缺口，并在依赖补齐后，通过 deterministic replay 重建可查询的 projection。PostgreSQL 仍负责持久化与查询，并未被 DAG 取代。

它还区分不同操作的语义：可以安全合并的操作不必每次都先确定全局顺序；有额度限制的操作使用 escrow，有排他约束的操作仍需 coordination。结果的 finality 也被明确表示，避免把 provisional 的结果当作不可推翻的承诺。

核心条件是：相同的有效起点、相同且依赖完整的有效提交集合，以及语义相同的规则，才能要求得到相同投影。

有什么作用

不可变历史让同步成为“补齐缺少的事实”，也为故障后的状态核对、投影重建和问题追溯提供依据。我们不仅知道数据现在是什么，也保留了它如何形成的记录。

明确区分已写入、已收敛和已定案，可以帮助外部副作用遵守正确的边界。数据库投影可以重建，但已发送的邮件或已交付的资源不能靠 replay 自动收回；outbox 与接收端必须按结果保证处理事件，而不是只看到一次 append 成功。

结论与边界

收敛不等于业务正确，也不等于所有副本和备份均已持久化。 DAG 不会让任意操作自动免于协调，不会提供端到端 exactly-once，也不能恢复所有副本都已丢失的提交。复制仍不能替代独立备份。

这些能力只适用于已经接入相应机制的数据集和操作策略。Checkpoint 不等于可以安全删除全部历史；当前新节点仍需补齐历史并自行重放核对，不能把取得快照误解为已经可以跳过所有历史。

跨版本语义、安全历史裁剪与可验证恢复是后续研究方向，而不是已完成的功能或论文创新声明。本文没有声称优于共识复制的性能；这样的判断需要在可比较的保证下进行可复现测试。

完整的设计推导、Commit DAG 示例、finality 与 checkpoint 讨论，以及相关研究引用，均保留在英文技术正文。