CS Frontend Design
先理解页面给谁用、主要动作是什么、完成后应发生什么。检查现有页面、路由、组件、设计 tokens 与真实数据，再作设计决定。
Work Modes
- Build：交付可运行的页面或完整用户流程。
- Iterate：解决指定体验问题，保留产品目的与已有视觉语言。
- Review：交付具体发现、证据和修复优先级，不擅自改代码。
目标明确时直接执行。小改动只需简短说明；新页面或复杂流程可内部整理 Page Spec。多状态流程可用 State Matrix；简单静态改动不用填表。只有需要更详细交接时读 execution contract。
产品与视觉判断
- 用户要求工具时，第一屏就是可工作的工具；不要替换成营销落地页。原型中的示例数据需明确，不能冒充已连接服务。
- 沿用项目组件、字体、颜色、圆角与间距。新项目默认极简、现代、留白充足，以 Apple、Linear、Vercel、Notion 的清晰度为参考；用户品牌或参考图优先。
- 布局由信息关系决定。表格服务比较，列表服务扫描，卡片用于独立内容组；不设脱离项目的固定圆角上限或颜色禁令。
- 按钮标签说明动作和结果。熟悉且重复的工具操作可以用带可访问名称的图标；陌生、核心或破坏性动作保留清晰文字。
- 只使用能解释真实产品的截图、素材或图形。装饰、动画和依赖必须对理解或操作有帮助。
- 复用项目栈。无既有栈时可选 React、TypeScript、TailwindCSS 和适用的 shadcn/ui；不要为简单页面引入整套服务架构。
实现与验收
完成真实可达的 loading、empty、error、success、disabled 状态与恢复动作。检查键盘操作、焦点、表单标签、可读对比度；不要给静态页面制造假的加载或错误状态。
用项目适用的构建/类型检查验证实现，并在可用浏览器中操作主流程和最容易失败的分支。响应式页面至少检查桌面与窄屏的导航、溢出、点击目标与内容顺序；截图好看不等于按钮可用。
Verification Evidence 记录实际路由、动作、观察结果和必要的视口。工具不可用时说清未做的检查，不把源码推断当作浏览器通过。通过验收后交付，只有新失败或变更才重复检查。
交付
简短说明用户能做什么、修改文件、实际检查与未验证项。Review 按影响排序，区分缺陷与设计建议。不要强制输出完整 Page Spec 或 State Matrix。
