⚙️ 任务调度

共享队列架构 — 多任务共用调度器、全局并发上限

⚙️ 本文件由 pnpm docs:rebuild 自动生成 — 修改无效。

涉及文档（43 个）

📐 架构 / 知识沉淀（5）

• 云端同步架构（SPEC-004 Phase 3 准备） · stable
• 为什么所有 sync-related 数据用 jsstore；4 类同步数据的 store 设计预览
• 扩展 reload 生命周期（MV3） · stable
• SW 重启 + chrome-extension tab 失效 + 双轨恢复机制全流程
• 设置字段语义对照
• settings 全部字段的实际语义、对应源码、易混淆点 — 改 UI 前必查
• 共享队列架构
• v0.10.0 后的核心调度模型 — 多任务共用一个调度器、Tab/worker 是全局资源
• Tab 生命周期与看门狗
• 抓取 Tab 的创建/销毁完整流程 + v0.10.15 看门狗的兜底机制

🎯 功能规格（4）

• SPEC-000 — v2 UI 改版说明（v0.8.58 → v0.9.x → v0.10.x） · done
• 早期整体界面改版历史档案；dist/ 与 dist-v2/ 双轨阶段进度记录
• Watchdog 核弹重启后自动恢复（带上限保护） · done
• 核弹重启后默认自动 pumpTasks，避免无人值守场景必须手动点开始；加 cycle 上限防止无限循环
• 文档治理自动化（docs:check + docs:rebuild + _overview） · done
• 用脚本 enforcement 解决"INDEX 脱节 / 断链 / 重复信息"持续累积的问题
• SPEC-006 — task delete 时二选一 confirm 商家数据去留 · done
• controlTask('delete') 前弹 dialog 询问"是否一并删除该任务的 N 条商家数据" — 解决孤儿数据 UX

🔧 已知问题 + 修复（17）

• 长时间运行后浏览器卡死 / 累积孤儿 Tab · fixed
• 插件运行时间长，会导致电脑卡死，页面没正常关闭，是不是要加上定期的检查？确保浏览器正常关闭，而不是打开一堆？
• 设置字段命名望文生义，与实际语义矛盾 · fixed
• 设置字段名暗示与实际语义矛盾，反复出现（已写成铁律）
• Watchdog 鲁棒性三连：并发触发 / nuke 不真关 tab / 计数残留 · fixed
• watchdog 鲁棒性三连：并发 / nuke 不真关 tab / 计数残留
• mailto 链接 URL 编码 body 污染邮箱字段 · fixed
• 邮箱正则把 mailto: 链接的 ?body=%xx 编码字符串当邮箱本地部分抓进来
• Google 验证拦截后用户感知 + 恢复体验差 · fixed
• 拦截已被检测+任务已暂停，但 UI 看不到状态、要逐个点继续、新开 maps tab 多余
• 拦截恢复机制在 SW 重启时丢失状态 + setTimeout 不可靠 · fixed
• verifyTabId/lastInterceptedAt 是 module-let 不持久化，setTimeout 在 SW kill 时丢
• watchdog 自动恢复 cooldown 用 setTimeout（SW kill 时丢失） · fixed
• v0.10.23/24 的自动恢复 cooldown setTimeout 在 SW kill 时丢，与 ISSUE-0026 同款
• doResumeFromInterception 只调 manageQueue 漏地图调度 · fixed
• 拦截恢复后地图任务不重新派 tab，纯地图任务自动恢复无效
• DataView 浪费 IndexedDB taskId 索引 + onMessage listener 无 cleanup · fixed
• 每 5s 拉全表再 JS filter（应 where 走索引）+ unmount 后 listener 残留 stale closure
• 第三轮 agent 找到 3 真 bug — watchdog 镜像 / 死 listener / 正则漂移 · fixed
• 第三轮独立 agent 验证收敛失败，3 个真问题
• 第四轮 agent 找到 ISSUE-0031 第 4 兄弟 + 2 个孤儿 listener · fixed
• 同函数内 3/4 分支补了 pumpAllSchedulers 漏第 4 个 catch 兜底；2 个 dead listener 工具盲区漏检
• 「去创建任务」按钮点击无反应 — storage API 混用 · fixed
• 按钮用 browser.storage.local.set 原生 API，watcher 用 wxt/storage 抽象，key 不同步
• 第 8 轮 agent — scan 工具盲区暴露 4 个新 bug + 扩 3 类新规则 · fixed
• scan:error-handling 只扫 promise chain 一级形态，try/catch + .finally(resolve) + 裸 sendMessage 三类完全在盲区
• 商家列表 chip count 截断 50k + 加载慢（22w 数据时） · fixed
• 22w 数据 chip "全部" 显示 50k；merchant-stats 每 10s select 50k 行
• 商家列表打开卡顿 — rows polling 5s + create_time sort 双重 IndexedDB 压力 · fixed
• merchant tab 比 website/email/phone 多跑 server-pagination + 22w sort 双 IndexedDB transaction，B+C 方案优化
• dynamic-scraper.ts tabStatus/tabError Map 加 onRemoved 兜底清理 · fixed
• v0.10.44 raw 待办收口 — webRequest 监听 all_urls 写 Map 无 tab.onRemoved 清理；4 行代码修
• SPEC-006 cascade 删命中 ISSUE-0008 历史回归 — where:taskId 老 DB 给 0 行 · fixed

