04 · 流程与状态治理
每次推进需求，都需要知道当前做到哪一步、谁可以操作、还缺什么。Northstar 用明确的状态与动作规则组织研发，让模型的建议能够转化为有条件、有记录的实际操作。
需求、变更与待办各有归属
需求组织一次从目标到交付的完整工作；变更描述更细的调整及其影响；待办记录角色接下来需要处理的事项。它们分别维护自己的状态，再通过引用与交接连接起来。
例如 Dev 在技术设计中发现业务规则不明确，可以提出产品异议。PM 确认或修订需求后，Dev 承接新的结论更新设计。系统保留问题、回答、产物和当前阶段，角色切换后可以找到尚未完成的工作。
变更流程、Dev 签核以及 QA、发布检查和复盘环节已有相应规则与记录机制，目前仍标为实验性，正在持续完善。
从推荐路径到正式执行
| 机制 | 负责的问题 |
|---|---|
| 工作流图 Workflow Graph | 描述阶段之间的路径、动作顺序、角色交接和返回处理方式。 |
| 动作契约 Operation | 定义一次动作的输入、执行方式与结果，例如评审、确认问题或签核。 |
| 展示条件 | 根据当前角色、阶段与材料，决定哪些动作值得呈现给用户。 |
| 领域门禁 Domain Gate | 执行时重新检查权限、状态与证据，裁决是否允许正式写入或推进。 |
工作流图在加载时检查引用和路径，并生成版本指纹。客户端读取服务端计算的当前动作，减少界面、推荐路径和业务规则各自维护一套逻辑造成的不一致。
准备度、评审与签核分别回答不同问题
- 准备度检查：材料齐了吗？哪些问题尚未解决？下一步由哪个角色补充？
- 语义评审：内容是否完整、可执行、可验证？设计是否承接了需求？
- 正式签核：当前角色是否确认这一版产物，并在条件满足后推进阶段？
查看阻塞用于了解当前缺口，完成评审会保存评审结果；正式阶段推进需要提交相应动作并通过门禁。以 PRD 签核为例，系统读取当前产品需求文档、有效评审和待解决问题，确认条件满足后才记录签核结果。
旧按钮提交时，再查一次当前事实
页面展示动作后，产物或需求状态可能继续变化。推荐动作因此绑定生成时的需求版本、工作流版本和角色，提交时重新核对当前条件。停留很久的页面也需要通过这次检查。
- 读取当前事实，生成可用动作与阻塞说明。
- 用户选择具体动作，提交必要字段。
- 核对来源、版本、角色、授权和门禁。
- 由负责该业务对象的模块写入，保存结果。
- 根据新状态刷新待办与下一步。
自由讨论与正式变更能够并存
用户可以随时补充背景、质疑方案或调整目标。对话承载讨论，系统将需要实际变更的意图转换为明确动作，再按相同规则校验。遇到异议时返回处理，满足条件后继续推进，让正常路径与返工都有位置。
流程治理回答的是“现在允许做什么”。产物变化后评审还能否使用，由下一篇 知识与版本一致性 进一步说明。