feat: track generation jobs

docs/technical/generation-job-state.md

@@ -4,9 +4,15 @@
 
 ## 当前结论
 
-短期不新增 `generation_jobs` 表，继续把求职版状态落在 `stories` 主记录上。
+已新增轻量 `generation_jobs` 与 `generation_job_events` 表，但不引入复杂工作流引擎。
 
-原因是当前 MVP 的生成方式仍然以同步请求为主：后端在一次请求中完成主内容保存，再补全封面、绘本插图或语音。用户最关心的是“这个故事现在能不能读、哪些资产可补全”，而不是一个独立 job 的生命周期。
+原因是当前 MVP 的生成方式仍然以同步请求为主：后端在一次请求中完成主内容保存，再补全封面、绘本插图或语音。用户最关心的是“这个故事现在能不能读、哪些资产可补全”；系统侧则需要有足够的轨迹说明“这次生成做到了哪一步、哪里失败、哪些资产还能重试”。
+
+因此当前采用轻量落库策略：
+
+- `stories` 继续承载用户可见结果和当前状态。
+- `generation_jobs` 记录一次生成或资产补全尝试。
+- `generation_job_events` 记录关键步骤事件，例如 `request_accepted`、`generation_completed`、`asset_retry_started`、`asset_retry_completed`。
 
 ## 现有状态模型
 
@@ -21,7 +27,7 @@
 
 ## 什么时候需要落库 job
 
-如果后续进入真实生产化，需要重新评估 `generation_jobs`：
+如果后续进入真实生产化，需要扩展当前 job/event 模型：
 
 - 生成流程改成真正异步，前端需要轮询 job 进度。
 - 单个故事会产生多次生成尝试，需要审计每次 provider 调用。
@@ -29,15 +35,14 @@
 - 需要按 provider、成本、延迟和失败原因做运营分析。
 - 需要断点续跑，避免 Worker 重启后丢失中间状态。
 
-## 推荐未来结构
+## 推荐未来扩展
 
-未来可以新增两层记录：
+当前已有两层记录，未来可以继续扩展字段和事件颗粒度：
 
-- `generation_jobs`: 一次用户发起的生成任务，记录输入、状态、耗时、错误和关联 story。
-- `generation_job_events`: 任务事件流，记录每一步开始、成功、失败、provider、耗时和错误摘要。
-
-这会把“用户可见结果”和“系统执行过程”分开，但目前还不是求职版的最高优先级。
+- 在 `generation_job_events` 中补 provider、耗时、成本和错误摘要。
+- 对绘本逐页插图、TTS、后处理任务记录更细事件。
+- 为前端提供 job 查询接口，用于真正异步生成时轮询进度。
 
 ## 面试表达
 
-我现在没有急着加 job 表，是因为 MVP 首要目标是让故事结果稳定可读，并让资产失败可恢复。等生成链路变成真正异步、需要审计和运营指标时，再把执行过程拆到 job/event 表，会比现在提前设计复杂表结构更稳。
+我没有一上来引入复杂工作流引擎，而是先用轻量 job/event 表把关键执行轨迹落下来。这样既能回答“生成过程是否可追踪”，又不会为了求职版 MVP 牺牲主链路稳定性。