yanhui
776a2cbde2
业务 2026-10-28 定版：「核验抓取的销售订单表是错误的，应该在数据库抓 jst_Orders（订单）+ jst_OrderItem（明细），审核时间就是 jst_Orders 里的创建时间」。 ## 为什么换数据源（状态镜像表的硬伤，均有实测） 1. `send_time` 漏回写：近 7 天「状态表说发货中+未发」的 4157 单里， 订单表已有 `send_date` 的 563 单、status 已是 Sent 的 492 单 —— 发了还算超时。 2. 被合并 / 拆单父单不回写：89 + 755 单被冤枉。 3. 会整批停更：2026-10-27 11:54:59 之后 6.8 小时零写入，18:00 轮推出的 34 单里混着已发货的。 4. 两张表发货时间其实同源：27387 单逐条比对**零偏差** ⟹ 订单表才是权威。 ## 改了什么 后端 - 主查询改打 `rpt.jst_Orders` + `rpt.jst_qmcust_orderlist`（店铺互斥，UNION ALL， 按 o_id 去重），SQL 侧过滤 `send_date IS NULL` + `status IN (Delivering/WaitConfirm/Question)`。 - 起算点由状态表 `last_oa_confirm_time` 改为订单表 `created`； 实测 created 100% 早于审核时间，正常单差 7~40 分钟，夜间下单次日审的单差 6~9 小时 —— 换口径后单量与「已等时长」都会变大，业务已知悉。 - 仓库归属：主查询只回 `wms_co_id`，Node 侧用仓表缓存换仓名再走 `resolveCenter()` （实测 SQL 里 LEFT JOIN 仓表会把查询从 28s 拖到 61~105s）。 - `OPTION (RECOMPILE)` + 时间字面量：qmcust 不加 RECOMPILE 实测 33~50s，加上 0.4s。 - 删除 `backfillOrderFacts()` 与 `mapLimit()`（起算点/状态/仓名已由主查询一次取全）。 - 不再按 `is_split / is_merge` 过滤 —— 实测 `is_split=1` 恰是拆单**子单** （同一 so_id 多行、各自要发货，近 30 天 1096 行），老逻辑 `is_split=0` 会把它们全排掉。 - 钉钉明细第 5 段「审核 HH:mm」→「创建 HH:mm」，无值文案「未审核」→「无创建时间」。 前端 - 明细/挂起清单/导出列「审核时间」→「创建时间」，Tooltip 与说明文案同步改写； - 顶部说明补「数据源 = 订单两表」「已发未发取 send_date」； - 「已支付待审核」统一为「待审核」（新数据源里就是 WaitConfirm）。 测试 - 两个测试文件的桩改成「订单两表 UNION」的返回形状，断言改为 created 起算、候选状态白名单、SQL 必须带 RECOMPILE / 不含状态镜像表 / 不 JOIN 仓表。 ## 验证 - `npm --prefix backend run check`：491/493 通过。2 项失败是既有环境问题： `resilientSecretStore`（Windows 文件权限 0o666≠0o600）、 `cloudDatabaseConfigCache` 负缓存 TTL（依赖隧道状态），均与本改动无关，单独跑同样失败。 - 前端 eslint + build 通过。 - 真实库：NOON 1553 单 / AFTERNOON 1866 单（本地 2026-10-28）， 数据质量：无仓名 0 / 时间异常 0 / 含 undefined|null|NaN 0； 单次查询耗时 35~38s（30 天护栏，冷缓存）。 - 浏览器真渲染（playwright，强制 round=NOON）： 表头 `…发货时间 / 创建时间 / 付款时间…`、轮次提示「核验今天 07:00 前创建的订单」、 「导出明细」导出 CSV 表头含「创建时间」共 1551 行数据 + 1 行表头，无 pageerror。 ## 风险与回退 - 口径变化是可感知的：单量上升，夜间下单/次日审核的单「已等时长」增加 6~9 小时， 属业务确认后的预期结果。 - 状态表「售后已作废」判据随换源放弃（实测在「发货中+未发」里只命中 4 单）， 这类单现在按正常单算超时；如业务反馈，可单独补查。 - 回退：单文件回滚本提交即可，无数据迁移、无配置变更。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 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、密码、令牌、数据库备份或真实业务数据。