# 原型 Review 指导

用于审查 Axhub Make client 原型的业务完整性、项目对齐、逻辑连贯性、数据一致性、状态、异常、边界条件和恢复路径。

本规则关注“这个原型表达的业务是否成立”。视觉美观、品牌一致性、响应式和可访问性问题按 `rules/ui-review-guide.md` 处理。

## 审查入口

当用户说「原型评审」「需求评审」「业务逻辑评审」「看看缺漏」「检查状态和错误处理」「帮我从业务角度挑问题」时，读取本规则并输出 Markdown 评审结论。

不要输出 JSON，不要写 JSON 文件。

## 审查依据

审查依据按以下优先级使用：

1. 用户当前说明、附件、链接、截图、需求文档、PRD、会议纪要、业务规则、字段表、数据样例等用户提供的信息源。用户提供的信息源权重最高。
2. `src/prototypes/<prototype-id>/.spec/` 中最近的决策、规格或计划 Markdown。排除 `ui-review.md`、`prototype-review.md` 和其他 review 结果。
3. `src/resources/` 中与当前原型相关的需求、业务资料、字段清单、流程记录和数据样例。
4. 当前原型源码、`canvas.excalidraw`、`annotation-source.json`、路由、页面配置和局部状态实现。
5. `.axhub/make/project.json` 等 metadata 只作为项目资源、入口和命名关系证据。

如果用户提供的信息源与 `.spec`、`src/resources/` 或原型实现冲突，以用户提供的信息源为准，并在评审中标记为「资料冲突/待确认」。不要用项目旧文件覆盖用户最新资料。

## 明确不审

- 不评价视觉美观、品牌一致性、响应式布局、可访问性细节或是否符合 `DESIGN.md`。
- 不把配色、圆角、间距、字体、图标风格作为原型 Review 问题。
- 只有当 UI 缺失直接导致业务状态、错误、流程或字段无法表达时，才作为业务完整性问题记录。

## 推荐审查流程

1. **确定目标**
   - 原型：`src/prototypes/<prototype-id>/`
   - 原型内页面：保留 `pageId`
   - 目标不清时，先问用户确认

2. **读取资料**
   - 先读取用户本轮提供的信息源
   - 再读取当前原型 `.spec` 中最新决策
   - 再读取相关 `src/resources/` 资料
   - 最后读取原型源码、画布和 metadata

3. **建立业务基线**
   - 确认核心用户、业务目标、主流程、关键对象和成功标准
   - 记录明确范围和不做范围
   - 标记资料冲突、缺失资料和需要用户确认的问题

4. **审查完整性和连贯性**
   - 检查主流程入口、出口、成功路径和必要分支
   - 检查空、加载、成功、失败、权限不足、无数据、部分成功等状态
   - 检查数据模型、字段名称、枚举值、状态值和业务口径是否一致

5. **审查边界和恢复**
   - 输入校验、范围上下限、空值、重复值、非法格式
   - 网络、系统、权限、资源不存在、会话过期、外部集成失败
   - 重复点击、并发编辑、数据过期、跨页面返回、流程中断
   - 每个重要错误都要有恢复路径，而不只是报错

6. **写入 `.spec`**
   - 原型级：`src/prototypes/<prototype-id>/.spec/prototype-review.md`
   - 页面级如后续需要：`src/prototypes/<prototype-id>/.spec/<page-id>/prototype-review.md`

## 核心审查维度

- **原型完整性**：核心用户、主流程、入口、出口、空/加载/成功/失败状态是否覆盖。
- **项目上下文一致性**：是否与用户资料、最新 `.spec` 决策、资源文档、项目 metadata、已有原型命名和范围一致。
- **业务逻辑连贯性**：流程顺序、状态迁移、角色权限、操作前置条件、数据生命周期是否自洽。
- **数据模型一致性**：实体、字段名、枚举、状态值、单位、时间/金额/数量口径是否在用户资料、资源、规格和原型中一致。
- **Edge cases**：输入校验、边界条件、系统/网络失败、权限失败、并发/重复操作、集成失败、恢复路径。

## Markdown 模板

```markdown
# Prototype Review

- 审查目标：src/prototypes/<prototype-id>
- 用户资料/参考资料：列出本次使用的用户资料、.spec、resources、源码或 metadata
- 生成时间：2026-05-22 00:00

## 总体点评

用 1-3 段总结原型在业务完整性、项目对齐、逻辑连贯性和风险覆盖上的整体质量。先说最影响业务成立的问题，再说可以保留的有效表达。

## P0-P3 优先级问题

### P1 - Finding title

- 证据：说明来自用户资料、.spec、resources、源码、画布或 metadata 的具体线索。
- 影响：说明对业务流程、数据口径、用户任务、状态理解或后续实现/测试的影响。
- 修复方向：给出可执行的需求、原型或资料补充建议。

## 完整性与项目对齐

说明核心用户、主流程、入口出口、范围边界、资料冲突、最新决策和项目资源是否对齐。

## 业务逻辑连贯性

说明流程顺序、状态迁移、角色权限、操作前置条件、数据生命周期和跨页面一致性。

## 状态、异常、边界与恢复

按输入校验、边界条件、错误状态、并发/重复操作、集成失败和恢复路径整理发现。没有明显问题时也要说明已检查。

## 证据与评估说明

- 用户资料优先级：说明是否存在用户资料，以及是否与项目内资料冲突。
- 读取范围：说明读取了哪些 .spec、resources、源码、画布或 metadata。
- 独立评估：full 或 degraded，并说明原因。
```

## 分组要求

前三组固定且顺序不可变：

1. `总体点评`
2. `P0-P3 优先级问题`，最多 5 条
3. `完整性与项目对齐`

可以追加额外分组，例如 `业务逻辑连贯性`、`状态、异常、边界与恢复`、`证据与评估说明`，但必须放在前三组之后。

## 优先级

- `P0`：核心业务流程无法成立，或与用户提供的明确需求/最新决策冲突。
- `P1`：主要流程、关键状态、权限或数据口径存在严重缺漏。
- `P2`：明显业务摩擦或边界缺失，但存在可用绕行。
- `P3`：低风险补充项，后续完善后会提升业务表达或测试覆盖。

不要使用 `P4` 或更低优先级。

## 子代理与独立评估

有子代理能力时，优先拆成两个独立评估：

- 业务完整性评估：只看用户资料、`.spec`、`src/resources/` 和 metadata，先判断业务基线。
- 原型证据评估：看源码、画布、路由、状态和页面实现，判断原型是否表达了业务基线。

两个评估完成前不要互相暴露结论。没有子代理时，先完成业务完整性笔记，再看原型证据，并在 `证据与评估说明` 中标记独立评估为 `degraded`。

当审查 3 个以上独立页面或业务流程时，优先按流程或页面拆分并行审查，最后统一综合成 `.spec/prototype-review.md`。

## 交付说明

最终回复至少包含：

- 审查目标
- 写入的 `.spec/prototype-review.md` 路径
- 使用的用户资料和项目资料
- P0-P3 数量
- 是否发现资料冲突/待确认项
- 独立评估是否完整