55 lines
2.3 KiB
Markdown
55 lines
2.3 KiB
Markdown
# Change: 为 opentu 引入 Stitch 驱动的设计闭环工作流
|
||
|
||
## Why
|
||
|
||
当前 `opentu` 的前端页面与面板主要直接在代码中设计和实现，缺少一条稳定的“设计探索 -> 方案沉淀 -> 代码回收”的闭环。
|
||
这会带来三个直接问题：
|
||
|
||
- 新页面或复杂面板的视觉方案探索成本高，难以快速比较多个方向
|
||
- 设计稿、实现代码、页面映射关系分散，后续复用和迭代成本高
|
||
- 即使使用 Stitch，也缺少明确的仓库内落点，容易变成一次性的外部试验
|
||
|
||
我们希望把 Stitch 接入为一个受控的设计工作流：
|
||
- 先把适合的页面和面板送入 Stitch 进行方案设计
|
||
- 再通过 MCP 将 screen 与 design system 信息拉回仓库
|
||
- 最终由本地 React/业务层完成生产实现
|
||
|
||
## What Changes
|
||
|
||
- 引入仓库内的 Stitch 工作流约定，包括 `.stitch/` 目录、screen 映射文件与设计规范文档
|
||
- 定义首批适合走 Stitch 的 UI 范围，优先覆盖外围页面、抽屉、弹窗、空状态页，不直接覆盖核心白板编辑器
|
||
- 规范从 prompt 到 Stitch screen，再到 MCP 拉取与本地编码实现的标准流程
|
||
- 明确代码与设计的边界：Stitch 负责视觉方案与结构参考，仓库代码仍然是交互行为与生产实现的唯一真源
|
||
- 为后续将 Stitch screen 回收为 React 组件提供可追踪的映射关系
|
||
|
||
## Impact
|
||
|
||
- Affected specs:
|
||
- `stitch-design-workflow`
|
||
- Affected code:
|
||
- `.stitch/*`
|
||
- `apps/web/src/app/*`
|
||
- `packages/drawnix/src/components/*`
|
||
- `packages/drawnix/src/contexts/*`
|
||
- `packages/drawnix/src/hooks/*`
|
||
- 未来首批接入页面对应的样式与组件文件
|
||
|
||
## Initial Rollout Scope
|
||
|
||
- 首批纳入 Stitch 设计闭环的页面/模块：
|
||
- `CrashRecoveryDialog`
|
||
- 设置面板 / 设置对话框
|
||
- 项目抽屉 / 项目列表
|
||
- 媒体库面板
|
||
- 空状态页 / 引导页
|
||
|
||
- 首批明确不纳入 Stitch 主导设计的页面/模块：
|
||
- 核心白板画布
|
||
- 涉及拖拽、框选、缩放、插件联动的编辑器核心交互
|
||
- 多标签同步、任务队列、画布操作等逻辑驱动区域
|
||
|
||
## Relationship To Existing Changes
|
||
|
||
- 本变更与现有 provider / runtime model 相关提案无直接冲突
|
||
- 本变更关注前端设计工作流与设计资产管理，不改变当前模型路由、任务执行和 SW 通信架构
|