对齐 Workflow / WorkflowRun 数据模型

[huyanxius]

背景

后端目前不存 Workflow，以后接管。前端已在 entities/workflow-run 实现本地状态推进
（见 #59），模型为单方面假设。本 Issue 只确认边界，不要求现在实现。

前端当前模型

interface WorkflowRun {
  id: string
  projectId: number
  characterId: number | null            // 建出角色前为 null
  driver: 'ai' | 'manual'
  intent: 'create-character' | 'edit-character' | 'add-action'
  status: 'draft' | 'running' | 'paused' | 'completed' | 'failed'
  currentStepId: string | null
  steps: WorkflowStep[]
}

interface WorkflowStep {
  id: string
  type: 'generate-template' | 'confirm-template'
      | 'add-action' | 'generate-action' | 'review'
  status: 'pending' | 'running' | 'done' | 'failed'
  actionId: number | null
  taskId: string | null
}

推进方式：前端提交命令，本地校验后改写步骤状态，如 { kind: 'add-action', name: '行走' }。

需要确认

1. Workflow 与 WorkflowRun 是一个对象还是两个？
可保存复用的节点图与一次具体执行，前端当成了同一个。07-22 会议提过这个歧义。

2. 一个项目能有几条 WorkflowRun？
前端按一对多实现，项目详情页列出未完成的供用户选择。但 windup_project.workflow_id
是单数字段——若为一对多，该字段表示什么？

3. 步骤在创建时排好，还是随操作追加？
前端是追加：初始两步（生成母版、确认母版），每加一个动作追加两步。
五种步骤类型是否够用？

4. 一个步骤能关联几个任务？
前端每步只有一个 taskId。生成失败重试会产生第二个任务，是否需要保留任务历史？

5. 后端接管后谁校验命令、谁推进状态？
现在前端全权。将来后端是只负责存取（前端算好整份提交），还是校验命令并返回权威状态？
前端提交非法状态（母版未确认就加动作）时，后端是否拦截？

6. 三个字段的归属

• characterId：谁在何时写入？实测走完建角色流程后仍为 null，「给已有角色补动作」
  入口因此不可达。
• intent：区分新建角色 / 编辑角色 / 补动作三种入口，后端持久化还是纯前端状态？
• id：架构文档写 string，windup_project.workflow_id 是 BIGINT。

本次范围

只确认领域模型与责任边界。SSE 事件格式、精灵尺寸口径、鉴权、动作帧数另开 Issue。

Refs #58 #59

[nighca]

后端目前不存 Workflow，以后接管

为啥不是现在就做成后端存？

[huyanxius]

后端目前不存 Workflow，以后接管

为啥不是现在就做成后端存？

后端的同学说来不及了

[nighca]

@huyanxius 是说这周来不及实现？这个没关系的，还是按后端存来设计接口，只是到时候前端“entities”的实现先走内存读写而不是调用服务端接口就好

[huyanxius]

@huyanxius 是说这周来不及实现？这个没关系的，还是按后端存来设计接口，只是到时候前端“entities”的实现先走内存读写而不是调用服务端接口就好

好的

[xiaocheny214]

一个项目能有几条 WorkflowRun？

这边有歧义。
在后端我做如下定义：
workflow
负责最终产品的工作流定义，不负责具体执行：
工作流定义；
节点类型；
节点配置；
输入输出端口；
节点连接；
DAG 合法性校验；
工作流保存、复制和复用；
工作流模板和版本。
节点可以代表 Prompt、角色模板生成、动作生成、审查、导出等能力。节点定义本身不等于 AI 实现。
execution
负责运行工作流：

创建执行任务；
固化工作流版本和项目约束快照；
拓扑排序和节点调度；
节点执行状态；
异步任务投递；
重试、取消和失败恢复；
中间结果缓存；
进度事件。
execution 是最终产品的动态执行能力。当前 MS2 可以暂不实现它，前端直接调用各独立业务能力。

generation
负责生成类业务用例：

角色模板生成；
动作生成；
精灵图集生成；
参考图和生成参数组装；
项目约束快照；
积分预估和扣减；
创建异步生成任务；
调用 ai_engine；
生成候选资产并交给 asset 登记。
generation 是业务编排

即 workflow 代表得是最终编排在前端页面所展示得图，可以有多条生成流程并行执行。故windup_project.workflow_id 使用单个字段挂在Project项目之上。

步骤在创建时排好，还是随操作追加？

前端是追加：初始两步（生成母版、确认母版），每加一个动作追加两步。
由于现阶段仅看到是前端单独维护节点得编排，采用追加得方式。与后端最终预设节点编排存在差异。
后端预想节点编排功能如下：
用户可在某一展示工作流的UI页面之上，自由组装如提示词节点、角色生成节点、角色人物动作生成节点等。
如此可根据连线，组装成图的形式，用户仅需要输入提示词，来达到并行生成角色相关资产的操作。
这样看起来显得更加灵活，且节点编排得工作流数据可直接存储进入相关workflow表中。后续仅需要通过workflow.id与project表关联即可达到工作流复用概念。
前端是定义步骤类型，未详细定义节点。

一个步骤能关联几个任务？

前端定义步骤概念，比如生成角色walk步骤，后端便会提供调用实现生成角色walk的接口，以便前端完成。

后端接管后谁校验命令、谁推进状态？

如果最终产品形态便是现在MVP展示这般，用户执行预设好的，前端把工作流程写死得这种，那么前端负责推进状态，是再好不过的，因为实现起来简单，仅需要在每一步骤下面调用需要调用的接口即可实现该功能。校验命令需丢给后端逻辑来做。

如果最终产品形态是用户可随意增添节点、组装成节点图，状态推进、校验均需要交给后端来做。

三个字段的归属

characterId：谁在何时写入？实测走完建角色流程后仍为 null，「给已有角色补动作」
入口因此不可达。
intent：区分新建角色 / 编辑角色 / 补动作三种入口，后端持久化还是纯前端状态？
id：架构文档写 string，windup_project.workflow_id 是 BIGINT。

这边我是不明白，这三个字段为什么要划分归属？后端的接口逻辑，是仅向前端提供可调用的能力。即你需要生成角色模板，就传给后端接口，角色模板需要用到的字段，如像素大小、提示词、以及需要多少张图。