QiuSWandClaude Opus 5
c6bafd968e
解除 #17 的单商品限制，改为勾选多个一次上传，逐个串行处理。 选定文件的方式彻底改了：不再查 videos 表，改为扫描 <video_dir>/<蝦皮ID>/*.mp4 按文件名升序取第一个。原因是使用者可能手工把 别处来的视频放进目录，那类文件在 videos 表里没有记录；而且库与磁盘的漂移 无法根绝（手动挪文件、换 video_dir、外部程序写入），以磁盘为事实来源更稳。 上传前用 ffprobe 按货憨憨的要求本地预检，不合规的跳过而不是白传： 大小 <= 30 MB 时长 10.0 <= duration <= 60.0，严格比较不取整 格式 容器为 mp4 像素 宽 <= 1280 且高 <= 1280 时长必须严格判定：本地已有的 49365131605_1.mp4 是 9.985011 秒， 差 0.015 秒卡在门槛下，任何取整都会把它误判为合规。 ProbeResult 相应增加 Width / Height。 每个商品四条分支，任一分支结束后继续下一个： 远端已有视频且勾选 > 1 -> existing，跳过，不发任何写请求 子目录没有 mp4 -> missing，跳过 有文件但不合规 -> invalid，last_error 写明违反哪条及具体数值 合规 -> 上传，done / failed 覆盖策略：batchUpdateShopProductVideo 是覆盖语义且不可恢复，所以批量永不 覆盖远端已有视频，单个（勾选 == 1）保持 #17 的红字警告加二次确认后可覆盖。 判断依据是实时读取的远端状态，不用本地 video_diagnosis——后者只在 「下载数据」时刷新，可能已经过期。 这三个新状态只是上一次尝试的结果记录，不构成断点：批量只处理当次勾选的 商品，不会因为状态是 missing/invalid/existing/failed 就把商品排除在外， 每次点上传都重新扫盘、重新预检、重新读远端。这是为了避免重蹈 video_status='none' 被断点永久跳过的覆辙（见 #15）。 上传成功后按 product_id + local_path 写入或更新 videos 记录， source_item 留空（磁盘还原不出来自哪个淘宝同款），不使用 ReplaceVideos。 按负责人明确决定，不做容量门禁，仅保留确认框中的静态提示。 测试全部用 httptest 假服务器，未向真实货憨憨发出任何请求。 真机验证尚未进行。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LbdtsD3ohhSMy3KPoCgARq
cmsp
cmsp 是内部使用的 Windows 桌面工具：把货憨憨 ERP 中指定 Shopee 店铺的商品，按商品主图到淘宝搜同款，抓取同款商品详情页的介绍视频，下载到本地，再批量上传回货憨憨对应商品，使 Shopee 商品页刷新后能看到视频。
技术栈为 Go + Wails v2 + Vue 3 + Naive UI + SQLite，只支持 Windows。项目采用 DevHarness 工作流：需要工单的任务以 Gitea 工单为单次任务事实来源，Gitea Wiki 保存长期文档，Git 记录代码变更，人负责确认目标和验收。
治理模式为轻量。内部工具、单人开发、不对外交付、无常驻服务，因此不设置超出实际风险的门禁。
当前状态
Go 骨架已建立：Wails v2 窗口、参数设置读写、SQLite 存储和脱敏日志可用并有单元测试覆盖。
货憨憨与淘宝的业务功能尚未实现——界面上「下载数据」「下载视频」「上传数据」三个按钮点击后会明确提示还没实现。这些能力目前只存在于仓库外的两份已验证 Python 实现，正在按工单逐步迁移为 Go。
任务闭环
讨论需求或缺陷
-> 阅读代码并提出方案
-> 人工确认方案
-> 创建单元任务工单（需要时先建 Epic / MVP）
-> Agent 实现并测试
-> 提交代码并更新工单
-> 工单集中回写最终证据并等待人工验收
-> 人工验收后在工单记录结论
-> 关闭工单并更新父工单；长期事实变化时才同步 Wiki
轻量模式下符合直接实施条件的小 Bug、局部 UI 和单模块低风险调整不走上述闭环：确认目标 → 最小修改 → 受影响范围测试 → 提交并报告结果。
涉及货憨憨写操作、账号凭据、SQLite 结构迁移、并发或删除数据时必须建工单并按高风险处理。
快速开始
-
克隆本仓库到本机，例如
D:\chengma\cmsp。 -
创建 Gitea 远端仓库并推送当前引导提交，启用工单和 Wiki。
-
配置
wiki-docs.json和安全访问方式；优先使用已配置的 Gitea MCP，MCP 不可用时才使用 Gitea API 并记录原因。令牌只通过环境变量或 MCP 安全配置提供，不写入仓库。 -
按 新项目文档初始化 查询线上 Wiki；
Home不存在时先创建并回读Home，取得 revision 后再创建其他核心页面。 -
治理模式已在 项目档案 选定为轻量；不可违反的安全规则写在根目录
AGENTS.md的「项目专用规则」。 -
需要工单时使用
.gitea/issue_template/中的模板。本地docs/的存在不能证明线上 Wiki 已初始化。 -
开始产品代码前运行：
python dev_scripts/harness.py sync --verify
常用命令
git status --short --branch
python dev_scripts/harness.py check --strict
python -m unittest discover -s tests -v
python dev_scripts/harness.py sync --check
产品构建与测试命令在 Go 骨架建立后补入 本地开发与验证。
目录
AGENTS.md Agent 的通用工作规则与本项目专用红线
CLAUDE.md Claude Code 的规则入口
.gitea/issue_template/ Epic、MVP、单元任务工单模板
docs/ Gitea Wiki 核心页面的只读镜像
docs/task/ 人工明确要求的专项快照，默认为空
wiki-docs.json 核心 Wiki 页面到本地镜像的显式映射
dev_scripts/harness.py check / sync / archive / export 单一入口
dev_scripts/wiki_docs.py Gitea Wiki 客户端与镜像生成库
tests/ DevHarness 结构自测
main.go / app.go Wails 入口与暴露给前端的方法
internal/config/ 参数设置的读写与校验
internal/store/ SQLite，所有状态的唯一事实来源
internal/logx/ 带脱敏的日志
frontend/src/ Vue 3 + Naive UI 界面
config.example.yaml 本机配置模板（config.yaml 不进 Git）
docs/ 由同步工具生成，不要直接编辑。
安全底线
无论治理模式如何裁剪流程，下面几条不可违反：
- 账号、密码、token、Cookie、Chrome Profile 内容不得写入代码、日志、工单、Wiki 和提交。
- 淘宝登录必须由使用者手动完成，程序不代填密码、不绕过验证码与安全验证。
- 淘宝登录失效必须中断整批任务，不得降级为单商品失败后继续。
- 对真实店铺的批量写入、覆盖和删除必须获得明确授权。
- 测试结果必须真实，未执行或无法覆盖的验证必须写明。
文档
默认不创建任务归档；archive、export 只作为人工显式触发的兼容能力。长期文档的唯一编辑入口是 Gitea Wiki，修改顺序为：修改 Wiki → 读取确认 → 导出核心 docs → 校验差异 → 提交镜像。