知识发布源码解析：谁有权把材料变成回答依据？

从文档上传，转向工程决策条目

ZhoMind 的目标内容不是文件堆，而是一条条可被团队使用的工程决策：什么问题、适用什么版本与环境、默认做法是什么、替代方案付出什么成本、依据是什么。运行副本只供检索和展示，不应因为某字段写着 approved 就成为编辑权威。¹

本文按 2026-09-08 本地集成修订 c1609dd12523e780149ec7ac546a34509f907757 解析。候选发布分支和大语料工作树另列为开发中，不混成同一版本；本次未重跑上游测试或生产验收。

三个角色，不共享一个批准按钮

私有编辑服务分别保留 Author、Approving Reviewer 与 Domain Knowledge Maintainer。作者或实质修改者不能批准自己的同一版本；维护者还要接受该修订的责任，才能形成合格的来源可用事实。System Administrator 处理批准导出，不因系统管理权限获得私有编辑内容的任意读取和修改权。¹²

这比“管理员上传即可信”多了角色和事件，但避免了同一个运行时入口同时创作、审核、发布并替自己验收。

来源失效通过事件表达，不改写过去

来源定义只存一次，可用性沿追加事件重建。事件必须属于正确来源、条目和修订，并绑定接受责任的维护者；缺少、外来或格式错误的事件不能把 unknown 改成 verified。¹

历史批准快照保留当时依据，新导出还要重新检查当前来源与 assurance 状态。因此旧审核记录可以解释过去，却未必允许今天再导出新候选。代价是一次读取需要核对关系，而不只是读一个布尔值；收益是来源撤销不会被旧文件里的“通过”覆盖。

审核导出不是 Git 同步，也不是发布

editorial_export/v1 从保留的权威事实确定性重建，规范 JSON 计算 SHA-256。Reviewed Release Bundle 绑定每个 item 的身份、操作、工件及哈希。导入时不仅检查哈希，还重建批准工件并比对当前权威；哈希一致不代表来源资格仍有效。¹²

private entry / revision / source events
  -> independent approval snapshot
  -> deterministic editorial export
  -> reviewed release bundle
  -> admitted item and frozen build input
  -> administrator dispatch
  -> isolated candidate_ready

相同 bundle 身份与相同哈希可以幂等重放，相同身份不同内容是冲突。整包完整性失败不能留下半个成功包；条目级资格失败可以只拒绝该条目，独立有效条目继续。验证器基础设施出错也不能被写成“内容不合格”。¹

这把材料不合格、身份冲突和服务暂时无法完成核验分开，让用户得到不同的下一步。

可恢复构建需要保留授权，不只保留进度

导入只安排构建，不自动入队。管理员 dispatch 事件绑定当前 attempt 和冻结输入；启动恢复不能仅凭可变的 dispatched_at 授予运行权。worker 写入前核对 attempt、owner、租约与输入身份，外部 indexing 等待期间续租，失去推进权后停止。¹²

stage: queued -> parsing -> chunking -> indexing

terminal:
candidate_ready / failed / canceled
interrupted_retryable / superseded

阶段与终态是两组词汇。indexing 不等于成功，candidate_ready 不等于 published。清理候选向量必须使用该候选冻结配置的指纹，不能在配置变化后删除当前正常检索集合。

最终生成 Candidate 前还要在权威锁保护下重新核对来源与批准事实，避免核验后、提交前来源已失效。这里的成本是更复杂的恢复与清理义务；好处是“重启继续”不会变成绕过审核的另一条入口。

候选预览和普通知识地图为什么分开

当前基线提供管理员 Candidate preview，核对冻结输入、bundle、当前构建尝试和分块哈希。预览带候选身份，明确不具备答案证据资格。普通 Pilot 候选池只读取当前已发布兼容代际，并回查最新编辑权威。¹³

Knowledge Map 也只向知识用户展示通过当前来源、范围和资格检查的已发布条目，不公开草稿和候选。用户可以发现知识覆盖，而不会把待审材料当作可用答案。⁴

当前仍处于迁移过程：旧文档发布接口存在，不代表新的 canonical Candidate 发布链已完成。候选检查、验收与发布分支需合并和产品路径验证后，才能归入集成交付。

最终希望用户得到什么

目标是：维护者持续修订工程决策，独立审核后形成可恢复候选，再通过显式发布交给团队；用户只能检索适用且有当前依据的版本，来源变化时得到缺口或撤回提示，而不是悄悄换一段答案。

这是目标使用闭环，不表示目前已经完成日常运维、完整新发布迁移或大规模语料验收。单个构建模块完成，不能替代整条闭环。

来源与范围

本篇依据当前集成代码与规范合同，不导出私有条目、真实来源摘录或运行记录。证据执行全文解释发布后怎样判定充分性，迭代记录分开已集成、在途和目标效果。