docs: record the UUID validation regression that broke detail replacement

docs/incidents/detail-replacement-durable-batch-2026-09-26.md

@@ -39,3 +39,27 @@
 线上检查：登录页 200、首页 200、未登录访问 `/api/agents/detail-replacement/batches` 返回 401；数据库去重索引已建，`CanvasImageTask` 无遗留批次。分支 `codex/detail-recovery-0924` 已推送 Git。
 
 发布时经确认近 3 小时无任何生成任务、近 1 小时无新消息，重启未打断在途生成。
+
+## 追加：上线后详情替换完全不可用（2026-09-27）
+
+现场：用户点“参考图替换”弹出「任务编号或项目编号无效」，结果区一直是 0/33。nginx 日志显示同一个用户对 `/api/agents/detail-replacement/batches` 的请求全部 400——GET 返回 30 字节（`{"error":"项目编号无效"}`），POST 返回 45 字节（`{"error":"任务编号或项目编号无效"}`），且 GET 请求里的 projectId 是合法 UUID。
+
+根因：新增批次路由自带的 UUID 正则漏写一组 `-{4}`，写成了 8-4-4-12，而标准 UUID 是 8-4-4-4-12。结果是**任何**真实编号都过不了校验，包括浏览器 `generateUUID()` 生成的 requestId，所以查询和提交在参数校验阶段就全部返回 400，页面自然拿不到任务状态。仓库里其他位置用的都是正确的 8-4-4-4-12，只有这个新文件写错。
+
+为什么上一轮没发现：上一轮的端到端验证是直接往 `CanvasImageTask` 插入任务再观察恢复循环，绕过了 HTTP 层，而编号校验只存在于 HTTP 层。这是一次验证覆盖不足，不是环境问题。
+
+修复：
+
+- 校验抽成 `isDetailReplacementUuid` 并修正为规范的 8-4-4-4-12，路由不再自带正则。
+- 回归测试覆盖真实线上项目编号、浏览器生成的请求编号，以及导致故障的 8-4-4-12 形状；另加源码守卫，禁止该路由再次出现自带的错误 UUID 正则。
+- 前端在项目尚未保存时直接提示“请先保存项目后再执行详情替换”，不再把空编号丢给接口。
+
+验证（这次走真实 HTTP，不再是绕过接口的数据库插桩）：用一次性 QA 账号（`activeSessionKey` 与 JWT 会话）和一次性 agent 项目请求线上接口，验证后立即删除，不触碰任何真实账号数据。
+
+- `GET ?projectId=<真实项目 UUID>` → 200 `{"task":null}`（修复前恒为 400，即用户遇到的现场）。
+- `GET ?projectId=not-a-uuid` → 400「项目编号无效」，编号校验仍然生效。
+- `POST` 合法 projectId/requestId → 通过编号校验并进入后续业务校验（返回“详情参考图尚未保存或已发生变化”），说明提交链路已恢复。
+- `POST` 非法 requestId → 400「任务编号或项目编号无效」，非法输入仍被拒绝。
+- QA 账号、项目、临时脚本全部删除，线上无残留。
+
+发布：2026-09-27 19:16 发布至 45.192.99.48 / ai.yydd.ai，提交 `f75d99ba`，构建目录 `.next-detail-batch-f75d99ba-20260927T191533`（BUILD_ID `f1ghXv5zLVb8BQv8a-ifE`）。回滚点为上一构建 `.next-detail-batch-0907aaff-20260926T023939`。