docs(todo): Wave 2 收口 — part2(poll-reviews挪Celery/写action瘦身)按 rule 3 暂缓移交监督
读码判定两项均落在 rule 3「严禁碰 生成/轮询业务逻辑」内,且对已验证功能(管线写契约 /
借火山AK审核子系统)动刀、loop 内无法 e2e 验收 → 按 rule 14 主动暂缓,附落地方案供用户监督执行。
Wave 2 实质收益(复合索引 + 消息中心 N+1)已在 part1 (99a442e) 落地、零回归。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
seaislee1209
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
99a442e883
commit
8e6c6f0881
+10
-5
@@ -29,7 +29,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Wave 2 · 后端查询治理 — ⏳ 进行中
|
||||
## Wave 2 · 后端查询治理 — ✅ 完成(part1 落地 · part2 移交监督)
|
||||
|
||||
### part 1 — ✅ 完成 (2026-06-19)
|
||||
|
||||
@@ -40,10 +40,15 @@
|
||||
|
||||
**part 1 验证:** `python manage.py test apps.ops` → **3/3 OK**;全量 39 测试 6 fail+1 error **全部是预存** image_edit/provider 路由失败(stash 我的改动跑 baseline 42c3c04 复现同样失败)→ **零新增回归**(rule 11 ✅);索引迁移在 sqlite 测试库成功 apply(证迁移有效)。
|
||||
|
||||
### part 2 — ⏳ 待做(下一拍,起 celery + 浏览器 E2E)
|
||||
- **poll-reviews 火山同步 HTTP 挪 Celery**(projects/views.py + assets/review.py;端点只读 DB review_status)——中风险,改审核轮询流,需 celery 起 + e2e。
|
||||
- **写 action 瘦身**(projects 写 action 不回吐全量 ProjectSerializer;前端 `action()` 补 liteRefresh、refreshProjectDetail 仅 pipeline 页)——**最高风险**,贴近 pipeline 数据流(rule 3 敏感),需浏览器走查管线 refresh 不回归,专一拍做。
|
||||
- **charge 通知 bulk_create**:暂缓 —— 仅后台 Celery 跑(非请求阻塞),且 `create_once` 创建+补字段二态耦合,裸批量改风险高 / 收益小,留作已知项。
|
||||
### part 2 — ⏸️ 主动暂缓(撞 rule 3 禁区,移交用户监督执行)
|
||||
|
||||
读码后判定:**两项都落在 rule 3 明令「严禁碰 脚本 agent / 生成 / 轮询的业务逻辑」之内**,且都是对「已验证可用、且我在无人值守 loop 里无法 e2e 验收」的功能动刀 —— 按 rule 14(需用户拍板/需监督验证才停)主动暂缓,给出落地方案供用户监督执行,**不硬改、不敷衍**。Wave 2 的实质收益(索引 + 消息 N+1)已在 part 1 落地。
|
||||
|
||||
- **写 action 瘦身 — 暂缓。** projects 的写 action(`adopt-script`/`generate-base-asset`/`generate-triview`/`update|rerun|add|delete-script-segment`/`generate-storyboard`/`submit-video-segment`/`adopt-video-version`/`save-timeline`…)**本身就是管线脚本 agent / 生成业务逻辑**;它们回吐全量 `ProjectSerializer` 是管线据以同步状态的契约,改返回子对象 + 前端 `action()` 改 `liteRefresh`/`refreshProjectDetail` 仅 pipeline 页 = **改管线数据流**,正是 rule 3 禁区。**落地方案**:与 Wave 4 的 pipeline 巨页拆分(同属高风险、计划本就要求「改前与用户确认」)**配对,作一次有监督的管线重构** —— 拆分后逐 action 把返回收窄为受影响子对象,前端同步改部分刷新,然后逐一回归脚本/故事板/生成/导出/拖拽。
|
||||
- **poll-reviews 挪 Celery — 暂缓。** 这是 `轮询` 端点(rule 3 点名),且改的是**已 e2e 验证拿到真绿盾、用借来的火山 AK/SK(待张业昌换)** 的真人审核子系统。难点:前端 `setReviews(m=>{...m,...map})` 是**合并累加**契约,端点改纯读 DB 必须把「刚翻成 active/failed」的资产也回一次(否则徽章永远停在 processing)—— 需返回「processing + 近 2 分钟刚 resolved」集合,属契约级改动,loop 内无真审核可验。**落地方案**(供监督执行):① 新建 `apps/assets/tasks.py::poll_team_reviews_task(team_id)`(`@app.task`,内部调现成 `poll_team_reviews`,逻辑零改);② 端点 `cache.add` 去重后 `delay` 该任务 + 只读 DB 返回上述集合;③ 起 celery,真生成一张真人基础资产跑通绿盾再合并。
|
||||
- **charge 通知 bulk_create — 暂缓**(同 part1 记录):仅后台 Celery 跑(非请求阻塞),`create_once` 创建+补字段二态耦合,裸批量风险高/收益小。
|
||||
|
||||
**Wave 2 整体 ✅(实质收益 part 1 已落:复合索引 + 消息中心 N+1,零回归;part 2 三项按 rule 3/14 移交用户监督执行,附落地方案)。**
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user