chore: 移除误入库的本地规划文档 docs/plans，加入 gitignore
This commit is contained in:
@@ -110,3 +110,7 @@ OPS_REDIS_MYSQL_OPTIMIZATION_NOTES.md
|
||||
架构.md
|
||||
*ts.%
|
||||
.omc
|
||||
|
||||
# ===== 本地规划文档（不入库）=====
|
||||
docs/plans/
|
||||
docs/*plan*.md
|
||||
|
||||
@@ -1,174 +0,0 @@
|
||||
# crawler-plugin 性能与资源优化 Plan 总览
|
||||
|
||||
> 生成时间：2026-08-29T14:02:50+08:00（Asia/Shanghai）
|
||||
> 适用仓库：`D:/todesk/副业/数富AI/crawler-plugin`
|
||||
> 当前基线：HEAD `3229056`（2026-08-29），本计划来源为代码审计；仓库当前不存在 `docs/specs/`，因此本文件先作为现状优化计划总览。
|
||||
|
||||
## 1. 计划说明
|
||||
|
||||
本计划针对大数据量、多图片、多任务并发场景，覆盖 Java 主后端、Python 插件后端、Vue 前端以及数据库/Redis/RustFS/RocketMQ 资源链路。
|
||||
|
||||
每个任务按约 8-15 分钟设计，开发时必须严格执行以下 TDD 顺序：
|
||||
|
||||
1. 先编写该任务全部测试；
|
||||
2. 运行测试确认 RED；
|
||||
3. 实现功能并运行测试确认 GREEN；
|
||||
4. 执行 lint/format、定向测试和必要的集成验证；
|
||||
5. 任务独立提交 commit 后，才能开始下一个任务。
|
||||
|
||||
涉及 I/O、数据库、HTTP、RustFS、Redis、文件或外部服务的任务，必须包含 mock 单元测试和至少一个真实集成/启动调用验证。每个普通功能任务在对应模块计划中至少列出 8 个语义化测试用例：正常路径 3 个、边界 3 个、异常/错误 2 个。
|
||||
|
||||
## 2. 已验证基线
|
||||
|
||||
- `backend-java`：`mvn -q -DskipTests compile` 通过。
|
||||
- `backend-java`：`mvn -q test`，54 个测试类、344 项测试，0 失败。
|
||||
- `frontend-vue`：`npm run build` 通过；仍有公共 chunk 超过 500KB 的构建警告。
|
||||
- `backend`：`python -m unittest discover -s tests -p "test*.py"`，13 项测试通过。
|
||||
- 当前没有生产压测、JFR、数据库 EXPLAIN 和真实 RustFS/Coze 指标，因此计划中的性能收益必须通过后续基准和压测确认。
|
||||
|
||||
## 3. 模块与任务范围
|
||||
|
||||
| 模块编号 | 模块 | 任务范围 | 任务数 |
|
||||
|---|---|---:|---:|
|
||||
| 01 | Similar ASIN 性能与资源优化 | 1-20 | 20 |
|
||||
| 02 | 店铺数据抓取性能与累计文件优化 | 21-40 | 20 |
|
||||
| 03 | 采集数据批处理与结果文件优化 | 41-60 | 20 |
|
||||
| 04 | 共享任务、对象存储、调度与清理优化 | 61-80 | 20 |
|
||||
| 05 | 前端轮询、缓存、构建与交付验收 | 81-100 | 20 |
|
||||
|
||||
模块计划文件将在本总览确认后按模块单独生成，不合并不同模块；每个模块文件将补充详细功能要求、完整测试清单、TDD RED/GREEN 流程和验证命令。
|
||||
|
||||
## 4. 全部任务清单
|
||||
|
||||
| N | 功能点 | 模块 | 依赖 | 预估耗时 |
|
||||
|---:|---|---|---|---|
|
||||
| 1 | 建立 Similar ASIN 性能基线夹具：1000/5000 行、图片开关、chunk 数与 payload 大小采样 | Similar ASIN 性能与资源优化 | 无 | 8-15 分钟 |
|
||||
| 2 | 将解析载荷改为单一规范行集合，消除 items/groups/allItems 重复数据结构 | Similar ASIN 性能与资源优化 | 1 | 8-15 分钟 |
|
||||
| 3 | 保留旧 payload 读取兼容逻辑，并验证新旧结构均可恢复全量行 | Similar ASIN 性能与资源优化 | 2 | 8-15 分钟 |
|
||||
| 4 | 解析接口改为只返回固定数量预览行，完整行仅保存在后端任务载荷 | Similar ASIN 性能与资源优化 | 3 | 8-15 分钟 |
|
||||
| 5 | 为预览行数量增加配置边界、空文件和超限输入校验 | Similar ASIN 性能与资源优化 | 4 | 8-15 分钟 |
|
||||
| 6 | 将分组数据改为索引/范围引用，避免 groups 嵌套复制完整行对象 | Similar ASIN 性能与资源优化 | 5 | 8-15 分钟 |
|
||||
| 7 | 限制单文件大小、最大行数和最大字段长度，防止解析任务无界增长 | Similar ASIN 性能与资源优化 | 6 | 8-15 分钟 |
|
||||
| 8 | 将 WorkbookFactory 输入解析改为受控读取，并验证超大 Excel 的失败提示 | Similar ASIN 性能与资源优化 | 7 | 8-15 分钟 |
|
||||
| 9 | 将 chunk 查询从单行分页改为批量 keyset 分页，保持低内存读取 | Similar ASIN 性能与资源优化 | 8 | 8-15 分钟 |
|
||||
| 10 | 为 chunk 结果建立按 row key 的批量索引，消除跨 chunk 线性扫描 | Similar ASIN 性能与资源优化 | 9 | 8-15 分钟 |
|
||||
| 11 | 将 Coze 结果合并的重复检测从 O(n²) 改为 HashSet/稳定 row key | Similar ASIN 性能与资源优化 | 10 | 8-15 分钟 |
|
||||
| 12 | 扩展 Coze 结果缓冲覆盖范围，减少频繁读写完整 chunk payload | Similar ASIN 性能与资源优化 | 11 | 8-15 分钟 |
|
||||
| 13 | 为 chunk 合并增加单次最大行数与 payload 字节上限 | Similar ASIN 性能与资源优化 | 12 | 8-15 分钟 |
|
||||
| 14 | 图片 DB cache 改为批量读取缩略图，并只更新实际命中的 last_used_at | Similar ASIN 性能与资源优化 | 13 | 8-15 分钟 |
|
||||
| 15 | 将图片缓存访问时间更新改为异步批量刷新，减少逐图 UPDATE | Similar ASIN 性能与资源优化 | 14 | 8-15 分钟 |
|
||||
| 16 | 图片预取改为短预算 best-effort，超时后直接回退 URL | Similar ASIN 性能与资源优化 | 15 | 8-15 分钟 |
|
||||
| 17 | 优化图片解码采样、像素上限和 JPEG 质量搜索，降低 CPU 与堆峰值 | Similar ASIN 性能与资源优化 | 16 | 8-15 分钟 |
|
||||
| 18 | 统一图片 spool 生命周期，确保超时、取消和异常路径删除临时文件 | Similar ASIN 性能与资源优化 | 17 | 8-15 分钟 |
|
||||
| 19 | 将 Coze 请求/响应及 Python 回传日志改为采样、截断和 DEBUG 级别 | Similar ASIN 性能与资源优化 | 18 | 8-15 分钟 |
|
||||
| 20 | 完成 Similar ASIN 端到端压测、JFR/GC 分析与结果文件兼容回归 | Similar ASIN 性能与资源优化 | 19 | 8-15 分钟 |
|
||||
| 21 | 建立店铺抓取性能基线：单店铺 1k/5k 行、多国家、图片成功/失败场景 | 店铺数据抓取性能与累计文件优化 | 无 | 8-15 分钟 |
|
||||
| 22 | 将店铺 Excel 图片缓存替换为有界字节缓存 | 店铺数据抓取性能与累计文件优化 | 21 | 8-15 分钟 |
|
||||
| 23 | 图片嵌入成功后立即释放外部缩略图字节副本 | 店铺数据抓取性能与累计文件优化 | 22 | 8-15 分钟 |
|
||||
| 24 | 为店铺图片预取增加任务级数量、字节和超时上限 | 店铺数据抓取性能与累计文件优化 | 23 | 8-15 分钟 |
|
||||
| 25 | 评估并实现店铺结果 workbook 的 SXSSF 或 spool 化写入路径 | 店铺数据抓取性能与累计文件优化 | 24 | 8-15 分钟 |
|
||||
| 26 | 为模板 workbook 增加大行数下的样式、图片和工作表兼容测试 | 店铺数据抓取性能与累计文件优化 | 25 | 8-15 分钟 |
|
||||
| 27 | 将 chunk 接收改为原子插入/幂等 upsert，减少先查后插 | 店铺数据抓取性能与累计文件优化 | 26 | 8-15 分钟 |
|
||||
| 28 | 以 scope 计数器替代每个 chunk 的 COUNT(*) 完整统计 | 店铺数据抓取性能与累计文件优化 | 27 | 8-15 分钟 |
|
||||
| 29 | 合并 scope 状态查询与更新，减少单 chunk 数据库往返 | 店铺数据抓取性能与累计文件优化 | 28 | 8-15 分钟 |
|
||||
| 30 | 为国家结果行建立稳定去重键，替换线性重复扫描 | 店铺数据抓取性能与累计文件优化 | 29 | 8-15 分钟 |
|
||||
| 31 | 将任务快照改为轻量进度字段，避免每次写入完整结果 JSON | 店铺数据抓取性能与累计文件优化 | 30 | 8-15 分钟 |
|
||||
| 32 | 将 task entity 本地缓存替换为有容量和过期回收的实现 | 店铺数据抓取性能与累计文件优化 | 31 | 8-15 分钟 |
|
||||
| 33 | 将店铺源文件 key 映射改为确定路径，取消临时目录递归扫描 | 店铺数据抓取性能与累计文件优化 | 32 | 8-15 分钟 |
|
||||
| 34 | 将 ownerInstanceId 从 JSON 查询迁移到显式列并补充索引 | 店铺数据抓取性能与累计文件优化 | 33 | 8-15 分钟 |
|
||||
| 35 | 将每日累计文件改为数据层增量模型，避免每次下载并重写完整 XLSX | 店铺数据抓取性能与累计文件优化 | 34 | 8-15 分钟 |
|
||||
| 36 | 为每日累计文件引入版本号/CAS，缩短店铺级锁的持有时间 | 店铺数据抓取性能与累计文件优化 | 35 | 8-15 分钟 |
|
||||
| 37 | 拆分每日累计文件组装与任务结果接收，增加异步文件作业状态 | 店铺数据抓取性能与累计文件优化 | 36 | 8-15 分钟 |
|
||||
| 38 | 历史列表与进度查询增加分页、字段裁剪和批量任务加载 | 店铺数据抓取性能与累计文件优化 | 37 | 8-15 分钟 |
|
||||
| 39 | 补充删除、超时、重复回传和累计文件失败的资源清理测试 | 店铺数据抓取性能与累计文件优化 | 38 | 8-15 分钟 |
|
||||
| 40 | 完成店铺抓取压测并比较内存、CPU、DB QPS、对象存储流量和锁等待 | 店铺数据抓取性能与累计文件优化 | 39 | 8-15 分钟 |
|
||||
| 41 | 建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线 | 采集数据批处理与结果文件优化 | 无 | 8-15 分钟 |
|
||||
| 42 | 限制采集解析的文件大小、最大行数和单 chunk 行数 | 采集数据批处理与结果文件优化 | 41 | 8-15 分钟 |
|
||||
| 43 | 将采集源文件查找改为确定路径/索引查询 | 采集数据批处理与结果文件优化 | 42 | 8-15 分钟 |
|
||||
| 44 | 保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化 | 采集数据批处理与结果文件优化 | 43 | 8-15 分钟 |
|
||||
| 45 | 将 ASIN 去重查询与无效品牌查询统一为批量集合查询 | 采集数据批处理与结果文件优化 | 44 | 8-15 分钟 |
|
||||
| 46 | 跳过空品牌批次的无效远程品牌检查请求 | 采集数据批处理与结果文件优化 | 45 | 8-15 分钟 |
|
||||
| 47 | 为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用 | 采集数据批处理与结果文件优化 | 46 | 8-15 分钟 |
|
||||
| 48 | 将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert | 采集数据批处理与结果文件优化 | 47 | 8-15 分钟 |
|
||||
| 49 | 将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储 | 采集数据批处理与结果文件优化 | 48 | 8-15 分钟 |
|
||||
| 50 | 为结果明细设计批量 upsert mapper 与幂等唯一键 | 采集数据批处理与结果文件优化 | 49 | 8-15 分钟 |
|
||||
| 51 | 将 accepted 行的序列化和 hash 计算改为批量处理 | 采集数据批处理与结果文件优化 | 50 | 8-15 分钟 |
|
||||
| 52 | 生成结果文件时按 chunk 一次读取，取消逐行对象读取 | 采集数据批处理与结果文件优化 | 51 | 8-15 分钟 |
|
||||
| 53 | 将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留 | 采集数据批处理与结果文件优化 | 52 | 8-15 分钟 |
|
||||
| 54 | 将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数 | 采集数据批处理与结果文件优化 | 53 | 8-15 分钟 |
|
||||
| 55 | 将进度统计更新改为节流/合并写，减少高频 task UPDATE | 采集数据批处理与结果文件优化 | 54 | 8-15 分钟 |
|
||||
| 56 | 为采集结果文件增加流式写入失败后的临时文件清理 | 采集数据批处理与结果文件优化 | 55 | 8-15 分钟 |
|
||||
| 57 | 为采集结果对象增加数据库删除与物理对象删除的一致性处理 | 采集数据批处理与结果文件优化 | 56 | 8-15 分钟 |
|
||||
| 58 | 补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试 | 采集数据批处理与结果文件优化 | 57 | 8-15 分钟 |
|
||||
| 59 | 完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证 | 采集数据批处理与结果文件优化 | 58 | 8-15 分钟 |
|
||||
| 60 | 完成采集模块 10k 行压测并验收结果完整性、内存和吞吐 | 采集数据批处理与结果文件优化 | 59 | 8-15 分钟 |
|
||||
| 61 | 建立共享任务链路资源指标基线：线程、连接、队列、GC、Redis、RustFS 和 DB | 共享任务、对象存储、调度与清理优化 | 无 | 8-15 分钟 |
|
||||
| 62 | 为本地任务实体缓存增加最大条目数、TTL 和定时清理 | 共享任务、对象存储、调度与清理优化 | 61 | 8-15 分钟 |
|
||||
| 63 | 为前端/后端进度快照增加写入去重和最小更新间隔 | 共享任务、对象存储、调度与清理优化 | 62 | 8-15 分钟 |
|
||||
| 64 | 将 transient payload 压缩改为直接 gzip 二进制流上传 | 共享任务、对象存储、调度与清理优化 | 63 | 8-15 分钟 |
|
||||
| 65 | 为 transient payload 读取增加流式解压和解压后字节上限 | 共享任务、对象存储、调度与清理优化 | 64 | 8-15 分钟 |
|
||||
| 66 | 限制 RustFS 并发读写与重试的总资源预算，防止多任务叠加爆发 | 共享任务、对象存储、调度与清理优化 | 65 | 8-15 分钟 |
|
||||
| 67 | 复用 RustFS/MinIO 客户端与 HTTP 连接池，减少每次操作创建客户端 | 共享任务、对象存储、调度与清理优化 | 66 | 8-15 分钟 |
|
||||
| 68 | 将 payload 引用删除改为批量引用检查与异步物理删除 | 共享任务、对象存储、调度与清理优化 | 67 | 8-15 分钟 |
|
||||
| 69 | 为数据库删除任务补充 transient payload 指针收集和清理队列 | 共享任务、对象存储、调度与清理优化 | 68 | 8-15 分钟 |
|
||||
| 70 | 将历史清理改为 keyset 分页、小批量和短事务 | 共享任务、对象存储、调度与清理优化 | 69 | 8-15 分钟 |
|
||||
| 71 | 清理日志改为数量与 sample ID，禁止输出超长任务 ID 列表 | 共享任务、对象存储、调度与清理优化 | 70 | 8-15 分钟 |
|
||||
| 72 | 为文件作业实现数据库原子 claim，避免重复派发同一 job | 共享任务、对象存储、调度与清理优化 | 71 | 8-15 分钟 |
|
||||
| 73 | 为本地文件作业队列增加 in-flight 去重和队列背压 | 共享任务、对象存储、调度与清理优化 | 72 | 8-15 分钟 |
|
||||
| 74 | 隔离调度线程池、文件作业线程池和外部 Coze/图片执行池 | 共享任务、对象存储、调度与清理优化 | 73 | 8-15 分钟 |
|
||||
| 75 | 为虚拟线程任务增加等待队列上限与拒绝/延迟指标 | 共享任务、对象存储、调度与清理优化 | 74 | 8-15 分钟 |
|
||||
| 76 | 将 JSON owner 查询迁移到显式列并补充任务/状态复合索引 | 共享任务、对象存储、调度与清理优化 | 75 | 8-15 分钟 |
|
||||
| 77 | 统一 Coze、品牌检查和紫鸟 HTTP 客户端的连接复用策略 | 共享任务、对象存储、调度与清理优化 | 76 | 8-15 分钟 |
|
||||
| 78 | 为所有外部调用增加耗时、重试、失败率和 payload 字节指标 | 共享任务、对象存储、调度与清理优化 | 77 | 8-15 分钟 |
|
||||
| 79 | 为对象存储、数据库和队列增加故障注入测试 | 共享任务、对象存储、调度与清理优化 | 78 | 8-15 分钟 |
|
||||
| 80 | 补充 JVM 堆、直接内存、临时磁盘和连接池容量配置说明 | 共享任务、对象存储、调度与清理优化 | 79 | 8-15 分钟 |
|
||||
| 81 | 建立前端任务轮询请求量、响应体大小和页面内存基线 | 前端轮询、缓存、构建与交付验收 | 无 | 8-15 分钟 |
|
||||
| 82 | 为进度响应 Map 增加 TTL 清理与最大条目数 | 前端轮询、缓存、构建与交付验收 | 81 | 8-15 分钟 |
|
||||
| 83 | 统一不同页面的轮询去重、in-flight 合并和终态清理 | 前端轮询、缓存、构建与交付验收 | 82 | 8-15 分钟 |
|
||||
| 84 | 优化店铺抓取队列状态合并，消除 historyItems 的线性重复查找 | 前端轮询、缓存、构建与交付验收 | 83 | 8-15 分钟 |
|
||||
| 85 | 优化 Similar ASIN 轮询与文件生成等待，避免重复 force 请求 | 前端轮询、缓存、构建与交付验收 | 84 | 8-15 分钟 |
|
||||
| 86 | 将隐藏页面轮询间隔、前台恢复和退避策略统一配置化 | 前端轮询、缓存、构建与交付验收 | 85 | 8-15 分钟 |
|
||||
| 87 | 限制 localStorage 中任务、快照和队列数据的最大数量/字节数 | 前端轮询、缓存、构建与交付验收 | 86 | 8-15 分钟 |
|
||||
| 88 | 解析结果前端只接收预览数据，避免大 payload 进入响应式对象 | 前端轮询、缓存、构建与交付验收 | 87 | 8-15 分钟 |
|
||||
| 89 | 清理页面卸载时的所有 timer、请求和临时 URL | 前端轮询、缓存、构建与交付验收 | 88 | 8-15 分钟 |
|
||||
| 90 | 为进度接口增加断网、超时、服务恢复和重复响应测试 | 前端轮询、缓存、构建与交付验收 | 89 | 8-15 分钟 |
|
||||
| 91 | 按页面拆分 Element Plus 与公共业务 chunk | 前端轮询、缓存、构建与交付验收 | 90 | 8-15 分钟 |
|
||||
| 92 | 配置 Vite manualChunks 并比较各页面首屏传输大小 | 前端轮询、缓存、构建与交付验收 | 91 | 8-15 分钟 |
|
||||
| 93 | 补充 Similar ASIN、店铺抓取和采集数据页面的 E2E 核心路径 | 前端轮询、缓存、构建与交付验收 | 92 | 8-15 分钟 |
|
||||
| 94 | 补充移动端与桌面端响应式页面验收截图 | 前端轮询、缓存、构建与交付验收 | 93 | 8-15 分钟 |
|
||||
| 95 | 补充深色主题、错误提示、重试和终态刷新验收 | 前端轮询、缓存、构建与交付验收 | 94 | 8-15 分钟 |
|
||||
| 96 | 建立 Java/Python/Vue 三端统一的 API 字段兼容检查 | 前端轮询、缓存、构建与交付验收 | 95 | 8-15 分钟 |
|
||||
| 97 | 执行 Java 全量测试、Python unittest、Vue 类型检查与构建 | 前端轮询、缓存、构建与交付验收 | 96 | 8-15 分钟 |
|
||||
| 98 | 执行真实启动、健康检查、核心请求和外部依赖调用验证 | 前端轮询、缓存、构建与交付验收 | 97 | 8-15 分钟 |
|
||||
| 99 | 执行全链路压测并记录 CPU、内存、GC、DB、Redis、RustFS、网络结果 | 前端轮询、缓存、构建与交付验收 | 98 | 8-15 分钟 |
|
||||
| 100 | 完成发布前回滚演练、git commit 对应关系检查和交付清单 | 前端轮询、缓存、构建与交付验收 | 99 | 8-15 分钟 |
|
||||
|
||||
## 5. 收尾硬性 Gate
|
||||
|
||||
以下验证不是可选项，任一失败都不能视为计划完成：
|
||||
|
||||
1. 使用项目实际启动命令启动 Java 服务，并通过健康检查端点。
|
||||
2. 启动 Python 后端并确认核心管理入口可访问。
|
||||
3. 访问 Similar ASIN、店铺数据抓取和采集数据页面，确认关键元素存在。
|
||||
4. 使用真实最小文件完成一次解析、任务创建、任务执行和结果下载。
|
||||
5. 使用多样化输入验证关键业务逻辑不是固定模板或纯回显。
|
||||
6. 验证数据库、Redis、RustFS、RocketMQ 和外部 HTTP 服务确实发生调用。
|
||||
7. 验证非法输入、依赖不可用、超时、断网和重复回传有明确错误或降级行为。
|
||||
8. 验证任务取消、页面关闭、服务重启和 owner 路由后不会残留锁、线程、timer 或临时文件。
|
||||
9. Java 全量测试全绿。
|
||||
10. Python 测试全绿。
|
||||
11. Vue 类型检查和生产构建通过。
|
||||
12. Java、Python 和前端 lint/format 检查零错误。
|
||||
13. Playwright 完成桌面端页面可访问和关键交互路径验证。
|
||||
14. Playwright 验证断网、恢复、错误提示和重试行为。
|
||||
15. 页面主题切换行为符合预期（如项目页面支持主题）。
|
||||
16. 保存 Desktop 1280x800 与 Mobile 375x812 响应式验收截图。
|
||||
17. 执行 Java、Python、Vue 三端接口字段一致性检查。
|
||||
18. 执行 `git log` 检查 1-100 每个任务均有对应 commit。
|
||||
19. 最后执行 `python check_progress.py`，仅当输出 `all tasks done` 且退出码为 0 时才宣布计划完成。
|
||||
|
||||
## 6. 当前阶段
|
||||
|
||||
当前已生成本 `00-plan-overview.md`、5 个模块详细 plan 文件及根目录 `progress.json`；各任务状态全部为 `pending`。详细 plan 已按模块拆分，完成全部任务后执行收尾 Gate 并进入 Step 3。
|
||||
|
||||
总任务数：100
|
||||
@@ -1,701 +0,0 @@
|
||||
# 01 Similar ASIN 性能与资源优化
|
||||
|
||||
> 对应总览任务：1-20
|
||||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||||
|
||||
## 模块目标
|
||||
|
||||
在保持 Coze 回传、结果文件格式和旧任务兼容性的前提下，降低重复 JSON、chunk 读写、图片下载/解码和结果组装的内存、CPU、数据库及网络成本。
|
||||
|
||||
## 模块级执行规则
|
||||
|
||||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||||
|
||||
## 任务 1：建立 Similar ASIN 性能基线夹具：1000/5000 行、图片开关、chunk 数与 payload 大小采样
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：无
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立 Similar ASIN 性能基线夹具：1000/5000 行、图片开关、chunk 数与 payload 大小采样”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_001_payload_chunk_image_normal_default_path` — 使用正常输入验证“建立 Similar ASIN 性能基线夹具：1000/5000 行、图片开关、chunk 数与 payload 大小采样”的默认成功路径和主输出。
|
||||
2. `test_task_001_payload_chunk_image_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_001_payload_chunk_image_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_001_payload_chunk_image_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_001_payload_chunk_image_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_001_payload_chunk_image_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_001_payload_chunk_image_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_001_payload_chunk_image_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 2：将解析载荷改为单一规范行集合，消除 items/groups/allItems 重复数据结构
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：1
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将解析载荷改为单一规范行集合，消除 items/groups/allItems 重复数据结构”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_002_parsed_payload_normal_default_path` — 使用正常输入验证“将解析载荷改为单一规范行集合，消除 items/groups/allItems 重复数据结构”的默认成功路径和主输出。
|
||||
2. `test_task_002_parsed_payload_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_002_parsed_payload_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_002_parsed_payload_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_002_parsed_payload_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_002_parsed_payload_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_002_parsed_payload_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_002_parsed_payload_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 3：保留旧 payload 读取兼容逻辑，并验证新旧结构均可恢复全量行
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：2
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“保留旧 payload 读取兼容逻辑，并验证新旧结构均可恢复全量行”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_003_payload_normal_default_path` — 使用正常输入验证“保留旧 payload 读取兼容逻辑，并验证新旧结构均可恢复全量行”的默认成功路径和主输出。
|
||||
2. `test_task_003_payload_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_003_payload_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_003_payload_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_003_payload_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_003_payload_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_003_payload_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_003_payload_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 4：解析接口改为只返回固定数量预览行，完整行仅保存在后端任务载荷
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：3
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“解析接口改为只返回固定数量预览行，完整行仅保存在后端任务载荷”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_004_preview_normal_default_path` — 使用正常输入验证“解析接口改为只返回固定数量预览行，完整行仅保存在后端任务载荷”的默认成功路径和主输出。
|
||||
2. `test_task_004_preview_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_004_preview_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_004_preview_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_004_preview_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_004_preview_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_004_preview_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_004_preview_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 5：为预览行数量增加配置边界、空文件和超限输入校验
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：4
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为预览行数量增加配置边界、空文件和超限输入校验”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_005_preview_row_count_normal_default_path` — 使用正常输入验证“为预览行数量增加配置边界、空文件和超限输入校验”的默认成功路径和主输出。
|
||||
2. `test_task_005_preview_row_count_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_005_preview_row_count_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_005_preview_row_count_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_005_preview_row_count_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_005_preview_row_count_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_005_preview_row_count_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_005_preview_row_count_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 6：将分组数据改为索引/范围引用，避免 groups 嵌套复制完整行对象
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：5
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将分组数据改为索引/范围引用，避免 groups 嵌套复制完整行对象”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_006_group_normal_default_path` — 使用正常输入验证“将分组数据改为索引/范围引用，避免 groups 嵌套复制完整行对象”的默认成功路径和主输出。
|
||||
2. `test_task_006_group_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_006_group_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_006_group_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_006_group_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_006_group_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_006_group_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_006_group_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 7：限制单文件大小、最大行数和最大字段长度，防止解析任务无界增长
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：6
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“限制单文件大小、最大行数和最大字段长度，防止解析任务无界增长”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_007_file_size_row_count_normal_default_path` — 使用正常输入验证“限制单文件大小、最大行数和最大字段长度，防止解析任务无界增长”的默认成功路径和主输出。
|
||||
2. `test_task_007_file_size_row_count_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_007_file_size_row_count_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_007_file_size_row_count_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_007_file_size_row_count_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_007_file_size_row_count_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_007_file_size_row_count_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_007_file_size_row_count_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 8：将 WorkbookFactory 输入解析改为受控读取，并验证超大 Excel 的失败提示
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：7
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 WorkbookFactory 输入解析改为受控读取，并验证超大 Excel 的失败提示”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_008_workbook_excel_normal_default_path` — 使用正常输入验证“将 WorkbookFactory 输入解析改为受控读取，并验证超大 Excel 的失败提示”的默认成功路径和主输出。
|
||||
2. `test_task_008_workbook_excel_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_008_workbook_excel_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_008_workbook_excel_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_008_workbook_excel_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_008_workbook_excel_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_008_workbook_excel_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_008_workbook_excel_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 9：将 chunk 查询从单行分页改为批量 keyset 分页，保持低内存读取
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：8
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 chunk 查询从单行分页改为批量 keyset 分页，保持低内存读取”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_009_chunk_normal_default_path` — 使用正常输入验证“将 chunk 查询从单行分页改为批量 keyset 分页，保持低内存读取”的默认成功路径和主输出。
|
||||
2. `test_task_009_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_009_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_009_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_009_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_009_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_009_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_009_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 10：为 chunk 结果建立按 row key 的批量索引，消除跨 chunk 线性扫描
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：9
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为 chunk 结果建立按 row key 的批量索引，消除跨 chunk 线性扫描”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_010_chunk_row_key_normal_default_path` — 使用正常输入验证“为 chunk 结果建立按 row key 的批量索引，消除跨 chunk 线性扫描”的默认成功路径和主输出。
|
||||
2. `test_task_010_chunk_row_key_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_010_chunk_row_key_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_010_chunk_row_key_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_010_chunk_row_key_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_010_chunk_row_key_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_010_chunk_row_key_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_010_chunk_row_key_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 11：将 Coze 结果合并的重复检测从 O(n²) 改为 HashSet/稳定 row key
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：10
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 Coze 结果合并的重复检测从 O(n²) 改为 HashSet/稳定 row key”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_011_merge_row_key_normal_default_path` — 使用正常输入验证“将 Coze 结果合并的重复检测从 O(n²) 改为 HashSet/稳定 row key”的默认成功路径和主输出。
|
||||
2. `test_task_011_merge_row_key_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_011_merge_row_key_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_011_merge_row_key_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_011_merge_row_key_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_011_merge_row_key_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_011_merge_row_key_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_011_merge_row_key_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 12：扩展 Coze 结果缓冲覆盖范围，减少频繁读写完整 chunk payload
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：11
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“扩展 Coze 结果缓冲覆盖范围，减少频繁读写完整 chunk payload”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_012_payload_chunk_normal_default_path` — 使用正常输入验证“扩展 Coze 结果缓冲覆盖范围，减少频繁读写完整 chunk payload”的默认成功路径和主输出。
|
||||
2. `test_task_012_payload_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_012_payload_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_012_payload_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_012_payload_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_012_payload_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_012_payload_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_012_payload_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 13：为 chunk 合并增加单次最大行数与 payload 字节上限
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：12
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为 chunk 合并增加单次最大行数与 payload 字节上限”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_013_payload_row_count_chunk_normal_default_path` — 使用正常输入验证“为 chunk 合并增加单次最大行数与 payload 字节上限”的默认成功路径和主输出。
|
||||
2. `test_task_013_payload_row_count_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_013_payload_row_count_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_013_payload_row_count_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_013_payload_row_count_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_013_payload_row_count_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_013_payload_row_count_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_013_payload_row_count_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 14：图片 DB cache 改为批量读取缩略图，并只更新实际命中的 last_used_at
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：13
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“图片 DB cache 改为批量读取缩略图，并只更新实际命中的 last_used_at”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_014_image_normal_default_path` — 使用正常输入验证“图片 DB cache 改为批量读取缩略图，并只更新实际命中的 last_used_at”的默认成功路径和主输出。
|
||||
2. `test_task_014_image_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_014_image_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_014_image_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_014_image_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_014_image_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_014_image_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_014_image_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 15：将图片缓存访问时间更新改为异步批量刷新，减少逐图 UPDATE
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：14
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将图片缓存访问时间更新改为异步批量刷新，减少逐图 UPDATE”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_015_image_cache_normal_default_path` — 使用正常输入验证“将图片缓存访问时间更新改为异步批量刷新，减少逐图 UPDATE”的默认成功路径和主输出。
|
||||
2. `test_task_015_image_cache_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_015_image_cache_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_015_image_cache_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_015_image_cache_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_015_image_cache_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_015_image_cache_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_015_image_cache_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 16：图片预取改为短预算 best-effort，超时后直接回退 URL
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：15
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“图片预取改为短预算 best-effort，超时后直接回退 URL”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_016_image_prefetch_normal_default_path` — 使用正常输入验证“图片预取改为短预算 best-effort，超时后直接回退 URL”的默认成功路径和主输出。
|
||||
2. `test_task_016_image_prefetch_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_016_image_prefetch_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_016_image_prefetch_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_016_image_prefetch_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_016_image_prefetch_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_016_image_prefetch_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_016_image_prefetch_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 17：优化图片解码采样、像素上限和 JPEG 质量搜索，降低 CPU 与堆峰值
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：16
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“优化图片解码采样、像素上限和 JPEG 质量搜索，降低 CPU 与堆峰值”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_017_image_decode_quality_normal_default_path` — 使用正常输入验证“优化图片解码采样、像素上限和 JPEG 质量搜索，降低 CPU 与堆峰值”的默认成功路径和主输出。
|
||||
2. `test_task_017_image_decode_quality_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_017_image_decode_quality_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_017_image_decode_quality_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_017_image_decode_quality_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_017_image_decode_quality_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_017_image_decode_quality_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_017_image_decode_quality_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 18：统一图片 spool 生命周期，确保超时、取消和异常路径删除临时文件
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：17
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“统一图片 spool 生命周期，确保超时、取消和异常路径删除临时文件”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_018_image_normal_default_path` — 使用正常输入验证“统一图片 spool 生命周期，确保超时、取消和异常路径删除临时文件”的默认成功路径和主输出。
|
||||
2. `test_task_018_image_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_018_image_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_018_image_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_018_image_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_018_image_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_018_image_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_018_image_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 19：将 Coze 请求/响应及 Python 回传日志改为采样、截断和 DEBUG 级别
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：18
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 Coze 请求/响应及 Python 回传日志改为采样、截断和 DEBUG 级别”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_019_logging_normal_default_path` — 使用正常输入验证“将 Coze 请求/响应及 Python 回传日志改为采样、截断和 DEBUG 级别”的默认成功路径和主输出。
|
||||
2. `test_task_019_logging_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_019_logging_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_019_logging_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_019_logging_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_019_logging_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_019_logging_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_019_logging_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 20：完成 Similar ASIN 端到端压测、JFR/GC 分析与结果文件兼容回归
|
||||
|
||||
**所属模块**：Similar ASIN 性能与资源优化
|
||||
**依赖**：19
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“完成 Similar ASIN 端到端压测、JFR/GC 分析与结果文件兼容回归”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_020_asin_normal_default_path` — 使用正常输入验证“完成 Similar ASIN 端到端压测、JFR/GC 分析与结果文件兼容回归”的默认成功路径和主输出。
|
||||
2. `test_task_020_asin_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_020_asin_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_020_asin_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_020_asin_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_020_asin_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_020_asin_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_020_asin_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 similarasin 服务、Coze 客户端、图片嵌入器、结果 workbook 组装链路。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 模块完成 Gate
|
||||
|
||||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|
||||
@@ -1,701 +0,0 @@
|
||||
# 02 店铺数据抓取性能与累计文件优化
|
||||
|
||||
> 对应总览任务：21-40
|
||||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||||
|
||||
## 模块目标
|
||||
|
||||
降低店铺抓取 chunk 回传、图片嵌入和每日累计文件更新的峰值内存、锁等待、全量重写和对象存储流量，同时保持现有店铺/国家结果语义。
|
||||
|
||||
## 模块级执行规则
|
||||
|
||||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||||
|
||||
## 任务 21：建立店铺抓取性能基线：单店铺 1k/5k 行、多国家、图片成功/失败场景
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：无
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立店铺抓取性能基线：单店铺 1k/5k 行、多国家、图片成功/失败场景”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_021_image_normal_default_path` — 使用正常输入验证“建立店铺抓取性能基线：单店铺 1k/5k 行、多国家、图片成功/失败场景”的默认成功路径和主输出。
|
||||
2. `test_task_021_image_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_021_image_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_021_image_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_021_image_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_021_image_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_021_image_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_021_image_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 22：将店铺 Excel 图片缓存替换为有界字节缓存
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：21
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将店铺 Excel 图片缓存替换为有界字节缓存”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_022_image_cache_excel_normal_default_path` — 使用正常输入验证“将店铺 Excel 图片缓存替换为有界字节缓存”的默认成功路径和主输出。
|
||||
2. `test_task_022_image_cache_excel_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_022_image_cache_excel_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_022_image_cache_excel_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_022_image_cache_excel_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_022_image_cache_excel_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_022_image_cache_excel_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_022_image_cache_excel_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 23：图片嵌入成功后立即释放外部缩略图字节副本
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：22
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“图片嵌入成功后立即释放外部缩略图字节副本”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_023_image_normal_default_path` — 使用正常输入验证“图片嵌入成功后立即释放外部缩略图字节副本”的默认成功路径和主输出。
|
||||
2. `test_task_023_image_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_023_image_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_023_image_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_023_image_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_023_image_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_023_image_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_023_image_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 24：为店铺图片预取增加任务级数量、字节和超时上限
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：23
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为店铺图片预取增加任务级数量、字节和超时上限”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_024_image_prefetch_normal_default_path` — 使用正常输入验证“为店铺图片预取增加任务级数量、字节和超时上限”的默认成功路径和主输出。
|
||||
2. `test_task_024_image_prefetch_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_024_image_prefetch_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_024_image_prefetch_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_024_image_prefetch_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_024_image_prefetch_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_024_image_prefetch_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_024_image_prefetch_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 25：评估并实现店铺结果 workbook 的 SXSSF 或 spool 化写入路径
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：24
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“评估并实现店铺结果 workbook 的 SXSSF 或 spool 化写入路径”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_025_workbook_normal_default_path` — 使用正常输入验证“评估并实现店铺结果 workbook 的 SXSSF 或 spool 化写入路径”的默认成功路径和主输出。
|
||||
2. `test_task_025_workbook_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_025_workbook_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_025_workbook_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_025_workbook_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_025_workbook_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_025_workbook_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_025_workbook_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 26：为模板 workbook 增加大行数下的样式、图片和工作表兼容测试
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：25
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为模板 workbook 增加大行数下的样式、图片和工作表兼容测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_026_row_count_image_workbook_normal_default_path` — 使用正常输入验证“为模板 workbook 增加大行数下的样式、图片和工作表兼容测试”的默认成功路径和主输出。
|
||||
2. `test_task_026_row_count_image_workbook_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_026_row_count_image_workbook_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_026_row_count_image_workbook_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_026_row_count_image_workbook_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_026_row_count_image_workbook_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_026_row_count_image_workbook_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_026_row_count_image_workbook_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 27：将 chunk 接收改为原子插入/幂等 upsert，减少先查后插
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：26
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 chunk 接收改为原子插入/幂等 upsert，减少先查后插”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_027_chunk_normal_default_path` — 使用正常输入验证“将 chunk 接收改为原子插入/幂等 upsert，减少先查后插”的默认成功路径和主输出。
|
||||
2. `test_task_027_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_027_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_027_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_027_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_027_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_027_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_027_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 28：以 scope 计数器替代每个 chunk 的 COUNT(*) 完整统计
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：27
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“以 scope 计数器替代每个 chunk 的 COUNT(*) 完整统计”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_028_chunk_normal_default_path` — 使用正常输入验证“以 scope 计数器替代每个 chunk 的 COUNT(*) 完整统计”的默认成功路径和主输出。
|
||||
2. `test_task_028_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_028_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_028_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_028_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_028_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_028_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_028_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 29：合并 scope 状态查询与更新，减少单 chunk 数据库往返
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：28
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“合并 scope 状态查询与更新，减少单 chunk 数据库往返”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_029_chunk_merge_normal_default_path` — 使用正常输入验证“合并 scope 状态查询与更新，减少单 chunk 数据库往返”的默认成功路径和主输出。
|
||||
2. `test_task_029_chunk_merge_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_029_chunk_merge_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_029_chunk_merge_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_029_chunk_merge_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_029_chunk_merge_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_029_chunk_merge_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_029_chunk_merge_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 30：为国家结果行建立稳定去重键，替换线性重复扫描
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：29
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为国家结果行建立稳定去重键，替换线性重复扫描”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_030_task_normal_default_path` — 使用正常输入验证“为国家结果行建立稳定去重键，替换线性重复扫描”的默认成功路径和主输出。
|
||||
2. `test_task_030_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_030_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_030_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_030_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_030_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_030_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_030_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 31：将任务快照改为轻量进度字段，避免每次写入完整结果 JSON
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：30
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将任务快照改为轻量进度字段，避免每次写入完整结果 JSON”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_031_snapshot_progress_normal_default_path` — 使用正常输入验证“将任务快照改为轻量进度字段，避免每次写入完整结果 JSON”的默认成功路径和主输出。
|
||||
2. `test_task_031_snapshot_progress_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_031_snapshot_progress_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_031_snapshot_progress_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_031_snapshot_progress_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_031_snapshot_progress_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_031_snapshot_progress_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_031_snapshot_progress_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 32：将 task entity 本地缓存替换为有容量和过期回收的实现
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：31
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 task entity 本地缓存替换为有容量和过期回收的实现”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_032_cache_normal_default_path` — 使用正常输入验证“将 task entity 本地缓存替换为有容量和过期回收的实现”的默认成功路径和主输出。
|
||||
2. `test_task_032_cache_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_032_cache_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_032_cache_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_032_cache_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_032_cache_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_032_cache_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_032_cache_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 33：将店铺源文件 key 映射改为确定路径，取消临时目录递归扫描
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：32
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将店铺源文件 key 映射改为确定路径，取消临时目录递归扫描”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_033_task_normal_default_path` — 使用正常输入验证“将店铺源文件 key 映射改为确定路径，取消临时目录递归扫描”的默认成功路径和主输出。
|
||||
2. `test_task_033_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_033_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_033_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_033_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_033_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_033_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_033_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 34：将 ownerInstanceId 从 JSON 查询迁移到显式列并补充索引
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：33
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 ownerInstanceId 从 JSON 查询迁移到显式列并补充索引”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_034_owner_normal_default_path` — 使用正常输入验证“将 ownerInstanceId 从 JSON 查询迁移到显式列并补充索引”的默认成功路径和主输出。
|
||||
2. `test_task_034_owner_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_034_owner_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_034_owner_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_034_owner_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_034_owner_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_034_owner_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_034_owner_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 35：将每日累计文件改为数据层增量模型，避免每次下载并重写完整 XLSX
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：34
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将每日累计文件改为数据层增量模型，避免每次下载并重写完整 XLSX”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_035_daily_file_normal_default_path` — 使用正常输入验证“将每日累计文件改为数据层增量模型，避免每次下载并重写完整 XLSX”的默认成功路径和主输出。
|
||||
2. `test_task_035_daily_file_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_035_daily_file_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_035_daily_file_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_035_daily_file_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_035_daily_file_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_035_daily_file_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_035_daily_file_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 36：为每日累计文件引入版本号/CAS，缩短店铺级锁的持有时间
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：35
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为每日累计文件引入版本号/CAS，缩短店铺级锁的持有时间”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_036_daily_file_lock_normal_default_path` — 使用正常输入验证“为每日累计文件引入版本号/CAS，缩短店铺级锁的持有时间”的默认成功路径和主输出。
|
||||
2. `test_task_036_daily_file_lock_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_036_daily_file_lock_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_036_daily_file_lock_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_036_daily_file_lock_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_036_daily_file_lock_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_036_daily_file_lock_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_036_daily_file_lock_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 37：拆分每日累计文件组装与任务结果接收，增加异步文件作业状态
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：36
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“拆分每日累计文件组装与任务结果接收，增加异步文件作业状态”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_037_daily_file_job_normal_default_path` — 使用正常输入验证“拆分每日累计文件组装与任务结果接收，增加异步文件作业状态”的默认成功路径和主输出。
|
||||
2. `test_task_037_daily_file_job_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_037_daily_file_job_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_037_daily_file_job_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_037_daily_file_job_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_037_daily_file_job_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_037_daily_file_job_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_037_daily_file_job_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 38：历史列表与进度查询增加分页、字段裁剪和批量任务加载
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：37
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“历史列表与进度查询增加分页、字段裁剪和批量任务加载”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_038_progress_normal_default_path` — 使用正常输入验证“历史列表与进度查询增加分页、字段裁剪和批量任务加载”的默认成功路径和主输出。
|
||||
2. `test_task_038_progress_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_038_progress_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_038_progress_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_038_progress_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_038_progress_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_038_progress_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_038_progress_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 39：补充删除、超时、重复回传和累计文件失败的资源清理测试
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：38
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充删除、超时、重复回传和累计文件失败的资源清理测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_039_daily_file_cleanup_normal_default_path` — 使用正常输入验证“补充删除、超时、重复回传和累计文件失败的资源清理测试”的默认成功路径和主输出。
|
||||
2. `test_task_039_daily_file_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_039_daily_file_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_039_daily_file_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_039_daily_file_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_039_daily_file_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_039_daily_file_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_039_daily_file_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 40：完成店铺抓取压测并比较内存、CPU、DB QPS、对象存储流量和锁等待
|
||||
|
||||
**所属模块**：店铺数据抓取性能与累计文件优化
|
||||
**依赖**：39
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“完成店铺抓取压测并比较内存、CPU、DB QPS、对象存储流量和锁等待”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_040_lock_object_storage_normal_default_path` — 使用正常输入验证“完成店铺抓取压测并比较内存、CPU、DB QPS、对象存储流量和锁等待”的默认成功路径和主输出。
|
||||
2. `test_task_040_lock_object_storage_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_040_lock_object_storage_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_040_lock_object_storage_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_040_lock_object_storage_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_040_lock_object_storage_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_040_lock_object_storage_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_040_lock_object_storage_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 shopdatacrawl 服务、每日累计文件、店铺图片嵌入、任务快照和 owner 路由。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 模块完成 Gate
|
||||
|
||||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|
||||
@@ -1,701 +0,0 @@
|
||||
# 03 采集数据批处理与结果文件优化
|
||||
|
||||
> 对应总览任务：41-60
|
||||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||||
|
||||
## 模块目标
|
||||
|
||||
将采集结果从逐行对象存储/逐行 upsert 改为可控批处理，降低数据库往返、RustFS 小对象数量、序列化次数和结果文件生成内存。
|
||||
|
||||
## 模块级执行规则
|
||||
|
||||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||||
|
||||
## 任务 41：建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：无
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_041_chunk_brand_normal_default_path` — 使用正常输入验证“建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线”的默认成功路径和主输出。
|
||||
2. `test_task_041_chunk_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_041_chunk_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_041_chunk_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_041_chunk_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_041_chunk_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_041_chunk_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_041_chunk_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 42：限制采集解析的文件大小、最大行数和单 chunk 行数
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：41
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“限制采集解析的文件大小、最大行数和单 chunk 行数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_042_file_size_row_count_chunk_normal_default_path` — 使用正常输入验证“限制采集解析的文件大小、最大行数和单 chunk 行数”的默认成功路径和主输出。
|
||||
2. `test_task_042_file_size_row_count_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_042_file_size_row_count_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_042_file_size_row_count_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_042_file_size_row_count_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_042_file_size_row_count_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_042_file_size_row_count_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_042_file_size_row_count_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 43：将采集源文件查找改为确定路径/索引查询
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：42
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将采集源文件查找改为确定路径/索引查询”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_043_collect_normal_default_path` — 使用正常输入验证“将采集源文件查找改为确定路径/索引查询”的默认成功路径和主输出。
|
||||
2. `test_task_043_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_043_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_043_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_043_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_043_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_043_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_043_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 44：保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：43
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_044_payload_chunk_normal_default_path` — 使用正常输入验证“保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化”的默认成功路径和主输出。
|
||||
2. `test_task_044_payload_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_044_payload_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_044_payload_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_044_payload_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_044_payload_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_044_payload_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_044_payload_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 45：将 ASIN 去重查询与无效品牌查询统一为批量集合查询
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：44
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 ASIN 去重查询与无效品牌查询统一为批量集合查询”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_045_asin_brand_normal_default_path` — 使用正常输入验证“将 ASIN 去重查询与无效品牌查询统一为批量集合查询”的默认成功路径和主输出。
|
||||
2. `test_task_045_asin_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_045_asin_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_045_asin_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_045_asin_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_045_asin_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_045_asin_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_045_asin_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 46：跳过空品牌批次的无效远程品牌检查请求
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：45
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“跳过空品牌批次的无效远程品牌检查请求”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_046_brand_normal_default_path` — 使用正常输入验证“跳过空品牌批次的无效远程品牌检查请求”的默认成功路径和主输出。
|
||||
2. `test_task_046_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_046_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_046_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_046_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_046_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_046_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_046_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 47：为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：46
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_047_cache_brand_normal_default_path` — 使用正常输入验证“为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用”的默认成功路径和主输出。
|
||||
2. `test_task_047_cache_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_047_cache_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_047_cache_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_047_cache_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_047_cache_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_047_cache_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_047_cache_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 48：将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：47
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_048_asin_normal_default_path` — 使用正常输入验证“将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert”的默认成功路径和主输出。
|
||||
2. `test_task_048_asin_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_048_asin_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_048_asin_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_048_asin_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_048_asin_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_048_asin_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_048_asin_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 49：将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：48
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_049_payload_chunk_rustfs_normal_default_path` — 使用正常输入验证“将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储”的默认成功路径和主输出。
|
||||
2. `test_task_049_payload_chunk_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_049_payload_chunk_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_049_payload_chunk_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_049_payload_chunk_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_049_payload_chunk_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_049_payload_chunk_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_049_payload_chunk_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 50：为结果明细设计批量 upsert mapper 与幂等唯一键
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：49
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为结果明细设计批量 upsert mapper 与幂等唯一键”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_050_task_normal_default_path` — 使用正常输入验证“为结果明细设计批量 upsert mapper 与幂等唯一键”的默认成功路径和主输出。
|
||||
2. `test_task_050_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_050_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_050_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_050_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_050_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_050_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_050_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 51：将 accepted 行的序列化和 hash 计算改为批量处理
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：50
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 accepted 行的序列化和 hash 计算改为批量处理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_051_task_normal_default_path` — 使用正常输入验证“将 accepted 行的序列化和 hash 计算改为批量处理”的默认成功路径和主输出。
|
||||
2. `test_task_051_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_051_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_051_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_051_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_051_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_051_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_051_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 52：生成结果文件时按 chunk 一次读取，取消逐行对象读取
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：51
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“生成结果文件时按 chunk 一次读取，取消逐行对象读取”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_052_chunk_normal_default_path` — 使用正常输入验证“生成结果文件时按 chunk 一次读取，取消逐行对象读取”的默认成功路径和主输出。
|
||||
2. `test_task_052_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_052_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_052_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_052_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_052_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_052_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_052_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 53：将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：52
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_053_task_normal_default_path` — 使用正常输入验证“将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留”的默认成功路径和主输出。
|
||||
2. `test_task_053_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_053_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_053_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_053_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_053_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_053_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_053_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 54：将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：53
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_054_chunk_normal_default_path` — 使用正常输入验证“将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数”的默认成功路径和主输出。
|
||||
2. `test_task_054_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_054_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_054_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_054_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_054_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_054_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_054_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 55：将进度统计更新改为节流/合并写，减少高频 task UPDATE
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：54
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将进度统计更新改为节流/合并写，减少高频 task UPDATE”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_055_merge_progress_normal_default_path` — 使用正常输入验证“将进度统计更新改为节流/合并写，减少高频 task UPDATE”的默认成功路径和主输出。
|
||||
2. `test_task_055_merge_progress_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_055_merge_progress_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_055_merge_progress_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_055_merge_progress_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_055_merge_progress_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_055_merge_progress_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_055_merge_progress_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 56：为采集结果文件增加流式写入失败后的临时文件清理
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：55
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为采集结果文件增加流式写入失败后的临时文件清理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_056_collect_cleanup_normal_default_path` — 使用正常输入验证“为采集结果文件增加流式写入失败后的临时文件清理”的默认成功路径和主输出。
|
||||
2. `test_task_056_collect_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_056_collect_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_056_collect_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_056_collect_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_056_collect_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_056_collect_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_056_collect_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 57：为采集结果对象增加数据库删除与物理对象删除的一致性处理
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：56
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为采集结果对象增加数据库删除与物理对象删除的一致性处理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_057_collect_normal_default_path` — 使用正常输入验证“为采集结果对象增加数据库删除与物理对象删除的一致性处理”的默认成功路径和主输出。
|
||||
2. `test_task_057_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_057_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_057_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_057_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_057_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_057_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_057_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 58：补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：57
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_058_chunk_brand_rustfs_normal_default_path` — 使用正常输入验证“补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试”的默认成功路径和主输出。
|
||||
2. `test_task_058_chunk_brand_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_058_chunk_brand_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_058_chunk_brand_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_058_chunk_brand_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_058_chunk_brand_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_058_chunk_brand_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_058_chunk_brand_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 59：完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：58
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_059_collect_object_storage_normal_default_path` — 使用正常输入验证“完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证”的默认成功路径和主输出。
|
||||
2. `test_task_059_collect_object_storage_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_059_collect_object_storage_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_059_collect_object_storage_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_059_collect_object_storage_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_059_collect_object_storage_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_059_collect_object_storage_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_059_collect_object_storage_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 60：完成采集模块 10k 行压测并验收结果完整性、内存和吞吐
|
||||
|
||||
**所属模块**：采集数据批处理与结果文件优化
|
||||
**依赖**：59
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“完成采集模块 10k 行压测并验收结果完整性、内存和吞吐”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_060_collect_normal_default_path` — 使用正常输入验证“完成采集模块 10k 行压测并验收结果完整性、内存和吞吐”的默认成功路径和主输出。
|
||||
2. `test_task_060_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_060_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_060_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_060_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_060_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_060_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_060_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 模块完成 Gate
|
||||
|
||||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|
||||
@@ -1,701 +0,0 @@
|
||||
# 04 共享任务、对象存储、调度与清理优化
|
||||
|
||||
> 对应总览任务：61-80
|
||||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||||
|
||||
## 模块目标
|
||||
|
||||
建立跨模块资源预算和可观测性，消除无界缓存、重复派发、长事务、物理对象泄漏和大 payload 读写放大。
|
||||
|
||||
## 模块级执行规则
|
||||
|
||||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||||
|
||||
## 任务 61：建立共享任务链路资源指标基线：线程、连接、队列、GC、Redis、RustFS 和 DB
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：无
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立共享任务链路资源指标基线：线程、连接、队列、GC、Redis、RustFS 和 DB”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_061_rustfs_metrics_normal_default_path` — 使用正常输入验证“建立共享任务链路资源指标基线：线程、连接、队列、GC、Redis、RustFS 和 DB”的默认成功路径和主输出。
|
||||
2. `test_task_061_rustfs_metrics_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_061_rustfs_metrics_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_061_rustfs_metrics_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_061_rustfs_metrics_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_061_rustfs_metrics_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_061_rustfs_metrics_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_061_rustfs_metrics_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 62：为本地任务实体缓存增加最大条目数、TTL 和定时清理
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：61
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为本地任务实体缓存增加最大条目数、TTL 和定时清理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_062_cache_cleanup_normal_default_path` — 使用正常输入验证“为本地任务实体缓存增加最大条目数、TTL 和定时清理”的默认成功路径和主输出。
|
||||
2. `test_task_062_cache_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_062_cache_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_062_cache_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_062_cache_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_062_cache_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_062_cache_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_062_cache_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 63：为前端/后端进度快照增加写入去重和最小更新间隔
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：62
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为前端/后端进度快照增加写入去重和最小更新间隔”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_063_progress_frontend_normal_default_path` — 使用正常输入验证“为前端/后端进度快照增加写入去重和最小更新间隔”的默认成功路径和主输出。
|
||||
2. `test_task_063_progress_frontend_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_063_progress_frontend_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_063_progress_frontend_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_063_progress_frontend_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_063_progress_frontend_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_063_progress_frontend_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_063_progress_frontend_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 64：将 transient payload 压缩改为直接 gzip 二进制流上传
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：63
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 transient payload 压缩改为直接 gzip 二进制流上传”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_064_payload_compression_normal_default_path` — 使用正常输入验证“将 transient payload 压缩改为直接 gzip 二进制流上传”的默认成功路径和主输出。
|
||||
2. `test_task_064_payload_compression_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_064_payload_compression_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_064_payload_compression_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_064_payload_compression_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_064_payload_compression_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_064_payload_compression_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_064_payload_compression_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 65：为 transient payload 读取增加流式解压和解压后字节上限
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：64
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为 transient payload 读取增加流式解压和解压后字节上限”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_065_payload_normal_default_path` — 使用正常输入验证“为 transient payload 读取增加流式解压和解压后字节上限”的默认成功路径和主输出。
|
||||
2. `test_task_065_payload_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_065_payload_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_065_payload_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_065_payload_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_065_payload_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_065_payload_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_065_payload_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 66：限制 RustFS 并发读写与重试的总资源预算，防止多任务叠加爆发
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：65
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“限制 RustFS 并发读写与重试的总资源预算，防止多任务叠加爆发”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_066_rustfs_normal_default_path` — 使用正常输入验证“限制 RustFS 并发读写与重试的总资源预算，防止多任务叠加爆发”的默认成功路径和主输出。
|
||||
2. `test_task_066_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_066_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_066_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_066_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_066_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_066_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_066_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 67：复用 RustFS/MinIO 客户端与 HTTP 连接池，减少每次操作创建客户端
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：66
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“复用 RustFS/MinIO 客户端与 HTTP 连接池，减少每次操作创建客户端”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_067_rustfs_normal_default_path` — 使用正常输入验证“复用 RustFS/MinIO 客户端与 HTTP 连接池，减少每次操作创建客户端”的默认成功路径和主输出。
|
||||
2. `test_task_067_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_067_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_067_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_067_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_067_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_067_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_067_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 68：将 payload 引用删除改为批量引用检查与异步物理删除
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：67
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 payload 引用删除改为批量引用检查与异步物理删除”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_068_payload_normal_default_path` — 使用正常输入验证“将 payload 引用删除改为批量引用检查与异步物理删除”的默认成功路径和主输出。
|
||||
2. `test_task_068_payload_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_068_payload_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_068_payload_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_068_payload_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_068_payload_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_068_payload_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_068_payload_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 69：为数据库删除任务补充 transient payload 指针收集和清理队列
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：68
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为数据库删除任务补充 transient payload 指针收集和清理队列”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_069_payload_cleanup_normal_default_path` — 使用正常输入验证“为数据库删除任务补充 transient payload 指针收集和清理队列”的默认成功路径和主输出。
|
||||
2. `test_task_069_payload_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_069_payload_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_069_payload_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_069_payload_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_069_payload_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_069_payload_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_069_payload_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 70：将历史清理改为 keyset 分页、小批量和短事务
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：69
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将历史清理改为 keyset 分页、小批量和短事务”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_070_cleanup_normal_default_path` — 使用正常输入验证“将历史清理改为 keyset 分页、小批量和短事务”的默认成功路径和主输出。
|
||||
2. `test_task_070_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_070_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_070_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_070_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_070_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_070_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_070_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 71：清理日志改为数量与 sample ID，禁止输出超长任务 ID 列表
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：70
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“清理日志改为数量与 sample ID，禁止输出超长任务 ID 列表”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_071_cleanup_logging_normal_default_path` — 使用正常输入验证“清理日志改为数量与 sample ID，禁止输出超长任务 ID 列表”的默认成功路径和主输出。
|
||||
2. `test_task_071_cleanup_logging_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_071_cleanup_logging_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_071_cleanup_logging_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_071_cleanup_logging_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_071_cleanup_logging_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_071_cleanup_logging_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_071_cleanup_logging_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 72：为文件作业实现数据库原子 claim，避免重复派发同一 job
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：71
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为文件作业实现数据库原子 claim，避免重复派发同一 job”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_072_job_normal_default_path` — 使用正常输入验证“为文件作业实现数据库原子 claim，避免重复派发同一 job”的默认成功路径和主输出。
|
||||
2. `test_task_072_job_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_072_job_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_072_job_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_072_job_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_072_job_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_072_job_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_072_job_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 73：为本地文件作业队列增加 in-flight 去重和队列背压
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：72
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为本地文件作业队列增加 in-flight 去重和队列背压”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_073_job_normal_default_path` — 使用正常输入验证“为本地文件作业队列增加 in-flight 去重和队列背压”的默认成功路径和主输出。
|
||||
2. `test_task_073_job_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_073_job_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_073_job_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_073_job_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_073_job_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_073_job_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_073_job_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 74：隔离调度线程池、文件作业线程池和外部 Coze/图片执行池
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：73
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“隔离调度线程池、文件作业线程池和外部 Coze/图片执行池”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_074_image_dispatch_job_normal_default_path` — 使用正常输入验证“隔离调度线程池、文件作业线程池和外部 Coze/图片执行池”的默认成功路径和主输出。
|
||||
2. `test_task_074_image_dispatch_job_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_074_image_dispatch_job_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_074_image_dispatch_job_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_074_image_dispatch_job_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_074_image_dispatch_job_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_074_image_dispatch_job_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_074_image_dispatch_job_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 75：为虚拟线程任务增加等待队列上限与拒绝/延迟指标
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：74
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为虚拟线程任务增加等待队列上限与拒绝/延迟指标”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_075_metrics_normal_default_path` — 使用正常输入验证“为虚拟线程任务增加等待队列上限与拒绝/延迟指标”的默认成功路径和主输出。
|
||||
2. `test_task_075_metrics_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_075_metrics_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_075_metrics_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_075_metrics_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_075_metrics_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_075_metrics_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_075_metrics_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 76：将 JSON owner 查询迁移到显式列并补充任务/状态复合索引
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：75
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将 JSON owner 查询迁移到显式列并补充任务/状态复合索引”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_076_owner_normal_default_path` — 使用正常输入验证“将 JSON owner 查询迁移到显式列并补充任务/状态复合索引”的默认成功路径和主输出。
|
||||
2. `test_task_076_owner_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_076_owner_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_076_owner_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_076_owner_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_076_owner_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_076_owner_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_076_owner_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 77：统一 Coze、品牌检查和紫鸟 HTTP 客户端的连接复用策略
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：76
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“统一 Coze、品牌检查和紫鸟 HTTP 客户端的连接复用策略”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_077_brand_normal_default_path` — 使用正常输入验证“统一 Coze、品牌检查和紫鸟 HTTP 客户端的连接复用策略”的默认成功路径和主输出。
|
||||
2. `test_task_077_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_077_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_077_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_077_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_077_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_077_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_077_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 78：为所有外部调用增加耗时、重试、失败率和 payload 字节指标
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：77
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为所有外部调用增加耗时、重试、失败率和 payload 字节指标”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_078_payload_metrics_normal_default_path` — 使用正常输入验证“为所有外部调用增加耗时、重试、失败率和 payload 字节指标”的默认成功路径和主输出。
|
||||
2. `test_task_078_payload_metrics_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_078_payload_metrics_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_078_payload_metrics_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_078_payload_metrics_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_078_payload_metrics_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_078_payload_metrics_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_078_payload_metrics_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 79：为对象存储、数据库和队列增加故障注入测试
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：78
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为对象存储、数据库和队列增加故障注入测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_079_object_storage_normal_default_path` — 使用正常输入验证“为对象存储、数据库和队列增加故障注入测试”的默认成功路径和主输出。
|
||||
2. `test_task_079_object_storage_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_079_object_storage_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_079_object_storage_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_079_object_storage_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_079_object_storage_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_079_object_storage_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_079_object_storage_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 80：补充 JVM 堆、直接内存、临时磁盘和连接池容量配置说明
|
||||
|
||||
**所属模块**：共享任务、对象存储、调度与清理优化
|
||||
**依赖**：79
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充 JVM 堆、直接内存、临时磁盘和连接池容量配置说明”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_080_task_normal_default_path` — 使用正常输入验证“补充 JVM 堆、直接内存、临时磁盘和连接池容量配置说明”的默认成功路径和主输出。
|
||||
2. `test_task_080_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_080_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_080_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_080_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_080_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_080_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_080_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||||
- 重点观察：backend-java 的 task、RustFS/MinIO、任务文件作业、调度线程池、历史清理和指标日志。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 模块完成 Gate
|
||||
|
||||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|
||||
@@ -1,726 +0,0 @@
|
||||
# 05 前端轮询、缓存、构建与交付验收
|
||||
|
||||
> 对应总览任务：81-100
|
||||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||||
|
||||
## 模块目标
|
||||
|
||||
减少浏览器端轮询重复请求、响应式对象和 localStorage 无界增长，降低首屏公共 chunk 体积，并通过真实页面交互确认核心链路没有 stub。
|
||||
|
||||
## 模块级执行规则
|
||||
|
||||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||||
|
||||
## 任务 81：建立前端任务轮询请求量、响应体大小和页面内存基线
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：无
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立前端任务轮询请求量、响应体大小和页面内存基线”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_081_polling_frontend_normal_default_path` — 使用正常输入验证“建立前端任务轮询请求量、响应体大小和页面内存基线”的默认成功路径和主输出。
|
||||
2. `test_task_081_polling_frontend_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_081_polling_frontend_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_081_polling_frontend_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_081_polling_frontend_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_081_polling_frontend_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_081_polling_frontend_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_081_polling_frontend_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 82：为进度响应 Map 增加 TTL 清理与最大条目数
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：81
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为进度响应 Map 增加 TTL 清理与最大条目数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_082_progress_cleanup_normal_default_path` — 使用正常输入验证“为进度响应 Map 增加 TTL 清理与最大条目数”的默认成功路径和主输出。
|
||||
2. `test_task_082_progress_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_082_progress_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_082_progress_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_082_progress_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_082_progress_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_082_progress_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_082_progress_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 83：统一不同页面的轮询去重、in-flight 合并和终态清理
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：82
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“统一不同页面的轮询去重、in-flight 合并和终态清理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_083_merge_cleanup_polling_normal_default_path` — 使用正常输入验证“统一不同页面的轮询去重、in-flight 合并和终态清理”的默认成功路径和主输出。
|
||||
2. `test_task_083_merge_cleanup_polling_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_083_merge_cleanup_polling_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_083_merge_cleanup_polling_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_083_merge_cleanup_polling_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_083_merge_cleanup_polling_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_083_merge_cleanup_polling_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_083_merge_cleanup_polling_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 84：优化店铺抓取队列状态合并，消除 historyItems 的线性重复查找
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：83
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“优化店铺抓取队列状态合并，消除 historyItems 的线性重复查找”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_084_merge_normal_default_path` — 使用正常输入验证“优化店铺抓取队列状态合并，消除 historyItems 的线性重复查找”的默认成功路径和主输出。
|
||||
2. `test_task_084_merge_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_084_merge_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_084_merge_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_084_merge_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_084_merge_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_084_merge_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_084_merge_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 85：优化 Similar ASIN 轮询与文件生成等待，避免重复 force 请求
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：84
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“优化 Similar ASIN 轮询与文件生成等待，避免重复 force 请求”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_085_asin_polling_normal_default_path` — 使用正常输入验证“优化 Similar ASIN 轮询与文件生成等待，避免重复 force 请求”的默认成功路径和主输出。
|
||||
2. `test_task_085_asin_polling_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_085_asin_polling_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_085_asin_polling_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_085_asin_polling_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_085_asin_polling_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_085_asin_polling_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_085_asin_polling_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 86：将隐藏页面轮询间隔、前台恢复和退避策略统一配置化
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：85
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“将隐藏页面轮询间隔、前台恢复和退避策略统一配置化”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_086_polling_normal_default_path` — 使用正常输入验证“将隐藏页面轮询间隔、前台恢复和退避策略统一配置化”的默认成功路径和主输出。
|
||||
2. `test_task_086_polling_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_086_polling_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_086_polling_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_086_polling_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_086_polling_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_086_polling_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_086_polling_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 87：限制 localStorage 中任务、快照和队列数据的最大数量/字节数
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：86
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“限制 localStorage 中任务、快照和队列数据的最大数量/字节数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_087_task_normal_default_path` — 使用正常输入验证“限制 localStorage 中任务、快照和队列数据的最大数量/字节数”的默认成功路径和主输出。
|
||||
2. `test_task_087_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_087_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_087_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_087_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_087_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_087_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_087_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 88：解析结果前端只接收预览数据，避免大 payload 进入响应式对象
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：87
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“解析结果前端只接收预览数据，避免大 payload 进入响应式对象”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_088_payload_preview_frontend_normal_default_path` — 使用正常输入验证“解析结果前端只接收预览数据，避免大 payload 进入响应式对象”的默认成功路径和主输出。
|
||||
2. `test_task_088_payload_preview_frontend_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_088_payload_preview_frontend_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_088_payload_preview_frontend_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_088_payload_preview_frontend_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_088_payload_preview_frontend_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_088_payload_preview_frontend_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_088_payload_preview_frontend_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 89：清理页面卸载时的所有 timer、请求和临时 URL
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：88
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“清理页面卸载时的所有 timer、请求和临时 URL”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_089_cleanup_normal_default_path` — 使用正常输入验证“清理页面卸载时的所有 timer、请求和临时 URL”的默认成功路径和主输出。
|
||||
2. `test_task_089_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_089_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_089_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_089_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_089_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_089_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_089_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 90：为进度接口增加断网、超时、服务恢复和重复响应测试
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：89
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“为进度接口增加断网、超时、服务恢复和重复响应测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_090_progress_normal_default_path` — 使用正常输入验证“为进度接口增加断网、超时、服务恢复和重复响应测试”的默认成功路径和主输出。
|
||||
2. `test_task_090_progress_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_090_progress_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_090_progress_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_090_progress_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_090_progress_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_090_progress_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_090_progress_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 91：按页面拆分 Element Plus 与公共业务 chunk
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：90
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“按页面拆分 Element Plus 与公共业务 chunk”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_091_chunk_normal_default_path` — 使用正常输入验证“按页面拆分 Element Plus 与公共业务 chunk”的默认成功路径和主输出。
|
||||
2. `test_task_091_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_091_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_091_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_091_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_091_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_091_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_091_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 92：配置 Vite manualChunks 并比较各页面首屏传输大小
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：91
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“配置 Vite manualChunks 并比较各页面首屏传输大小”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_092_chunk_normal_default_path` — 使用正常输入验证“配置 Vite manualChunks 并比较各页面首屏传输大小”的默认成功路径和主输出。
|
||||
2. `test_task_092_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_092_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_092_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_092_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_092_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_092_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_092_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 93：补充 Similar ASIN、店铺抓取和采集数据页面的 E2E 核心路径
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：92
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充 Similar ASIN、店铺抓取和采集数据页面的 E2E 核心路径”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_093_collect_asin_e2e_normal_default_path` — 使用正常输入验证“补充 Similar ASIN、店铺抓取和采集数据页面的 E2E 核心路径”的默认成功路径和主输出。
|
||||
2. `test_task_093_collect_asin_e2e_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_093_collect_asin_e2e_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_093_collect_asin_e2e_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_093_collect_asin_e2e_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_093_collect_asin_e2e_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_093_collect_asin_e2e_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_093_collect_asin_e2e_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 94：补充移动端与桌面端响应式页面验收截图
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：93
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充移动端与桌面端响应式页面验收截图”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_094_task_normal_default_path` — 使用正常输入验证“补充移动端与桌面端响应式页面验收截图”的默认成功路径和主输出。
|
||||
2. `test_task_094_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_094_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_094_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_094_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_094_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_094_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_094_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 95：补充深色主题、错误提示、重试和终态刷新验收
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：94
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“补充深色主题、错误提示、重试和终态刷新验收”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_095_task_normal_default_path` — 使用正常输入验证“补充深色主题、错误提示、重试和终态刷新验收”的默认成功路径和主输出。
|
||||
2. `test_task_095_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_095_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_095_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_095_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_095_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_095_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_095_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 96：建立 Java/Python/Vue 三端统一的 API 字段兼容检查
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：95
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“建立 Java/Python/Vue 三端统一的 API 字段兼容检查”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_096_task_normal_default_path` — 使用正常输入验证“建立 Java/Python/Vue 三端统一的 API 字段兼容检查”的默认成功路径和主输出。
|
||||
2. `test_task_096_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_096_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_096_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_096_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_096_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_096_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_096_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 97：执行 Java 全量测试、Python unittest、Vue 类型检查与构建
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：96
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“执行 Java 全量测试、Python unittest、Vue 类型检查与构建”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_097_build_normal_default_path` — 使用正常输入验证“执行 Java 全量测试、Python unittest、Vue 类型检查与构建”的默认成功路径和主输出。
|
||||
2. `test_task_097_build_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_097_build_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_097_build_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_097_build_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_097_build_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_097_build_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_097_build_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 98：执行真实启动、健康检查、核心请求和外部依赖调用验证
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：97
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“执行真实启动、健康检查、核心请求和外部依赖调用验证”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_098_task_normal_default_path` — 使用正常输入验证“执行真实启动、健康检查、核心请求和外部依赖调用验证”的默认成功路径和主输出。
|
||||
2. `test_task_098_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_098_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_098_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_098_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_098_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_098_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_098_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 99：执行全链路压测并记录 CPU、内存、GC、DB、Redis、RustFS、网络结果
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：98
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“执行全链路压测并记录 CPU、内存、GC、DB、Redis、RustFS、网络结果”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_099_rustfs_normal_default_path` — 使用正常输入验证“执行全链路压测并记录 CPU、内存、GC、DB、Redis、RustFS、网络结果”的默认成功路径和主输出。
|
||||
2. `test_task_099_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_099_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_099_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_099_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_099_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_099_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_099_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 任务 100：完成发布前回滚演练、git commit 对应关系检查和交付清单
|
||||
|
||||
**所属模块**：前端轮询、缓存、构建与交付验收
|
||||
**依赖**：99
|
||||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||||
|
||||
### 功能点要求
|
||||
- 围绕“完成发布前回滚演练、git commit 对应关系检查和交付清单”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||||
- 实现范围限定在 frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证。
|
||||
|
||||
### 测试用例（必须先写，确认 RED）
|
||||
1. `test_task_100_task_normal_default_path` — 使用正常输入验证“完成发布前回滚演练、git commit 对应关系检查和交付清单”的默认成功路径和主输出。
|
||||
2. `test_task_100_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||||
3. `test_task_100_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||||
4. `test_task_100_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||||
5. `test_task_100_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||||
6. `test_task_100_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||||
7. `test_task_100_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||||
8. `test_task_100_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||||
|
||||
### TDD 流程
|
||||
|
||||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||||
|
||||
### 验证方法
|
||||
- `npm run build` 通过；涉及页面的任务执行对应 Playwright/E2E 用例。
|
||||
- 检查浏览器 Network、Performance、Memory 面板，确认轮询请求无重复风暴、终态后停止、缓存有界。
|
||||
- 重点观察：frontend-vue 的任务轮询、响应缓存、队列状态、构建拆包和页面 E2E 交付验证中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||||
|
||||
## 模块完成 Gate
|
||||
|
||||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|
||||
|
||||
|
||||
## 全局收尾 Gate
|
||||
|
||||
以下验证必须在任务 100 完成后按顺序执行，任一项失败都不能将计划标记为完成：
|
||||
|
||||
1. 使用项目实际启动命令启动 Java 服务，并通过健康检查端点。
|
||||
2. 启动 Python 后端并确认核心管理入口可访问。
|
||||
3. 访问 Similar ASIN、店铺数据抓取和采集数据页面，确认标题、输入控件和任务区域存在。
|
||||
4. 使用真实最小文件完成一次解析、任务创建、任务执行和结果下载。
|
||||
5. 使用多样化输入验证关键业务逻辑不是固定模板或输入纯回显。
|
||||
6. 验证数据库、Redis、RustFS、RocketMQ 和外部 HTTP 服务在对应路径确实发生调用。
|
||||
7. 验证非法输入、依赖不可用、超时、断网和重复回传有明确错误或降级行为。
|
||||
8. 验证任务取消、页面关闭、服务重启和 owner 路由后不会残留锁、线程、timer 或临时文件。
|
||||
9. 运行 Java 全量测试并确认全绿。
|
||||
10. 运行 Python 测试并确认全绿。
|
||||
11. 运行 Vue 类型检查和生产构建并确认无错误。
|
||||
12. 运行 Java、Python 和前端 lint/format 检查并确认零错误。
|
||||
13. 使用 Playwright 完成桌面端页面可访问和关键交互路径验证。
|
||||
14. 使用 Playwright 验证断网、恢复、错误提示和重试行为。
|
||||
15. 如果页面支持主题切换，验证深色/浅色主题状态发生正确变化。
|
||||
16. 保存 Desktop 1280x800 与 Mobile 375x812 的响应式验收截图到项目约定目录。
|
||||
17. 执行接口字段一致性检查，确认 Java、Python、Vue 三端命名和状态值一致。
|
||||
18. 执行 `git log` 检查 1-100 每个任务均有对应 commit，且工作树状态符合交付要求。
|
||||
19. 最后执行 `python check_progress.py`，仅当输出 `all tasks done` 且退出码为 0 时，才允许宣布计划完成。
|
||||
Reference in New Issue
Block a user