将 Discovery 作为相互关联的文档集审查

沿文档集追踪一项要求

本场景继续使用虚构设备申请服务。最初的规格说明允许经理录入申请。随后，团队添加员工自助功能。

这一变化不只影响一个页面。员工需要身份，以及访问自己申请的权限。经理可见范围需要明确边界。数据流和安全分析必须体现两种角色。

使用 Discovery 的 Context、Conversation 和 Documents 步骤，建立并检查这一意图。对于导入产品，代码仓库分析替代对话；请遵循单独的导入工作流。

包括规格说明在内，共有八份必需文档：

生成过程遵循依赖关系和发布顺序。接受后续文档采用的假设前，先审查前面的文档。生成的 DPIA 是评估材料；仅有这份文档，不能证明法律合规。

Look & Feel 和 Service Blueprint 是可选文档。如果渲染后的界面设计方案或服务描述有助于团队评估产品，可以使用它们。

规格说明最初是草稿。下游生成使用已发布版本。编辑会创建新草稿；发布新版本后，修改才对下游生效。

其他文档带有发布和审查信息。Generate remaining 可以依次生成缺失文档，每项结果都需要审查。生成结束，不代表有人已经确认假设正确。

对于设备服务，检查所有相关文档中的访问规则。正确的规格说明与过时的数据流，不能组成一致设计。

重新发布规格说明后，依赖它的已生成文档可能变为 Outdated。Taiga 不会悄悄改写它们。其他来源文档的变化，也可能影响依赖链中更后面的文档。

在 Discovery 开放期间，重新生成受影响文档。Generate remaining 包括过期文档。检查新结果，尤其是涉及多份文档的假设变化。

八份必需文档全部发布后，才能使用 Finish Discovery。Outdated 文档不会阻止完成。应亲自检查一致性，不要把按钮当作所有审查都已完成的证据。

完成后，文档集会锁定，下游产品工作流随之开放。需要修改已锁定文档集时，从文档中重新打开 Discovery。

规划前，说明当前用户角色、接受的限制和尚未解决的决定。检查 initiative 提案引用的文档是否描述同一个产品。

有用的审查结果应具体：“员工自助功能已体现在流程、授权设计、数据流和威胁处置中。”继续学习 initiatives，将这一意图转为工作。