# 完整使用演示：从新需求到 Ready Spec

本页记录 2026-08-27 在真实 DSH 工作台中完成的一次全新流程。演示需求为“演示：需求列表快速复制分享链接”，从新建开始，依次经过产品 AI 初审、人工澄清、候选 Patch、产品确认、Decision、研发检查和 Ready 质量门。所有截图均使用 ego-browser 重新截取，截图前已收起 DSH 主侧边栏。

## 演示需求

目标是在桌面端与窄屏需求列表中增加“复制分享链接”：接收者打开链接后直接看到目标需求；复制失败、需求不存在和访问被拒绝时给出明确反馈。需求同时约束地址结构、隐私字段、归档需求、键盘操作与读屏播报，不扩展现有访问权限，也不涉及短链、二维码或批量复制。

## 1. 从空白表单新建需求

在需求栏中新建需求，填写标题、原始需求和来源，并选择真实项目工作区 `dsh-spec-collab`。工作区是后续 AI 审核读取代码、测试、Git 历史和项目说明的上下文边界；创建后，原始输入形成首个 Git commit。

![新建需求并选择工作区](assets/demo-01-workspace.png)

## 2. AI 初审，产品逐项澄清

运行智能初审后，AI 将模糊点拆成可回答的问题。本次实际澄清了四类关键边界：将原始描述重组为完整正式 Spec；分享地址只携带稳定需求 ID；链接默认打开需求正文，不保存页签、滚动位置或侧栏状态；只调整需求列表入口，其他复制链接入口不在范围内。

![AI 审核问题和人工回复](assets/demo-02-ai-review.png)

回答时应区分事实、推断、假设和待核验内容。当前无法从工作区证明的实现细节保留为 `TO_VERIFY`，不把推测包装为已经确认的事实。

## 3. 审核并接受候选 Patch

AI 根据产品回答生成候选 Patch，人工在写入前检查完整正文、受影响章节和验收标准。本次候选内容补齐了目标与非范围、地址片段规则、剪贴板失败兜底、无效或无权链接语义、七条场景化 AC 及测试约束。

![审核并接受候选 Patch](assets/demo-03-patches.png)

候选 Patch 绑定精确 `baseCommit`。只有人工接受后才会生成新的 Git commit；正文再次变化时，旧 Patch 与受影响确认会自动失效。

## 4. 产品确认并记录 Decision

产品检查当前版本后确认 commit，并把关键取舍记录为独立 Decision。本次生效决策为：使用需求级地址片段，只包含编码后的稳定需求 ID，默认打开需求正文；不保存页签、滚动位置或侧栏状态。理由是该方案与工作台已有深链模型一致，同时避免把协作内容或本地路径写入链接。

![已生效的产品 Decision](assets/demo-04-decisions.png)

Decision 与普通评论分离，保留结论、理由、确认人和生效状态，供后续研发检查与 Ready 输出追溯。

## 5. 研发检查与 Ready 质量门

进入产研确认后运行研发检查，重点核对现有实现、影响范围、兼容性和测试落点。产品与研发必须确认同一个当前 commit；之后才能检查六项 Ready 门：目标与用户结果、稳定验收标准、范围与非范围、业务语义、证据来源和测试约束。

![Ready 质量门与最终 Ready Spec](assets/demo-05-ready.png)

本次 Ready Spec 绑定 commit `233338d6e1a4b1cec758d5348abdff04f76a5a88`，产品确认人为“验收人员”，研发确认为“演示研发”。Ready 输出保留稳定 AC、生效 Decision、来源、非阻塞 Open Questions 以及双方确认人。它是交给研发和开发 AI 的需求合同，不代表代码已经实现、测试已经执行或版本已经发布。

## 使用原则

1. 每条需求从新建开始绑定真实项目工作区，不在不同项目上下文之间复用审核结论。
2. AI 负责检查、追问和提出 Patch；写入 Git、确认版本和判定 Ready 始终由人完成。
3. 事实必须带可访问且版本固定的证据；证据不足时明确保留 `TO_VERIFY`。
4. 接受 Patch 前检查 `baseCommit` 和变更范围；正文变化后重新完成受影响的审核与确认。
5. 产品与研发确认同一个 commit，六项质量门全部通过后再输出 Ready Spec。