cmshoppe/docs/tasks/T-672.md

id, title, status, phase, deps, created

id	title	status	phase	deps	created
T-672	更新蝦皮商品状态筛选与更新状态命名	DONE	7	T-671	2026-07-20

T-672 更新蝦皮商品状态筛选与更新状态命名

问题 / 背景

③「更新蝦皮」顶部的「状态」下拉实际表示已生成、失败、已更新等本地更新进度，而不是商品是否在架。虽然③开始更新时会用 product_status 严格预检，但运营无法预先只查看架上商品或定位被排除的未上架、审核中商品，且“状态”名称容易误解。

方案

• 在③筛选行的既有状态下拉左侧增加「商品状态」下拉，固定顺序为「批次、店铺、商品ID、商品状态、更新状态、刷新」。把原标签「状态」改为「更新状态」。
• 商品状态选项与 T-669/T-671 统一：全部商品状态、架上商品、未上架、审核中、状态未知、待检测。按原始 tasks.product_status 筛选：NULL/空白为待检测，显式 unknown 为状态未知，历史默认 normal 视为架上商品；不改状态字段或历史迁移结果。
• 商品状态、更新状态、批次、店铺和商品 ID 筛选叠加生效。更新状态继续使用已生成、失败、已更新、略过、全部状态的现有语义；商品状态筛选只缩小 model.tasks，_update_candidates() 只能从当前筛选后的列表取任务。
• 「检查本轮更新」和「开始更新」仍须对当前筛选结果重新执行 build_apply_plan()。商品状态下拉不是线上更新授权：只有 product_status=normal 且标题/封面内容完整的记录才进入 ApplyWorker；未上架、审核中、状态未知和待检测即使被筛选出来也只会在预检中列为排除项，绝不提交蝦皮。
• 更新确认框和检查摘要新增当前商品状态筛选的中文显示，使用户能核对“架上商品 + 已生成”等组合范围；确认后的计划指纹校验继续覆盖任务状态、更新时间、新标题和新封面变化，不因新增筛选放宽。
• 本任务不在③表格新增商品状态列，保留现有更新列表的紧凑布局；商品状态通过筛选、确认摘要和预检排除说明呈现。

验收标准

• ③筛选行显示「商品状态」和「更新状态」两个明确标签，商品状态位于更新状态左侧。
• 筛选「商品状态=架上商品」后点击检查或开始更新，只从该筛选结果构建候选，不会扫描同批次其他未上架、审核中或未知商品。
• 商品状态筛选可与更新状态、批次、店铺、商品 ID 叠加；确认框显示当前商品状态筛选和最终可执行数量。
• 选择未上架、审核中、状态未知或待检测后，检查/开始更新仍被既有状态预检阻止，不创建 ApplyWorker、不打开 Chrome、不提交蝦皮。
• tests/test_gui.py 与商品状态计划测试覆盖筛选交集、确认范围文本、只从当前模型任务取候选，以及异常状态无法绕过预检。

验证

py -3.10 -m unittest discover -s tests -p "test_gui.py"
py -3.10 -m unittest discover -s tests -p "test_product_status.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

非目标

• 不在③表格新增商品状态列，不修改现有列宽。
• 不放宽商品状态预检，不新增强制更新异常商品、跳过确认或批量状态修复入口。
• 不改数据库 schema、历史批次迁移、AI/CMHub、CDP/Shopee 自动化、Excel 或实际上传/更新流程。

执行记录

• ③筛选行新增「商品状态」下拉，原「状态」改名为「更新状态」；商品状态与批次、店铺、商品 ID、更新状态共同筛选当前 model.tasks。
• 确认检查/开始更新弹窗新增当前商品状态与更新状态范围；启动前仍重新执行 build_apply_plan()，异常商品状态不会创建 ApplyWorker 或打开 Chrome。
• 更新路由文档，并补充筛选交集、确认范围文本和未上架商品预检阻断的 GUI 回归测试。
• 验证通过：py -3.10 -m unittest discover -s tests（623 项）、py -3.10 -m ruff check app tests main.py、py -3.10 -m compileall app main.py、git diff --check。