版本: v1.1 | 最后修订: 2026-07-07 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。 关键词: [三谱系, 业务规则明文化, 认知校准, UI显化, 业务输入分类, 落点判定] 适用场景: 收到Owner业务输入后判定归属、判断是否需要W-重
Owner 的业务输入按其性质分属三条谱系之一。三谱系决定落点（写到哪个文件）+ 触发动作（要不要回写设计文档）+ W 档（W-轻可关闭 vs 必走 W-重）。
元约束：守则 § 1 业务唯一裁判。
| 谱系 | 本质 | 典型落点 | W 档 |
|---|---|---|---|
| 谱系 1 业务规则明文化 | Owner 补齐了原本含糊 / 未表达的业务规则 | 业务文档（如 domain/）+ 会话日志记录 | W-轻 即可（已是 Owner verbatim） |
| 谱系 2 认知校准 | AI / 团队对业务的理解偏离了真相，被 Owner 纠偏 | 会话日志（verbatim 入册）+ 受影响的设计文档同步修订 | 必走 W-重（业务认知偏差只有 Owner 在场能放大检验） |
| 谱系 3 UI 显化 | 业务规则已稳定，但 UI 表达 / 文案 / 交互层显化不足 | UI 设计文件 | W-轻 即可 |
接到一条业务输入时，按以下问题判别谱系：
| Q | 是 → 谱系 |
|---|---|
| 这是 Owner 第一次说出这条业务规则吗？且与已有文档不冲突？ | → 谱系 1 |
| AI / 团队对该业务的现有理解被 Owner 否定 / 纠正？ | → 谱系 2 |
| 业务规则没变，只是改了”用户看到的样子 / 文案 / 流程顺序”？ | → 谱系 3 |
| 同时属多谱系？ | → 拆开处理：谱系 1 / 2 部分先入册；谱系 3 部分另立 |
→ 落点：业务文档 + 会话日志记录；W-轻 收尾即可。
→ 落点：会话日志 verbatim + 受影响的设计文档全部同步修订；必走 W-重；可能需要全量回扫受影响面。
→ 落点：UI 设计文件；W-轻 即可。
| 错误 | 后果 | 修正 |
|---|---|---|
| 把谱系 2 当谱系 1 处理 | 漏走 W-重 / 受影响的设计文档没回写 / 留下业务认知偏差 | 严格走 W-重 + 全影响面扫描 |
| 把谱系 3 当谱系 1 处理 | 业务文件被 UI 细节污染 / domain 与 design 边界模糊 | UI 显化只入设计文件，业务文件保持稳定 |
| 把谱系 1 当谱系 2 处理 | 大量 W-重耗 Owner 时间 / 增量低 | 先 W-轻入册；如后续发现冲突再升 W-重 |
| 三谱系都不归（”挂账”） | 业务输入丢失 / 跨会话失忆 | 走 Owner-业务输入窗口.md § 3 三处承载强制落位 |
| 关联 | 关系 |
|---|---|
| Owner-业务输入窗口.md | 业务输入的收/入册/承载规范；每条输入必标谱系 |
| W-协议.md | 谱系 2 强制走 W-重 |
| cos-context.md §A 收尾协议 | 收尾自检：本会话产生的业务输入谱系是否标全 / 落点是否正确 |