refactor(workflow-controller): align six-node asset generation graph

[xyh202131]

本次更新

• 工作流统一为六个真实 node：角色设定、角色母版、动作首帧、动作生成方式、完整动画、审核。
• node 关系通过 dependsOnNodeIds 明确保存，不再使用 Step、假 root 或数组位置推断边。
• 新增 Action 只允许依赖一个角色母版 node，避免持久化后无法执行的图。
• 重做按图的后代关系处理，只重置目标分支；保留显式边，不影响其他并行 Action。
• 重做角色母版时会隔离尚未返回的旧 Generation，新执行不会复用旧命令或接收迟到结果。
• 已归档 Action 的历史 node 不会被共享上游重做清空，也不会在恢复、解锁、执行或 SSE 写回时重新激活。
• 并行 Action 独立结算，一个 Action 失败不会阻止其他 Action 接收生成结果。
• 中断仅暂停前端订阅，resume() 可继续恢复后端任务；后端没有取消接口，因此不伪装成已取消任务。
• 3D 转 2D 选择随 WorkflowRun 落库，但接口提供前明确阻止误走视频裁剪。

页面读取方式

• getWorkflow() 提供首次或即时快照。
• subscribe() 是 UI 持续接收 WorkflowRun 更新的主渠道。
• 生成、确认、重做等修改方法只返回 Promise<void>，不再额外返回另一份 WorkflowRun。
• Quick Start 的实际使用与自动推进实现见 refactor(quick-start): align with six-node workflow controller #95。

边界

• entities/workflow-run 定义纯数据和异步 CRUD，Controller 负责前端 node 推进规则。
• 后端保存 WorkflowRun 图快照，不负责决定下一个 node。
• Controller 不新增页面、Playtest、发布、导出或后端实现，保持 chaifen/02-workflow-controller 最小单元。

验证

• 全量前端测试：26 files / 182 tests 通过。
• TypeScript 类型检查、oxlint、变更文件格式检查通过。
• 生产构建通过。

仓库级格式检查仍会报告既有文件格式问题；它们不属于本 Controller PR，因此未扩大改动范围。

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
windup	Ready	Preview	Aug 10, 2026 12:32am

[fennoai]

Three concrete issues keep this flow from being reliable as-is.

[xyh202131]

@fennoai 复审

[fennoai]

Re-review Result

Found 1 issue on the updated PR.

• Medium frontend/src/entities/workflow-run/api.ts:85: the WorkflowRun response validator accepts nodes whose status and phase contradict each other. For example, a character node with status: 'passed', phase: 'configuring_character', and selectedImageUrl: null passes validation because the selected image is required only when phase === 'completed'. The controller treats dependencies as satisfied solely via status === 'passed', so a corrupted persisted node can unlock downstream Action nodes without the confirmed character asset. Please make the validator enforce the status/phase matrix, especially passed => phase: 'completed' plus the selected asset, and add a regression test for this mismatch.

Verification:

• Reviewed the fixed range ab6e8d1e31385bcccc9cd9c18b38469fd4b4a22b...2f73825642a0954c3536f0b247a27c16b7c84e99.
• Confirmed the prior FennoAI findings were against an outdated file and the replacement controller addresses the subscription-before-GET and interrupt settlement races.
• git diff --check passed locally.
• Focused local Vitest run could not start in this checkout: vitest: Permission denied, with no local node_modules/vitest present. Collected GitHub checks for the head commit are green, including frontend checks and lint/test.

View job run

[xyh202131]

@fennoai 复审

[fennoai]

复审结果

发现 1 个中等严重度问题，已作为行内 review 提交：从共享的角色设定/角色母版节点重做时，会同时重置带 deletedAt 的已归档 Action 后代，清空其生成历史与选择结果，并可能再次将其激活。需要在后代重置、可用性计算和执行检查中隔离归档节点，并补充对应回归测试。

此前反馈的 passed/phase 响应校验与状态订阅渠道问题已修正。

验证

• 固定复审范围：2231b9ae527921e61b638284a8bf1285fca0390b...b1c86bf06c5b9209e35996d6c1f2591492c1bc7d
• git diff --check 通过。
• 当前 head 的 GitHub Frontend checks、lint-and-test、提交信息与分支名检查均通过。
• 本地未安装 node_modules，因此 Vitest/TypeScript 命令无法在该工作区启动；未将此视为代码失败。

View job run

[fennoai]

复审发现 1 个仍需处理的生命周期问题；此前关于状态交付与 passed/phase 校验的反馈已修正。

[xyh202131]

@fennoai 复审

[fennoai]

Review Complete

• 锁定并审查固定提交范围 2231b9ae527921e61b638284a8bf1285fca0390b...b239575bd9311bda7513640ef6bca7478df05f78
• 完成代码质量、性能、安全与文档检查
• 运行 npm test：26 files / 182 tests 通过
• 运行 npm run typecheck、npm run lint、npm run build、npm run format:check：通过

未发现足以提交 PR 反馈的确定性问题。已发布非阻塞 COMMENT 复审。

View job run

[fennoai]

复审完成：未发现足以提交 PR 反馈的确定性问题。重点检查了六节点图关系、归档/重做分支隔离、迟到 Generation 结果、并行 Action 结算、3D 转 2D 防误调用，以及 WorkflowRun 响应校验。

[huyanxius]

@fennoai 检查一下我说的问题是否属实

[fennoai]

检查结果

