laily
af6e139d30
short-ship and long-ship share one ship-id record under .pouch/ship/<id>/. specifier writes PRDs into spec/; delivery-loop appends evidence pointers. Old names stay as deprecation stubs so existing installs keep working.
40 lines
2.2 KiB
Markdown
40 lines
2.2 KiB
Markdown
# HTML PRD 生成规范
|
|
|
|
## 页面目标
|
|
|
|
HTML 是给人离线评审的交付物，不是运行中的产品页面。它必须自包含、可打印、可搜索，并且
|
|
在没有网络、构建工具或额外服务时仍能阅读。
|
|
|
|
推荐使用 [templates/prd.template.html](../templates/prd.template.html) 的结构；可以按需求增删
|
|
章节，但不能删除版本信息、变更摘要、未决问题和验收标准。
|
|
|
|
## 必需章节
|
|
|
|
1. 摘要：需求、目标用户、问题和成功标准。
|
|
2. 范围：包含项、非目标、约束和假设。
|
|
3. 场景：用户角色、主流程、异常流程和权限边界。
|
|
4. 方案：候选方案、取舍、推荐方案和被否决方案。
|
|
5. 设计：交互、领域模型、状态流、API/数据变化和迁移。
|
|
6. 非功能：安全、性能、兼容性、可观测性、发布和回滚。
|
|
7. 任务预览：垂直切片、依赖、关键路径、`expected`、`verification`。
|
|
8. 验收：逐条可观察的用户、API、数据和错误信号。
|
|
9. 风险与未决：负责人、影响、缓解动作和需要确认的选择。
|
|
10. 版本记录：当前版本、基线版本、本轮变更和评审状态。
|
|
|
|
## 渲染要求
|
|
|
|
- CSS 写在页面内，脚本只用于不影响阅读的目录或打印增强。
|
|
- 不使用远程 CDN、远程字体、外部图片或需要联网的脚本。
|
|
- 颜色和状态不能只依靠颜色表达；为状态提供文字标签。
|
|
- 长表格允许横向滚动，代码或 API 示例使用 `pre`，正文保持可复制。
|
|
- `h1` 只有一个；标题层级连续；链接和表格有可读的焦点/边框状态。
|
|
- 页首显示 ship id、PRD 版本、状态、生成时间和基于的版本。
|
|
- 变更内容用文字摘要或 `ins` / `del` 标记表达，不要只用颜色标记。
|
|
|
|
## 内容质量
|
|
|
|
- 把“体验好”“性能足够”“支持权限”等不可验证表述改成可观察信号或明确待决策项。
|
|
- 不把实现方案伪装成用户需求；需求、决策和任务分开写。
|
|
- 未知事实写“待确认”，并加入未决问题，不填看似合理的数字、接口或页面。
|
|
- 每条验收都能被 long-ship / Test 按步骤观察；测试工具不可用时仍能区分产品失败和环境失败。
|