feat(web): 前端 SPA 化 + 工具页任务面板统一与历史批量删除

- SPA 化：22 个 MPA html 入口与 *-main.ts 合并为 index.html + vue-router（URL 无 .html 后缀），
  页面跳转全部 router-link，/new_web_source/xxx.html 旧路径归一为 /xxx
- 任务面板统一：共享 TaskCenterPanel/TaskItemCard/TaskStatCards/HistoryTaskLayer，
  16 个工具页右侧统一为统计卡 + 当前任务 + 历史任务弹层（任务ID/开始/结束/状态必展示）
- 历史记录支持单条删除 + 批量勾选删除（确认框/全选/失败提示）
- Java 7 模块（dedupe/convert/split/productrisk/shopmatch/pricetrack/deletebrand）
  history 接口补齐任务时间字段（VO+Service，复用 biz_file_task 列）
- 图片工作台/API 层（brand/permission/user）既有未提交改动一并提交

prompts/step-1-brainstorm.md

@@ -0,0 +1,60 @@
+把 `<源码目录/需求输入>` 按目标 `<目标技术栈/需求描述>` 完成分析。
+
+> 本提示词覆盖三种场景，按实际情况选一种代入，其余流程（分析维度、向用户确认、生成 spec）通用：
+> 1. **技术栈迁移**：`<源码目录/需求输入>` = 现有源码目录，`<目标技术栈/需求描述>` = 目标技术栈。第一步保持"分析架构"。
+> 2. **全新项目**：`<源码目录/需求输入>` = 需求/设计文档路径，"第一步：分析架构"改为"分析需求与目标功能"。
+> 3. **现有项目重构/迭代开发**：`<源码目录/需求输入>` = 当前项目源码目录本身（技术栈不变），`<目标技术栈/需求描述>` = 本次重构目标或新迭代需求描述。第一步改为"分析现状架构 + 新需求/重构目标"，后续"迁移/实现顺序"理解为"改动/开发顺序"，第二步"技术栈"确认可跳过（已固定），改为确认改动范围与影响面。
+>
+> 占位符取值不要求用户按 key=value 填写：执行者应从用户对需求的自然语言描述（及当前工作目录的实际情况）中自动判断属于哪种场景、自动推断占位符取值；只有关键信息确实缺失（如完全看不出目标是什么）时才反问用户，而不是要求用户先按格式填表。
+
+## 你要做的事
+
+### 第一步：分析架构
+
+1. 通读 `<源码目录>` 下所有源文件，分析 import/依赖关系，画出依赖图
+2. 从依赖图中识别模块边界，按功能拆成独立模块
+3. 分析每个模块的内部结构（核心类、核心函数、对外接口）
+4. 根据依赖关系，从底向上确定迁移/实现顺序
+
+**在分析时必须覆盖以下所有维度**（不要遗漏，具体数量和目录名以实际项目为准）：
+
+- 源码根目录下的**每一个子目录**都是潜在模块，全部要过一遍
+- 源码根目录下的**每一个顶层源文件**也是潜在模块
+- 源码目录**外部**的功能目录也要纳入分析，包括但不限于：文档、前端/UI、插件与扩展、移动端或其他客户端等（视项目实际结构增减）
+- 发现新模块时，记录其文件数量、核心职责、被哪些模块依赖
+
+### 第二步：向用户确认关键决策
+
+分析完架构后，逐一向用户提问确认（每次只问一个问题），包括但不限于：
+
+- **技术栈**：分析原实现实际用了哪些库/框架，给出目标技术栈侧的候选及优劣，包括但不限于：核心运行时/SDK、Web 框架、前端框架、CLI 框架、类型系统/Schema 校验、依赖管理与打包、lint 工具、测试框架、E2E 框架、任务队列等（按项目实际需要取舍，不适用的类别跳过）
+- **迁移/实现范围**：列出分析过程中发现的全部模块清单，逐个询问是否纳入（不要跳过、不要模糊化、不要合并）
+- **项目结构**：目录结构、命名约定等
+
+不要替用户做决定，给候选 + 优劣分析 + 推荐，让用户选。
+
+### 第三步：生成 Spec 文件
+
+决策确认后，为每个模块生成独立 spec 文件，输出到 `docs/specs/`：
+
+```
+docs/specs/
+├── 00-overview.md    # 总览：技术栈选型、依赖图、模块关系、迁移/实现顺序
+├── 01-<模块名>.md
+├── 02-<模块名>.md
+└── ...
+```
+
+每个 spec 文件必须包含：模块职责、依赖关系、核心接口（原实现 → 目标实现，无原实现则直接描述目标接口）、内部结构、类型映射（如适用）、迁移/实现注意事项。
+
+### 约束
+
+- 不写代码，只做分析和设计
+- spec 是后续 step-2 拆任务的唯一输入
+- 每个 spec 文件独立可读
+- 每个 spec 只覆盖一个模块（或紧密耦合的一组子模块）
+- 00-overview.md 中的依赖图精确到"哪个文件的哪个符号被谁依赖"
+
+---
+
+确认后开始。先分析源码/需求，然后向我提问。