• 我读取了 PR refactor(workflow-controller): align six-node asset generation graph #107 的完整讨论；当前触发评论“检查一下我说的问题是否属实”前，没有看到你具体描述问题、复现步骤或截图，因此无法准确判断你指的是哪一项。
• 如果你指的是最近讨论中的“从角色设定/角色母版重做会污染已归档 Action 历史”，该问题在提交 b239575 中已修复：后代遍历跳过 deletedAt 节点，归档节点不会被重置或重新激活，生成入口、恢复和迟到结果也会拒绝/跳过归档节点。
• 对应回归测试已覆盖；controller.test.ts 定向运行结果为 1 file / 31 tests 通过。

请把你说的具体问题（最好附文件/行号、操作步骤或截图）补充到 PR，我可以继续针对该问题复现核查。

View job run

[huyanxius]

检查结果

• 我读取了 PR refactor(workflow-controller): align six-node asset generation graph #107 的完整讨论；当前触发评论“检查一下我说的问题是否属实”前，没有看到你具体描述问题、复现步骤或截图，因此无法准确判断你指的是哪一项。
• 如果你指的是最近讨论中的“从角色设定/角色母版重做会污染已归档 Action 历史”，该问题在提交 b239575 中已修复：后代遍历跳过 deletedAt 节点，归档节点不会被重置或重新激活，生成入口、恢复和迟到结果也会拒绝/跳过归档节点。
• 对应回归测试已覆盖；controller.test.ts 定向运行结果为 1 file / 31 tests 通过。

请把你说的具体问题（最好附文件/行号、操作步骤或截图）补充到 PR，我可以继续针对该问题复现核查。

View job run

@fennoai 去翻我在frontend/src/features/workflow-controller/controller.ts472 行的 comment

[fennoai]

检查结论

• 你链接的 controller.ts 第 472 行实际是：approveReview() 将审核节点替换为 status: 'passed'、phase: 'completed' 的状态更新语句，不是代码里的注释。
• 这段逻辑本身成立：前面已限制目标必须是未归档、active 且 reviewing 的 review 节点；保存后调用 unlockReadyNodes()，只会解锁显式依赖已通过节点的其他活动分支，已归档节点会被跳过。
• 我也查询了 PR 的全部 inline review comments：没有找到 huyanxius 在第 472 行留下的独立评论；当前 PR 中相关的 FennoAI 评论位于第 775 行，内容是归档 Action 在上游重做时可能被污染，该问题已在 b239575 修复。
• 验证通过：controller.test.ts 与 api.test.ts 共 44 tests，typecheck 和 oxlint 均通过。

如果你指的是 GitHub 页面上某条未被 API 返回的评论，请直接贴评论文字或 discussion_r... 编号；仅凭第 472 行目前无法确认另一个问题。

View job run

[nighca]

我没问题了，我看你们还在 review，如果你们也没问题了可以合入

[huyanxius]

我没问题了，我看你们还在 review，如果你们也没问题了可以合入

ok，老师，我感觉目前 WorkflowController 没有提供资产入库能力，虽然 Quick Start 已经自行完成了入库，但后续 Workflow Editor 还需要单独写一套，相当于重复造轮子。既然两边都复用 WorkflowRun 和 WorkflowController，这部分是不是放到公共层里会更合适？

[nighca]

我感觉目前 WorkflowController 没有提供资产入库能力

看你们是不是把它视作“workflow”的一部分吧，如果是，那由 WorkflowController 提供是合适的；如果否，那不用仅仅为了复用把它做到 WorkflowController 中，我们可以通过别的方式来复用

你们可以这样来判断它是不是“workflow”的一部分，比如回答这个问题：如果 workflow 支持了复用，然后我们把某个 workflow 在另外一个 character 上重放，重放会包括把重放过程中生成的 action 保存到资产库吗？如果包括，那大概率我们应该把入库视作 workflow 的一部分；反之则不应该视作 workflow 的一部分

[huyanxius]

重放会包括把重放过程中生成的 action 保存到资产库吗？

我的理解是，workflow 重放就是为目标 Character 生成可用的 Action，审核通过后肯定要入库，否则流程并没有完成。所以按这个判断，入库属于 workflow 的最终态。不知道是我理解有偏差吗？

[nighca]

我的理解是，workflow 重放就是为目标 Character 生成可用的 Action，审核通过后肯定要入库，否则流程并没有完成。所以按这个判断，入库属于 workflow 的最终态。不知道是我理解有偏差吗？

可以这么理解的。当然也有另外一个思路：即使是全自动的 workflow 重放，也只会把生成过程一路走完，但是不会自动入库，需要用户自己再去操作保存入库。这俩思路都可能是合理的，你们选你们觉得更符合直觉的就好

[huyanxius]

我的理解是，workflow 重放就是为目标 Character 生成可用的 Action，审核通过后肯定要入库，否则流程并没有完成。所以按这个判断，入库属于 workflow 的最终态。不知道是我理解有偏差吗？

可以这么理解的。当然也有另外一个思路：即使是全自动的 workflow 重放，也只会把生成过程一路走完，但是不会自动入库，需要用户自己再去操作保存入库。这俩思路都可能是合理的，你们选你们觉得更符合直觉的就好

好的，明白了

[huyanxius]

感觉有个问题，这里审核通过了更新的只是 workflow 节点的 pass，但是好像没有看到吧确认的 generation 结果写入 character 资产树，也没有actionId。那这样其实在资产库中根本看不到 character

[huyanxius]

看漏了……发现在#95 的 QuickStartService 确实自行完成了 Character/Action 入库，但 #107 的公共 Controller 只把审核节点标记为 passed。这样 Workflow Editor 如果也要完成发布，只能再复制一套“读取 Generation → 构造 Action → 更新 Character → 返回稳定资产 ID”的逻辑，与两种界面共用底层工作流的目标不一致。是否应该把发布收口为 Controller 或公共用例层的统一命令，供 Quick Start 与 Workflow Editor 共用？

[huyanxius]

@xyh202131