Initial commit: OneOS prototype workspace baseline.

Include weekly report and other prototype sources with project tooling config.

Co-authored-by: Cursor <cursoragent@cursor.com>

rules/prototype-review-guide.md

@@ -0,0 +1,151 @@
+# 原型 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 数量
+- 是否发现资料冲突/待确认项
+- 独立评估是否完整