05 · 知识与版本一致性

后续工作需要承接正确的材料。Northstar 将需求、设计、代码和验证记录按对象与版本关联起来，检查已有结论是否仍然适用于当前工作。

知识库是一组有结构的产品资料

产品知识库（Project Guide）保存产品身份、需求、技术设计、待办与验证材料。主题索引帮助查找内容，来源约定说明信息冲突时应以哪份材料为准，角色工作区从这些资料中恢复当前任务。

已发布的产品基线、进行中的需求资料和更细的变更记录各有位置。正文解释背景与取舍，结构化条目保存标识、状态和引用，两者一起支撑阅读、检查与后续交接。

代码仓与知识库按需求成对推进

配置双仓的产品使用代码仓保存实现、知识库仓保存文档。同一需求在两侧拥有相互对应的需求分支，让实现和产品资料一起演进；正式发布的主分支（main）保留已交付基线。

读写需求文档时，系统会检查当前需求及其工作副本身份。这样，Dev 可以修改当前方案，PM 可以核对对应产品规则，后续交付也能说明代码与知识分别来自哪个版本。

评审绑定实际材料与上游依据

Northstar 的语义评审会形成结构化结论、问题和覆盖记录，同时绑定被评材料、上游输入及评审规则。版本由相关内容与引用共同确定，因此同名文件改变了正文，也需要重新检查评审是否适用。

例如 PRD 补充了“按拍摄地点的时区归档”，原 TD 评审就需要核对方案是否满足新规则。评审发现的问题经过修订与确认后，系统检查解决证据及其他输入；满足特定承接条件时可以沿用已有依据，否则重新评审。

阶段门禁读取当前有效结论、覆盖情况与阻塞项来判断是否允许推进。评审负责内容判断，门禁负责核验这份判断能否用于当前版本。

Alignment 检查上下游关联是否完整

Alignment 是需求、设计、代码、测试与发布材料之间的关联记录。它能够检查引用对象是否存在、条目是否有覆盖，以及哪些关联需要补齐，并查询已记录的直接影响关系。

例如一条 PRD 需求已经有对应 TD，却缺少代码或测试关联，覆盖检查可以标出缺口。技术负责人便能沿已有引用找到材料，补充缺失环节。关联检查基于已登记的数据，业务正确性仍需语义评审和实际验证。

旧草稿写入前，先核对当前版本

受管知识写入会比较读取时的预期版本与当前版本。不一致时先处理冲突；写入完成后读回内容摘要，核对实际落地结果。长对话中的早期草稿因此有机会在覆盖新资料前被拦住。

这项保护作用于经过系统管理的写入。外部编辑产生的变化需要被识别并纳入新版本，已有评审与关联再按新的材料检查。

双仓交付分别记录结果

每次交付记录代码仓与知识库仓的版本和回执。一侧成功、另一侧失败或响应未知时，系统保留各自状态，沿原操作继续核对。双仓协作需要处理这种部分完成的情况。

候选代码如何整合、验收和进入需求分支，见下一篇 外部 Agent 委派与交付。公司级统一 RAG 与知识图谱将进一步使用这些结构化关系，属于 后续规划。