yanhui
893f4d6aca
需求（yanhui 2026-10-20）：在 MKH-BOM 列表左侧加一栏「仓储中心24小时发货时效」， 下列 11 个主仓（横林二仓、横林三仓、横林二仓品牌仓、崔桥工厂仓、崔桥工厂品牌仓、 崔桥工厂半成品仓、新苏北仓、睢宁仓、山东青岗集仓、山东品牌仓、河南洛宁仓）， 从系统库存抓取已发货/未发货订单，按订单创建时间判定发货是否及时： · 每天 12:00 核验「当天创建时间 7:00 之前」的订单是否已完成发货 · 每天 16:00 核验「当天创建时间 16:00 之前」的订单是否已完成发货 已确认的三条设计决策： 1. 子仓归属 → 连子仓一起算（京东云仓/自营仓/运营C专用仓/唯品仓等并入主仓） 2. 崔桥工厂半成品仓 → 系统无同名仓，先留空占位（不映射到配件仓 15718196） 3. 展示结构 → 只显示超时未发 实现要点 - 仓库归属用「关键词最长匹配」（不写死 wms_co_id），新增子仓只要名字含主仓关键词 就自动归入，缓存 1h。实测 28 个子仓全部正确归入 11 个主仓，132 个代发仓零误并。 - 12:00 之前**不做核验**：resolveActiveRound 返回 null，服务层直接返回 notStarted， 既不查订单表（接口 165ms）也不回填昨天的数据。前端显示「未到核验时间」+ 「12:00 开始首轮核验（核验当日 07:00 前创建的订单）」，11 个仓结构保留、数字显示「—」。 - 订单取数：两张表店铺互斥（jst_Orders = 京东/拼多多/抖音/得物/唯品会， jst_qmcust_orderlist = 天猫/淘宝/1688），并行分开查 + Node 侧按 o_id 去重合并， 用 Promise.allSettled 保证单表失败时另一表数据仍可用（detailDegraded 标记）。 - 三态判定 pending / shippedLate / onTime：send_date 与出库表 io_date 取先到的发货痕迹， 避免上游 send_date 回写滞后导致「已发的被判成没发」。 - 状态过滤：排除 Cancelled / Merged / **Split**（拆单父单永不发货，不排除会捞出一年前 1.3 万条历史单），Question 仍计入待发。 - freshness 字段如实报告出库表最新 io_date，前端「发货数据可能滞后」告警， 不拿一份可能滞后的数据去考核仓库。 排除的两次错误优化（均在代码注释里留了实测数据与复测脚本路径） 1. 用 created 替代 order_date 做窗口过滤（快 10 倍）—— 已证伪：2581 行里完全相等的只有 4 行， 差 >1h 的 412 行，198 行跨日；典型形态 order_date=10-18 23:58 而 created=10-19 04:00:08 （上游凌晨 4 点批量补录，created 是灌库时间不是下单时间）。业务口径是「订单创建时间」， 只有 order_date 正确。 2. 「UNION ALL 一条 SQL 慢 5~8 倍」—— 被后续实测推翻（46.3s vs 并行 48.2s，基本持平）。 验证 - 新增 backend/test/warehouseShipTimeliness.test.js，10 条用例全绿，覆盖： 最长匹配不误并、子仓命名、山东/河南高频前缀不误并、占位仓、12:00 前返回 null、 12:00 轮窗口 00:00~07:00、16:00 轮窗口 00:00~16:00、状态排除表、三态分桶互斥、 跨表重复 o_id 去重、round.windowEnd 必须带出（否则前端渲染成「核验 前」）。 - check-syntax 185 文件通过；全量 node --test 415 项 / 413 过 / 2 fail， 两条失败均为已知环境因素（负缓存带 TTL 因 .env 有 CLOUD_DB_* 短路； resilientSecretStore 的 Windows 权限断言，基线恒失败）。 - 真渲染验收（组件级沙盒 + 真实接口数据）：两态均 0 控制台错误； 已核验态 358 单超时未发、8 个仓有数字、点仓切换选中/再点取消均正常； 多分辨率验证 1920/1600 侧栏 208px、1440/1366 收窄 176px、列表始终竖向。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 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 run remote:dev 进程并重新启动，保证前后端使用同一版本。MKH 页的强制刷新带有版本协议校验；如果新前端仍代理到未重启的旧后端，页面会停止展示可能过期的库存并明确提示重启，不再将旧值冒充为“最新数据”。
验证与构建
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、密码、令牌、数据库备份或真实业务数据。