📋 工作流规则（8）

• 备份与开发日志
• 改代码前必做的备份 + 全程开发日志记录规范
• Rule — 修 bug 必走全字典扫描（防补丁不彻底家族） · stable
• 每修一个 ISSUE 后必扫所有同模式 — 防止"修了触发点，漏了姊妹
• Rule — 独立 agent 审查（消除作者 anchor bias） · stable
• 关键代码必须由没参与原始实现的独立 agent 复核
• Rule — MV3 持久化陷阱清单（每次 background 改动跑一遍） · stable
• setTimeout / module-let / SW kill 等 MV3 通用陷阱的自查清单
• 抓取 pipeline 决策表 / mstage 标签速查 · stable
• SPEC-004 多阶段抓取 — 每种 mstage 标签的含义、UI 颜色、DB 行为速查；改 UI 或逻辑前必看
• 改设置项 / UI 文案 — 前置自查
• 改 settings 字段或调度相关 label/helper 前的必做检查
• 版本发布铁律 — 项目版本更新总规范 · stable
• 改设置页/调度逻辑/文案前必读；第七章 MV3 持久化陷阱 16 条铁律
• 中文标点 → Edit 工具兜底方案
• 含中文标点的旧 JSX/TS 改不动时，用 Python 切片替换

🗒️ 原始素材（6）

• 反馈 — 地图实开 (265) 比 地图请求 (249) 还多，反直觉 · processed
• settings 里讲"实开 1 → 后台翻 14 页"，但日志显示实开 > 请求
• 系统性盲区 — 前端 React lifecycle 一直没人查 · spec-ed
• 本会话 14 个 issue 0 个针对 useEffect cleanup / unmount race / setState-on-unmounted
• 反馈 — Google /sorry/index 验证拦截交互不到位 · spec-ed
• 已检测+暂停但 UI 无横幅、无 toast、要逐个点继续、又开新 tab
• 反馈 — 邮箱列表出现 168 字符的怪邮箱 · spec-ed
• mailto 链接的 URL 编码 body 被当成邮箱本地部分抓进来
• task delete 不删 MapTaskData 行 — 设计 vs bug 待确认 · spec-ed
• controlTask('delete') 只删 task store + progress，不删该 taskId 的商家数据行
• 反馈 — Watchdog 重启后希望自动继续，而不要手动点开始 · spec-ed
• 系统通知截图后，用户报告自动暂停的任务需要手动点开始才能恢复

给 AI / 新协作者的建议阅读顺序

1. 先读 wiki（了解架构）
2. 再读 specs（了解需求 / 设计决策）
3. 遇到 bug 查 issues（避免重蹈覆辙）
4. 追溯起源看 raw（用户原话）