以后总结失败了，我仍然应该能读转写。要做到这一点，任务就不能只剩一个“成功”或“失败”。
要解决什么
现在一个任务用 Stage 表示当前阶段，OutputFileID 随流程推进被替换。它能表达转码接转写，却很难同时表达词汇完成、总结重试中。
有哪些方案
我考虑过继续加状态字符串、接入完整工作流引擎，以及先加固定的步骤表。第一种很快会写满分支，第二种需要额外学习和运维。我先选步骤表，只支持目前确定的依赖关系。
我准备怎样实现
下面都是拟新增字段，不是当前接口：
| 对象 | 必要信息 |
|---|---|
| Task | 用户、原始文件、请求的功能、整体状态 |
| Step | step_id、类型、依赖、输入版本、状态、最终产物引用 |
| Attempt | 某次执行的编号、节点、起止时间、错误；第 05 篇补齐租约 |
| Artifact | 文件 ID、用途、生产步骤与版本 |
固定依赖先写清楚：转码成功后开放转写；转写成功后立即可读，并开放用户请求的词汇、总结分支。未选择的功能不创建步骤。翻译先按需发起。
步骤状态先定为 blocked → queued → running → succeeded，另有 retry_wait、failed。重试等待到期再回到 queued。整体状态由步骤推导：有运行中的步骤就是处理中；全部请求的步骤成功才整体成功；转写成功但附加功能终止失败，返回部分完成。转写就绪单独作为可读条件。
每次完成步骤，在一个数据库事务内检查旧状态、登记产物、解锁后续步骤。对同一任务、步骤类型和输入版本加唯一约束，重复完成事件不能生成两份总结任务。
落点从 03_taskService/internal/model/、迁移、meta/ 和 service/ 开始，再调整 proto/task.proto 并重新生成代码。查询接口增加步骤列表，旧字段先保留兼容，不先删除旧表字段。
转写结果增加 schema_version、transcript_revision 和稳定的 segment_id。文字修改生成新 revision；旧词汇和总结仍指向旧 revision，不能悄悄挂到新文本上。前端继续兼容原来的 text/segments。
怎么验收
先迁移一条旧任务，确认原页面仍能读。再用假处理器返回转写成功、词汇成功、总结失败，检查页面还能播放、只有总结允许重试。把同一个完成通知送两次，后续步骤只能出现一次。
先画出状态转移和完成事务，再写接口。字段齐全不等于状态转换正确。