以小批量可审查的切片推进应用质量提升，不破坏现有工作流，不在大范围重构中隐藏风险。
核心原则
- 保留现有架构，除非某个边界明显导致频繁变更、性能损耗或用户可见 bug
- 每个问题优先找最小正确补丁，然后重复
- 将必要修复与可选优化分开，让维护者可以独立落地高价值工作
- 保持插件面向行为有文档且向后兼容
- 优先改善主用户路径：onboarding、auth、chat、provider 设置、插件管理、诊断
六个阶段
Phase 1：基线审计
在修改前盘点现有应用状态：
- 识别核心用户工作流及其代码归属
- 列出死代码、重复设置、不清晰的错误状态、昂贵的渲染路径
- 将问题标记为 required / recommended / optional
- 记录需要 owner 审查的已知阻塞项（API、安全、发布、插件合约变更）
完成标准：一份带仓库文件引用的问题列表，每个问题有严重程度、归属面、预期用户影响和验证路径。
Phase 2：产品与 UX 清理
- 收紧 onboarding 文案和空状态（model auth、gateway 状态、插件设置）
- 移除或禁用无法操作的死功能
- 在响应式宽度下保持重要操作可见
- 合并重复的状态语言，让错误有唯一来源
Phase 3：前端架构收紧
- 将重复的 UI 状态转换移入窄类型 helper
- 保持数据获取、持久化、展示职责分离
- 优先使用现有 hooks、stores、组件模式，而非新抽象
- 仅在减少耦合或明确测试时才拆分过大组件
必须保持：不因文件拆分改变公开行为；保持菜单、对话框、标签页、键盘导航的无障碍行为。
Phase 4：性能与可靠性
- 测量启动、路由切换、大列表、聊天记录的开销
- 用 memoized selector 或缓存 helper 替换重复昂贵的派生数据（需 profiling 证明价值）
- 为热路径 helper 和合约边界添加轻量回归测试
每个性能变更需记录：基线、预期影响、实际影响、剩余差距。
Phase 5：类型、合约与测试加固
- 用判别联合或封闭代码列表替换松散运行时字符串
- 用现有 schema helper 或 zod 验证外部输入
- 为插件 manifest、provider catalog、gateway 协议消息、config 迁移行为添加合约测试
验证命令：
pnpm check:changed
pnpm build # 当 lazy 边界、打包或发布面变更时Phase 6：文档与发布就绪
- 行为、API、config、onboarding、插件变更时同步更新文档
- 仅为用户可见变更添加 changelog 条目
- 确认发布和安装说明与当前命令面匹配
推荐首个切片
从 Control UI 和 onboarding 的范围审计开始：
- 审计首次运行设置、provider auth 就绪状态、gateway 状态、插件设置面
- 移除死操作，明确失败状态
- 为状态派生和 config 持久化添加或更新聚焦测试
- 运行
pnpm check:changed
前端交付标准（Skill 摘要）
- 从现有产品工作流和代码约定出发
- 最小正确补丁优先
- 在响应式宽度下保持操作可见可用
- 移除死功能而非留下无法操作的控件
- 保留 loading、empty、error、success、permission 状态
- 使用现有设计系统组件、hooks、stores、图标