diff --git a/docs/tasks/T-676.md b/docs/tasks/T-676.md
new file mode 100644
index 0000000..58b9534
--- /dev/null
+++ b/docs/tasks/T-676.md
@@ -0,0 +1,56 @@
+---
+id: T-676
+title: 三个工作流商品状态筛选默认值优化
+status: TODO
+phase: 7
+deps: [T-669, T-671, T-672]
+created: 2026-07-20
+---
+
+# T-676 三个工作流商品状态筛选默认值优化
+
+## 问题 / 背景
+
+①②③都已提供商品状态筛选，但当前新打开页面时均默认「全部商品状态」。这会让②AI生成和③更新蝦皮先展示未上架、审核中、状态未知等默认不能处理的记录，增加误操作和点数/线上更新范围判断的负担。
+
+三者不能机械统一为「架上商品」：①新导入任务通常仍是「待检测」，若默认筛到架上商品，运营会看不到刚导入的数据，容易误以为导入失败或没有待采集任务。
+
+## 方案
+
+- ①导入采集的商品状态筛选初始默认保持「全部商品状态」，让待检测的新导入记录可见；点击采集后的范围确认仍默认「采集架上商品」，由真实商品页检测结果决定是否继续采集。
+- ②AI生成的新页面初始默认选择「架上商品」，只先展示正常商品，降低异常商品误入生成范围和消耗点数的风险。
+- ③更新蝦皮的新页面初始默认选择「架上商品」，只先展示可能进入更新预检的正常商品，减少用户先看到大量必然被拦截记录的困惑。
+- 这仅是界面初始筛选值：用户主动选择「全部商品状态」或任一异常状态后，刷新、切换批次/店铺、输入商品ID和处理/生成/更新状态筛选时继续沿用既有的有效选择保留逻辑，不得每次刷新强制改回默认值。
+- ①②③的实际执行边界不变：①仍在商品详情页实时检测后由范围确认控制；②仍需范围确认，默认只生成 `normal`；③仍通过 `build_apply_plan()` 和 Worker 再次拒绝非 `normal` 或内容不完整任务。商品状态下拉只缩小当前列表和候选范围，不能成为绕过安全检查的授权。
+
+## 验收标准
+
+- [ ] 新打开①时商品状态筛选为「全部商品状态」，待检测的新导入行可见；采集范围确认默认策略不变。
+- [ ] 新打开②和③时商品状态筛选为「架上商品」，列表仅展示原始状态为 `normal` 的记录。
+- [ ] ②③主动改选全部、未上架、审核中、状态未知或待检测后，刷新或切换其他筛选条件不会无故重置为架上商品。
+- [ ] ②默认架上商品时开始生成、③默认架上商品时检查/开始更新，只以当前筛选结果构建候选；异常商品即使用户手动筛出，仍不能绕过既有范围确认、状态预检和内容预检。
+- [ ] 不修改 SQLite schema、历史商品状态迁移、Chrome/CDP、AI 调用、Excel 回写或线上更新逻辑。
+- [ ] `tests/test_gui.py` 覆盖三个页面的新建默认值、待检测可见性、用户选择保留及②③安全边界不回归。
+
+## 测试与文档
+
+- 更新 `docs/routes.md` 和 `docs/api.md` 中①②③商品状态筛选的默认值与“筛选不等于授权”说明。
+- 运行：
+
+```bash
+py -3.10 -m unittest discover -s tests -p "test_gui.py"
+py -3.10 -m unittest discover -s tests
+py -3.10 -m ruff check app tests main.py
+py -3.10 -m compileall app main.py
+git diff --check
+```
+
+## 非目标
+
+- 不新增商品状态字段、状态重检入口、批量状态修复或新的状态选项。
+- 不改变①采集、②生成、③更新的商品状态判定和安全拦截规则。
+- 不强制把用户当前主动选择的筛选值改回默认值。
+
+## 执行记录
+
+- 待实现。