yanhui
3e64702f12
背景
- 业务反馈 MKHDNZ0409260601548 近 15 天实发 2 件、库存 0，页面既不报缺货也不进任何预警。
- 根因是双重盲区：
① 上游 rpt.pm_stockMonitor.fifteenAvgSale 漏算 —— 快照 09-18 下，窗口内有真实发货的
178 个 MKH 成品编码里有 24 个被记成 0；其中 16 个订单全部来自样品专用店铺（上游同样
不计样品单，属合理口径），剩 8 个是真实店铺（天猫/京东/拼多多）。该列是**保留两位
小数的日均**（最小非零 0.07 = 1 件 ÷ 15 天），无法用四舍五入解释。
② 快照日销 = 0 且待发货订单 = 0 时，判定直接落到「无销量」分支、hasWarning=false，
彻底排除在预警之外 —— 库存为 0 也救不回来。
改动
- 日销兜底（服务文件头新增 ⑦-a）：**快照日销 ≤ 0 且近 15 天有真实发货**时，日销改用
订单表实算值 = 已发货件数 ÷ 15；快照 > 0 一律以上游为准，不覆盖，避免两套口径打架。
· 排除样品/测试专用店铺（shop_name 含「样品」「测试」），与上游口径对齐
· 窗口 = 含今天在内的 15 个自然日，与分母同口径
· 结果透出 dailySaleSource('snapshot'|'orders') / snapshotDailySale / recentShippedQty
- 取数：loadPendingOrderIndex 重构为 loadOrderIndex，一条查询同时覆盖「待发货
（send_date IS NULL）」与「近 15 天已发货（send_date 在窗口内）」。实测合并后总耗时
约 1.25s ≈ 单查待发货，而拆成两条独立查询要在现有开销之上再加一次全表扫描
（首轮冷执行计划下 qmcust 单表可劣化到 20s+）。
- PENDING_ORDER_TABLES 更名 ORDER_TABLES：两张表的口径没变，只是不再仅服务待发货。
- 前端：日销来自兜底时加虚线下划 + 悬停说明，业务拿该数字与源系统 fifteenAvgSale
对照时不会被误判为数据错误。
验证
- 语法检查：151 文件通过。
- 后端测试：338 项 337 通过。唯一失败为 resilientSecretStore 的权限断言（期望 0o600、
Windows 实际 0o666），平台固有，与本改动无关。
- 新增回归测试：兜底生效 / 快照非零不覆盖 / 无发货不兜底 / 与订单驱动的优先级 /
订单源降级时退化成旧口径；订单索引测试补充「已发货同编码跨表累加」与「样品、测试店排除」断言。
- 真实数据端到端（本地接口 /api/mkh-bom/list，4,223 个成品）：
· MKHDNZ0409260601548：日销 0 → 0.1333（source=orders），不再隐身
· 日销 > 0 的商品 177 → 198；有效预警（缺货 + 预警）18 → 28
· 21 个等级变化**全部是「无销量 → 缺货/正常/已排产」**，没有任何既有预警被降级
· 其中 10 个新缺货均为「库存 0 + 近 15 天真实发货 9~27 件」的真盲区
· 样品店排除按整行生效：实测某编码窗口内 5 件（含样品店 1 件）→ 索引记为 4 件
- 前端 eslint 通过、vite build 通过。
风险与回退
- 只影响「快照日销 = 0」的商品，快照 > 0 的商品行为完全不变。
- 订单源不可用时兜底自动失效，退化成旧口径（不会误报）。
- 回退：本提交可整体 revert，无表结构变更、无数据迁移。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 Pull Request，代码按 MIT 许可证开放。
保留商品监控、仪表盘、激励看板、营销活动、推广、商品分析、工单以及在线客户端与执行任务等现有模块。部分菜单仍沿用原项目的占位页面。
已删除市场数据、店铺管理和运营工具整组页面、Claw 对话、skills 管理、平台切换与其他平台演示页，以及对应路由、页面资源、专属配置接口和权限项。首页为仪表盘。保留业务仍使用的模型配置、商品数据查询、桌面会话和自动上架公共服务继续可用；Claw 补全与图搜备用通道已经移除，缺失资料需使用业务接口或手工补充。
本地启动
需要 Node.js 22。团队开发机器无需安装或初始化 MySQL、Redis 及第三方数据库；使用管理员发放的部署 Key，一次注册后自动连接中央系统数据库、公网 TLS Redis 和第三方数据库。完整步骤及安全边界见 远程系统数据库部署。
npm --prefix backend ci
npm --prefix frontend ci
npm run remote:dev
首次启动时填写配置请求地址和部署 Key，系统自动写入被 Git 忽略的本机配置并重启后端。保存一次性显示的管理员账号和密码后直接登录，不需要在本地创建数据库或继续执行设置向导。前端默认访问 http://localhost:5173，API 默认代理到本地后端。
验证与构建
npm --prefix backend run check
npm --prefix frontend run check
前端构建输出位于 frontend/dist。部署时需为单页应用配置路由回退，并代理 /api 与 /cubejs-api 到后端。
启动时会迁移旧侧栏配置，并删除已退役页面的权限、专属设置和专用数据表。上架测算旧偏好表中的商品分析阈值会先迁移到商品分析专用表；其他保留模块的数据不受影响。迁移仅作用于实际配置给此实例的系统数据库。
参与修改
开始开发前请阅读 仓库提交与合并规范（多用户与 AI 开发必读）。准备更新生产服务器时必须继续阅读 服务器部署规范（开发者与 AI 必读）。AI 工具的规则入口为 AGENTS.md。每个任务使用独立目录和分支，通过 PR、同步验证和独立审核合并，禁止强推或覆盖其他开发者的工作。
所有用户均可 Fork 仓库、创建分支并提交 Pull Request。直接推送本仓库需要仓库所有者授予协作者写权限。提交时请说明修改和验证结果，勿提交 .env、密码、令牌、数据库备份或真实业务数据。