feat: add generation job cancel and retry queue

docs/technical/generation-job-state.md

@@ -6,7 +6,7 @@
 
 已新增轻量 `generation_jobs` 与 `generation_job_events` 表，但不引入复杂工作流引擎。
 
-原因是当前 MVP 的生成方式仍然以同步请求为主：后端在一次请求中完成主内容保存，再补全封面、绘本插图或语音。用户最关心的是“这个故事现在能不能读、哪些资产可补全”；系统侧则需要有足够的轨迹说明“这次生成做到了哪一步、哪里失败、哪些资产还能重试”。
+原因是当前 MVP 已经进入“请求接收与后台执行分离”的阶段：`POST /api/generations` 先接受请求并返回 `generation_job_id`，再由 Celery worker 完成主内容保存和后续资产补全。用户最关心的是“这个故事现在能不能读、任务跑到哪一步、哪些资产可补全”；系统侧则需要有足够的轨迹说明“这次生成做到了哪一步、哪里失败、是否被取消、哪些资产还能重试”。
 
 因此当前采用轻量落库策略：
 
@@ -43,22 +43,24 @@ job 响应会返回 `progress_percent`、`progress_label` 和 `is_terminal`，
 - 音频缓存由 `STORY_AUDIO_CACHE_TTL_DAYS` 控制过期时间，Celery beat 会每日清理。
 - 生成任务由 `GENERATION_JOB_STALE_MINUTES` 控制卡住阈值，Celery beat 会每 30 分钟扫描一次，将超时运行中的任务标记为 `generation_stale_failed`。
 - 当某个故事已经有运行中的 job 时，封面补全、音频生成和统一资产重试会直接拒绝重复请求，避免用户连点造成重复成本。
+- 统一生成请求已由 Celery worker 执行，前端会先拿到 `generation_job_id`，再轮询 job 详情直到主记录落库或任务终止。
+- 当前已支持首版任务控制：队列中的任务可直接取消，运行中的任务可在安全检查点取消，失败或已取消任务可重新排队。
 
-## 什么时候需要落库 job
+## 为什么当前仍然需要扩展 job 模型
 
-如果后续进入真实生产化，需要扩展当前 job/event 模型：
+虽然 worker 化已经完成，但如果继续进入真实生产化，仍然需要扩展当前 job/event 模型：
 
-- 生成流程改成真正异步，前端需要轮询后台 worker 的实时进度。
-- 单个故事会产生多次生成尝试，需要对比每次任务的 provider 表现、重试原因和资产结果。
+- 单个故事会产生多次生成尝试，需要对比每次任务的 provider 表现、取消原因、重试原因和资产结果。
 - 需要展示比当前事件更细颗粒度的步骤，例如 prompt 构建、provider 选择依据、provider failover 原因、每次调用 token/图片/语音成本。
 - 需要按 provider、成本、延迟和失败原因做运营分析。
+- 需要继续扩展取消与重试队列的颗粒度，例如更细的中断点、任务依赖和断点续跑策略。
 - 需要断点续跑，避免 Worker 重启后丢失中间状态。
 
 ## 推荐未来扩展
 
 当前已有两层记录，未来可以继续扩展字段和事件颗粒度：
 
-- 将同步生成请求迁移到真正异步 worker 后，继续复用现有 job 查询和前端轮询进度条。
+- 继续复用现有 job 查询和前端轮询进度条，为取消请求、重新排队和长任务通知提供统一入口。
 - 将当前跨故事 provider 指标扩展为跨用户、跨环境和更细颗粒度的失败原因维度分析。
 
 ## 面试表达