# Design Review Workflow

适用场景：建筑行业平台界面方案评审、页面任务评审、工作台体验评审、前端实现前的设计交接

## 目标

在实现前发现界面方案中的真实缺口，把页面任务、信息架构、证据定位、复核动作、交互状态、中文文案、响应式、可访问性和验收方式补清楚，避免工程师根据模糊描述生成不可用、不可复核或不可验收的 UI。

## 参与角色

| 阶段 | Agent | Skill |
| --- | --- | --- |
| 产品契约输入 | Janus | `aios-product` |
| 产品和体验判断 | Janus | `aios-design` |
| 架构 / 数据边界补充 | Atlas | `aios-arch` |
| 实现交接 | Hephaestus | `aios-exec` |
| 代码和风险审查 | Argus | `aios-review` |

## 输入

- 页面目标、用户角色和关键任务。
- 已确认的版本范围、非目标、用户故事和产品验收指标；缺失时先交回 `aios-product`。
- 页面、组件、流程、状态和数据对象。
- 现有设计系统、组件库、截图或参考界面。
- 目标设备、浏览器、可访问性和验收要求。
- 建筑行业语义：项目、图纸、模型、构件、规范条文、审查项、证据、报告和人工复核。
- 图纸定位：页码、轴网、楼层、专业、视图、批注和图纸版本。
- 模型定位：IFC GUID、构件树、空间层级、构件属性、模型版本和版本对比。
- 审查结论：规则来源、命中依据、证据片段、人工复核状态、确认人和撤回路径。
- 长任务：上传、解析、索引、审查、报告生成、失败恢复和重试。

## 执行顺序

1. Janus 判断版本范围、用户故事和产品验收是否足以进入设计；缺失时先用 `aios-product` 补齐产品契约。
2. Janus 判断是否存在 UI / UX 范围；没有则退出并推荐其他 workflow。
3. Janus 盘点已有组件、样式、术语、表格、Viewer、证据定位、状态组件和可复用模式。
4. Janus 按 0-10 评分法评审信息架构、工作流效率、状态覆盖、领域证据呈现、中文术语、响应式 / 可访问性、界面决策清晰度、设计系统一致性和实现交接清晰度。
5. 对低于 8 分的维度，说明达到 10 分需要补什么，并给出可执行修正；涉及版本范围、用户故事或产品验收的未决事项交回 `aios-product`。
6. 如果设计缺口涉及数据链路、权限、长任务、证据链或服务边界，交给 Atlas 补做架构评审。
7. 设计计划达到可实现状态后，交给 Hephaestus 执行前端实现或修改。
8. 实现完成后，Argus 做代码 / 风险审查，并根据需要执行浏览器或截图验证。

## 输出

- 适用性结论。
- 总体设计完整度和维度评分表。
- P0 / P1 / P2 设计缺口。
- Unresolved Decisions。
- 修正后的界面方案。
- 实现交接和验证建议。

## 验收标准

- 页面有明确任务，而不是泛化展示页。
- 关键状态都有用户可见表现和操作路径。
- 建筑行业对象、证据链和复核点在 UI 中可定位、可追溯、可撤回。
- 图纸页码、轴网、楼层、专业、IFC GUID、构件树、空间层级、规则来源和命中依据有清楚呈现策略。
- 上传、解析、索引、审查和报告生成等长任务有进度、失败恢复和重试路径。
- 专家复核能说明谁确认、确认什么、何时确认以及如何追溯。
- 中文文案、术语、错误和状态一致。
- 桌面、窄屏、移动端和可访问性策略明确。
- 工程实现者能根据计划写代码、运行验证并判断是否完成。

## 约束

- 不把设计评审替代为代码审查。
- 不把文本设计评审当成最终视觉 QA。
- 不替代 `aios-product` 定义用户问题、版本范围、优先级、产品指标和试点 / UAT。
- 不替代通用 `frontend-design` 的视觉风格和前端代码美化评审。
- 不替代 `frontend-generation` 的 UI 实现、布局验证和交互验证。
- 不引入新设计系统，除非已有系统无法支撑关键任务。
- 不生成营销页式 UI 来替代工作台、后台、Viewer 或审图工具。