Web UI 基础组件迁移策略
决策
引入 Radix UI 作为 Aurevoy Web UI 的无样式交互基元；继续使用项目现有的 CSS 自定义属性与组件级 CSS，暂不引入 Tailwind CSS。
已迁移的高风险交互包括：
Dialog：图片预览、Provider 连接、Skill 详情；DropdownMenu：所有现有右键菜单（经虚拟锚点兼容既有调用方）；Toast：全局通知；Tabs：Skills 来源切换。
这些组件由 Radix 统一处理焦点回收、键盘导航、Esc、点击外部关闭、Portal 和视口碰撞，业务组件只保留状态与内容。
分层约定
text
业务页 / 领域组件
↓
components/ui（Radix 组合基元，后续集中沉淀）
↓
Radix UI（可访问性与交互行为）
↓
CSS 令牌 + 组件级 CSS（Aurevoy 视觉系统）新增浮层、菜单、模态框、选择器或页签时，优先使用对应 Radix primitive。不要在业务组件中重新实现全局事件监听、焦点遍历或 Portal 定位逻辑。
Tailwind CSS 评估
当前不引入。项目的视觉体系已经基于 App.css 中的语义令牌（主题、字号、间距、圆角、阴影）和高密度的既有语义类名；全面切换 Tailwind 会产生较大的双轨样式期，并把桌面端细粒度状态样式分散到 JSX 中。
| 维度 | Tailwind 的潜在收益 | 本项目当前成本 | 结论 |
|---|---|---|---|
| 新组件开发 | 原子类可缩短简单布局编写 | 现有 CSS 令牌和大量组件类需要并存或迁移 | 暂缓 |
| 主题一致性 | 可映射 token 为 utility | data-theme、color-mix 与组件状态规则迁移量大 | 暂缓 |
| 构建体积 | 生产时可按内容裁剪 | 对已有 CSS 无直接减量，迁移期间反而增加维护面 | 暂缓 |
| 可访问性 | 无直接提升 | Radix 已覆盖交互可访问性关键缺口 | 不构成引入理由 |
重新评估的触发条件：新页面或新组件有超过约 30% 采用 utility class 的明确需求、设计令牌能先被抽取为统一配置、或团队决定在一个独立功能域完成 CSS 到 utility 的完整迁移。届时应先做单一功能域试点，禁止新旧写法无边界混用。