ZIPFORCE Hub 变更日志

财务 apr 源表化改造：7 接口源表直读，onno 9月订单从 0 恢复到 134 单 生产pen_tests 全过

根因：finance_monthly 中间表只从 SP-API 财务事件（spapi_finances）单源灌入，onno 的订单/广告/结算没交叉进去——spapi_finances 天生残缺（要求 seller_sku 非空 + 财务事件滞后），导致财务页订单数严重漏单：onno 8月中间表 126 单 vs 源表 431 单、9月中间表 0 单 vs 源表 134 单。

改造（源表直读）：订单/营收→amazon_orders，费用→order_fees，广告→ads 表，回款→amazon_settlement_monthly，退货→amazon_refund_monthly，不再读 finance_monthly。GLM 先改 /api/finance/full 主矩阵 fin+cost CTE（快照 backups/code-2026-09-18/）；Kimi K3 接续完成剩余 6 接口 + full 内部 4 处遗留：summary / sku-profit / kpi-wall / product-pl / profit-matrix / onno + full 的国家KPI子查询/年度对比/未映射SKU计数/profit-matrix月份列表。

口径写死：①有效订单=order_status NOT IN(Canceled,Cancelled)；②净额=revenue_usd−佣金−尾程−促销−其他（order_fees 为 USD）；③SKU 级按 sku_list 逗号展开平摊（多SKU订单约9%）；④country→marketplace 用 marketplaces 表映射（GB→UK 特例），不再用 _AMZ_CC（那是 finance_monthly 的 marketplace 映射）；⑤本地币 net 无源（order_fees 仅 USD）→ 拍板用 USD 净利率折算 local_net=local_amount×(net_usd/revenue_usd)；⑥费用滞后时 net≈rev（9月费用未进 order_fees），订单数/营收仍准。

保留未改：/api/finance/monthly 是财务三方对账口径（posted_date+settlements），用户拍板不改（对账本就该用财务事件口径，与业务指标不同）；Noon 系列（noon/summary、noon-sku、noon-pnl）与本次 onno Amazon 漏单无关；/api/settlement 本就是源表直读。

验证：每接口改完跑 pen_tests 全 PASS；剩余 finance_monthly 实际 SQL 引用清零；双视口截图自检通过。桌面截图 · 手机截图。

配套方案文档：🔗 数据链路盘点（mercury raw → SaaS 中间表 → API → Web 全链路图 + 27+ 中间表明细 + 口径清单 + 对照理想架构的 4 缺口）。归档入口：changelog.zipforcehub.com 子域上线（显式站点块，不走 on_demand——changelog 非租户 ask 会拒；普通 ACME 签发，DNS 已指向本机），根路径默认打开本页，截图/方案/审计同域可访问。

架构铁律落地：全站 113 张图标题迁前端（Web 写死框架，API 只注数据） 生产四门全过

用户令：「Web端写死框架，API注入数据，所有页面都是这样」——标题/布局/列名固定在前端组件，API 只返回 key+kind+x+series。

实施：①新建 web/lib/chartTitles.ts——113 张图的 key→{title,hint} 注册表（从线上 API 提取，写死在前端）；②BrandBoard.tsx 和 NoonBoard.tsx 的 ChartCard 渲染改为从注册表取标题（CHART_TITLES[c.key]?.title），不再读 API 的 title/hint 字段；③API 侧 title/hint 保留在响应中（向后兼容/供审计工具读），但前端已不再消费——后续可在 API 清理。四门全过，双墙截图自检通过。

结构性防御：标题在组件文件里和 API 调用写在一起——改了查询参数，标题就在旁边看着你，文实不符一眼看出。标题语义锚门继续在 dashboard_audit 常驻（从 API 侧对比标题声明 vs 数据实际）。

订单时段分布按品牌分系列（用户第 N 次催办）+ 第 3 步备份迁移 生产四门全过

用户实锤"你他妈的分品牌了吗？说了多少次了"——hourly24 和 hourDist 两图此前只有一条混装系列。修复：sales_hourly 查询改按 (brand, hour) 分组，每品牌一条系列（fittingirls 1078 / onno 399 / zipforce 484）。切具体品牌时自动只剩该品牌一条。四门全过。

第 3 步备份迁移：backup-zipforce.sh(WordPress DB) + backup-pg-analytics.sh(PG dump) 的触发权从 mercury crontab 移到 mars crontab（SSH 触发，备份文件仍在 mercury 本地）。cleanup_braionow_tunnel.sh 留 mercury（本机基础设施，同 acme.sh 性质）。mercury crontab 现在只剩 acme.sh + 隧道清理两条。

第 2 步迁移完成：mercury 3 个定时任务收编 mars 生产四门全过

迁移清单：①sourcing-v2-dispatcher（原 mercury systemd timer 每分钟）→ mars 宿主 crontab（SSH 触发，脚本仍在 mercury 执行）；②label_price_status.sql（原 mercury crontab 每小时×2）→ mars worker cron 直连 mercury PG（psycopg2，SQL 已拷至 /collection/scripts/）；③align_zf_fg_schema.sql（原 mercury crontab 每日 04:00）→ 同②。mercury 侧已停：systemd timer stop+disable、crontab 移除 label_price 与 align_schema 两行。

mercury 剩余 cron（均为基础设施，第 3 步处理）：backup-zipforce.sh / acme.sh / cleanup_braionow_tunnel / backup-pg-analytics.sh。

通路要点：SQL 类走 worker 容器 psycopg2 直连（104.194.81.222:5432，凭据 /collection/secrets/db.json，与采集器同通路）；Python 脚本类走宿主 SSH（容器内无 SSH 别名）。实测 label_price_status 从 worker 容器跑通（0 行更新=当前无待标数据，正常）。

onno 品牌标签根治（mapping table 判定）+ 第 1 步迁移完成 生产四门全过

根因：mars `zf_amazon.py` 适配器第 15 行 `BRAND='zipforce'` 硬编码——zf 账号拉的所有订单（含 ON-SKU 欧洲单）全标 zipforce，9 月起 81 单 onno 产品被错标。用户令 「一切以 mapping table 为核心，不猜前缀」。

修复：①`_brand_for_order` 改为启动时加载 `shared.mapping_onno`（32 SKU→onno）+ `shared.mapping_fittingirls`（832 SKU→fittingirls），逐单按 items SKU 查映射判品牌，未匹配→zipforce 兜底；②重拉全量 12 市场 139 单，**81 单 onno 全部回位**（源表 onno:81 + zipforce:171 = 252 正确分布）；③SaaS 明日 04:30 全量 ingest 自动对账纠正旧标签。

新铁律（用户令）：①数据抓取与 API 注入相互独立、互不干扰——数据库是什么 API 就注入什么，LLM 全程不碰数据流；②不允许拿"自洽"当正确性证明——数据来源问题直接确认源头；③一切以 mapping table 为品牌归属唯一真源。三条已入 AGENTS.md 口径铁律段。

「最近数据日24小时订单」标题撒谎案 + 标题语义锚门 生产四门全过

用户实锤"onno 过去24小时 100多单"两轮——真相：/dashboard/onno AMZ 墙的「最近数据日 24 小时订单」图，标题声称最近一天、代码实际算的是整个窗口（30 天）订单按时段聚合（合计 368=30 天量，onno AMZ 真实日均 ~12）。数值层全对（与 SQL 互证），错的是标题语义——所有门都验"数对不对"，无门验"标题是否说真话"。onno Noon 侧经双源互证确认为 ~5 单/天（日级采集与月度结算一致），此前"100多单"判断即源于此图。

修复：①hourly24 与同案 hourDist 标题改为「订单时段分布（窗口合计）」+ hint 明示"窗口内全部订单聚合·非单日量"；②新立标题语义锚门（dashboard_audit）：凡标题/hint 含"最近数据日/今日/24小时"的图，系列合计必须≈SQL 最新单日量，否则 FAIL——上线首跑即抓到第二个同案犯 hourDist，修后 178+ 项全绿。

文档三件套：业务流·数据流图 / 定时任务总览 / 底账终态 文档

①🗺 业务流·数据流全景（新 tab）：业务闭环五层（数据接入→经营分析→决策→带护栏执行→履约回款+质量回路）与数据管道全链（平台API→mars采集器→源库→ingest对账→96表RLS→口径层→页面→用户，旁路监控报警→自动补抓），Mermaid 双图 + 关键口径锚点（一个口径一份实现/并集铁律/回款费用真源/禁裸零）。②⏰ 定时任务总览：23 项任务五层分类，每项节奏+工作内容+新鲜度核验（2026-09-17 实测全吻合）。③底账烧名单终态 226✅/24📖/5⬜/1❌。三页与 changelog 互链成导航区。

⬜烧名单完成（175 项派发·150+ 回填）+ 全站 toast 静默 bug 修复 生产四门全过

9 窗口并行实点验证 175 个未测控件（写操作点到弹窗即止/禁真推真发），回收 150+ 条带证据结果合并入底账。烧出 1 个全站性真 bug：5 个页面主组件 toast 静默失效（/listings /mapping /settings /onboarding /promotion）——页面组件在 AppShell 内嵌 KitProvider 上方调用 useToast() 拿到空 context，创建/保存/删除等操作反馈全部丢失。修复=KitProvider 上移根布局（layout.tsx）+ 从 AppShell 摘除（同治 useConfirm/usePrompt 同病）。实测 /listings 空创建 toast 正常弹出。

甄别澄清：po 窗口 3 个按钮"点击超时"= 抽屉遮罩挡住后续点击的脚本误报（新建 PO/预警导入/供应商添加实测全部正常开抽屉）；ads 花费门槛"KPI 不变"= KPI 全量池口径非 bug（已注）。底账终态：226 ✅实点 / 24 📖代码级 / 5 ⬜未验证 / 1 ❌(培训2卡404)——剩余 5 ⬜ 为 billing 套餐切换三件套+产品串链+供应商表单真提交，均涉及计费/写路径留待专项。

功能验证底账页：/audit/checklist.html——28 页 258 项控件逐项「逻辑描述+验证状态+证据」，四态计数 49✅实点 / 21📖代码级 / 185⬜未验证 / 1❌(培训2卡404列P2)，与 changelog 互链。铁律：本账永不预填✅。

项羽（mercury six-codex 飞书机器人）已停用：模型余额耗尽+Lark websocket 每日崩，systemctl stop+disable。同族 zhangsanfeng-codex-bridge 仍在运行（未动，待拍板）。mercury 侧 sourcing-v2-dispatcher/备份/schema 对齐等 cron 均为 SaaS 数据链上游，保留不动。

UVPVP 培训内容整体搬运入站（用户纠偏：复制内容，不是挂链接） 生产四门全过

上一版挂外链被用户否决（"我是叫你把内容复制过来"）。本版从 mercury /opt/uvpvp/backend 搬运四页培训内容入 static/training/uvpvp/（Caddy 宿主直出）：核心词汇（100 行术语表）/ 运营 SOP / Listing 教程 / Listing 设计规范（含 13 案例图 + 19 张版式实拍图）。处理：去 Jinja（breadcrumb+portal nav）、内联设计变量（--zf-red 色系等）、交叉链接本地化（vocab↔sop↔listing↔design、BraiNews 指向站内既有副本）、源 1.9G 资源目录只保留页面真实引用的 32 张图（5.9MB）。培训页区块改为「UVPVP 培训内容（本地搬运）· 无需 UVPVP 账号」四张内链卡。

截图自检：培训页 · 词汇页（表格 100 行渲染正常，design 页 37 图 0 破图）。

培训页接入 UVPVP 外部培训站三课程 生产四门全过

用户指定加入：/training 新增「UVPVP 外部培训站」区块——核心词汇（vocab）/ 运营 SOP（sop）/ Listing 教程（listing）三张外链卡片。三个链接实测均 302 跳 UVPVP 登录页（login?next=… 登录后自动回课程页），故卡片标注「需 UVPVP 账号登录 · 登录后自动跳回课程页」。双视口截图自检通过（桌面 · 移动）。

元素×断言类交叉矩阵 + 站点(国家)隔离入闸 生产四门全过

背景（用户质问"都测试了怎么还有问题"）：元素枚举早已全量（517 卡/443 图），但每元素挂的断言类是逐个补的——枚举全、断言不全，每补一类就抓到上一类漏网。解法=交叉矩阵一遍跑：每图表系列 × {品牌加和、站点(国家)加和、空系列}全断言，首跑 75 项 0 违规（品牌隔离 bug 已在上一条修净）。

站点隔离固化进 dashboard_audit：country 维度同款加和不变量（AMZ 17 国 + Noon AE/SA），与品牌隔离共用排除表（比率/Top-N/按实体）。四门全过。

当前断言类清单（每元素全挂）：渲染像素非空白 / 值对账(KPI 57 项+节点 2905) / 品牌加和 / 站点加和 / 时间窗语义 / 注释 desc-foot-hint / 响应无 ≥400 / 空系列检测。如实列出尚未覆盖面：表格行级逐行对账（45 表 1385 行只验了有行/空态）、写路径（表单提交/CRUD）、移动端布局（用户已叫停）。

品牌隔离审计立闸 + 月度结算字典覆盖 bug 修复（全部≠Σ品牌的实锤） 生产四门全过

背景（用户实锤"要按品牌和平台区分，你都混到一起了"→"所有数据要随品牌/站点/国家/时间自动筛选，审计怎么没审出来"）：昨天的联动断言验证"请求带 brand 参数+首卡值变化"，从不断言"每个图/系列真的按品牌隔离"。新立品牌隔离审计（加和性不变量：全部品牌视图每个数值系列==各品牌之和，按系列名配对），首跑即抓到真 bug：

①monthSettle 字典覆盖 bug：全部品牌视图下 amazon_settlement_monthly 每月多行（每品牌一行），payout_m={mon:v} 字典推导按键覆盖只留最后一行——月度结算图显示的是"每月某随机品牌的值"（7 月显示 onno 的 -40，真实三品牌之和 44,500）。修=按月累加；实测全部视图 [5889,44500,1185,-934] 与逐品牌求和精确吻合。②fees 字典键碰撞（键仅 order_id，跨品牌同单号会串费用）：键改 (brand, order_id)。③Noon 墙"最新数据日24小时订单"改按品牌分系列（此前全部品牌视图 zf+onno 混一条序列）。

隔离审计已固化进 dashboard_audit（178+ 项）：排除三类语义不可加项（比率/均值系列名、Top-N/份额/下钻/最新日、按实体聚合图），其余系列全部断言加和；此前另修 noon_orders 并入 2h 增量（"最新数据日"曾是残月：源 75 件 vs SaaS 7 件，卡在每日 04:30 同步点）。

费用滞后两层补抓上线：周日 45d 深窗兜底 + 报警触发定向重拉 生产四门全过

背景（用户拍板"2个都上"）：费用滞后分两种——发布滞后（Amazon 结算 2-4 周后才 POST 事件，3 天滚动窗自然追到，占缺失 ~95%）与窗口漏抓（采集器停摆>3 天则事件永久漏掉；成熟周残缺 2-5% 中 Shipped 单是真漏抓嫌疑）。zf/fg finances 原本无任何深窗回补（仅 noon 有周日 30d）。

两层补抓：①兜底深窗——每周日 03:20 collection_finances_deep 对 zf/fg 各拉 45 天窗（覆盖完整结算周期+余量），UPSERT 幂等（键=order+sku+posted_date）零副作用，页上限按天放缩（45d→135 页/区防 2000 事件截断）；②报警触发定向重拉——fee_coverage_alarm 检出成熟周低于线时 enqueue fee_backfill_targeted（窗口=报警周龄+7 天，不阻塞报警任务），次日覆盖率重算，回升自动消警、未回升升级人工。采集器 WINDOW_DAYS 参数化（--days，run.py 透传模式补 main() 入口）。

全链路实测：enqueue→worker→采集器 --days 3→23 事件 upsert→rc=0 返回；SaaS 侧 04:30 daily 全量 upsert 自动带出。onno 不需要（onno-finances 本就是全量适配器）。

费用滞后复核规范上线：度量+铃铛+每日报警+门禁四件套 生产四门全过

规范（用户问"费用滞后怎么及时补全"）：①度量——metrics.fee_coverage_rows 口径唯一实现，品牌×下单周费用覆盖率，近 12 周滚动；②目标线按实测曲线校准（结算批量 2-4 周龄到达：5%→66%→91%→95%+）：≥21 天 40% / ≥35 天 90% / ≥50 天 95%，20 单以下的周不算（噪音）；③铃铛新增 fee_lag 计数（与管道断更同款 fail-open）；④worker 每日 06:20 fee_coverage_alarm——成熟周低于线 → owner 邮件（best-effort）+stderr，覆盖率回升自动消警；⑤门禁兜底——dashboard_audit 新增成熟周断言（≥35 天且 ≥20 单的周覆盖 ≥90% 否则 FAIL，178+ 项）。

复核节奏：近窗（<21 天）滞后=正常不报；21-35 天低覆盖=观察；连续报警（邮件措辞已注明）=向采集侧发需求单重拉 finances。当前实测全部达标（报警静默、fee_lag=0），KPI 覆盖脚注与铃铛/报警/门禁四者同源。

费用覆盖率脚注 + 全卡状态断言（用户实锤"佣金尾程还是0"） 生产四门全过

用户截图实锤近窗口佣金/尾程为 0——数据实证：费用行随结算滞后到达（近 2 周订单覆盖 0-5%、一周前 28%），近 7 天窗佣金尾程必然 0，30 天窗也只 44% 覆盖。此前对账只能证明"显示=SQL"（一致性），证明不了"数据到齐没到齐"（完备性）——判断标准漏了覆盖率维度；状态扫也只断言第一张卡非零。

修复：①_kpi_deck 计算窗口费用覆盖率，佣金/尾程/费用/利润/利润率/TACOS 六卡在覆盖<100% 时自动挂"费用覆盖X%(结算滞后未到,利润偏高)"脚注；②ad_spend=0 且有订单时挂"无投放或广告数据未到"；③e2e 状态扫升级为全卡断言：每状态×每张 KPI 卡，0/空值必须带解释脚注否则 FAIL（升级后当场又抓出 onno 广告裸零卡，已补脚注）。截图

遗留公开项：移动端 / 页仍有 518px 横向溢出（宽表无横向滚动容器，ChartGrid 网格已修 44px 档）；费用滞后本身属源头结算节奏，需求单已挂。

全量六层覆盖体系 + merged-kpi day 空 500 修复（40 状态组合扫抓到） 生产四门全过

背景（用户令"所有页面所有功能最细颗粒度全量"）：把"全量"从页面级降到元素级，定义六层覆盖矩阵（元素/渲染/值/交互/口径/边界），并立即执行第 1、2、4 层全量：

元素清单（32 路由逐页枚举）：517 卡 / 443 图 / 45 表 1,385 行 / 1,465 按钮 / 297 tab / 38 下拉 / 158 输入框 / 956 链接——空表无空态 0、破图 0、API≥400 0、导航失败 0。

40 状态组合扫（平台×品牌×时间窗）抓到并已修：/api/dashboard/merged-kpi?mode=day 空 500（下架视图端点仍被切换瞬态调用；空日期进 BETWEEN 使 date 解析炸）——修=空日期回退近30天，实测 200。fg×Noon 组合无平台 tab 属正确行为（fg 无 Noon 业务）。状态扫已固化为 e2e 节 18（valid-state 感知，0 异常才过）。

门禁三连升级：KPI 全池对账 + 注释门 + 像素空白扫描（白名单制） 生产全过

背景（用户质问"审计为什么没查出来"的三类盲区）：①19 张 KPI 卡从未全量对过账（audit_nodes 只挂 9 个值基准）；②注释存在性（desc/foot/hint）从未有检查；③"有轴无数据"的伪装空白图骗过所有容器数/canvas 数断言。且补扫两品牌墙后修正全貌：已知空白共 23 张（zf AMZ 墙 2 + fg 墙 3 + onno 墙 14 + zf Noon 墙 4），全部为数据形态缺口——onno 排名 0 行、shipped_date 0/560、退款源头止于 05-15、摊销列结构性零值、zf 无 noon 日广告源。

落地：①dashboard_audit 增 kpi_pool_reconcile()——19 卡×{全部/amazon/noon} 独立 SQL 按 desc 公式重算 vs kpi-cards API（57 项）+ annotation_checks() 注释门（desc/foot 非空 ×3 平台 + 81 图墙与 Noon 墙 hint 全覆盖），106+ → 172+ 项；②frontend_e2e 增节 17 像素空白扫描——11 个图表页 canvas 彩色像素占比检测，23 张已知空白入 BLANK_ALLOW 白名单（附原因），白名单外新空白 = FAIL；检测器经合成 canvas 自证（空白被抓/彩色不误报）。AGENTS.md 门描述同步。

门写门验：本次门代码自身被拦两次（o. 双前缀 SQL 错、units30 映射错）——与历史上"门两次拒绝写错的基准"同款，基准双实现互检对作者同样生效。

退货卡口径修复 + Noon 墙 32 图 hint 补全 + 6 张无数据图根因定案 生产四门全过

① 退货/退款卡改代码（用户拍板）：原纯 Amazon 平台恒 0——AMZ 分支查了 _refunds 却丢弃。现按 desc 口径：AMZ 平台=AMZ 近窗口退款件，全部=AMZ+Noon，脚注分别标注来源。对账 57/57 保持全吻合（当前 90 天 AMZ 退款真值恰为 0，源头最后一条退款单 05-15）。

② Noon 主看板 hint 22→32 全覆盖：每张图题下现在都有口径注释（数据源表+公式，如"CIR 率=当日 CIR 件÷当日总件"、"每日广告花费=noon_ads_daily 日级(仅 onno 有源)"）。截图。

③ 6 张无数据图根因：退款图=源头断供（refund_count 最后写入 05-15，挂源头核实）；摊销图=结构性零值（无费用事件订单的 other_fees_usd 全 NULL，222 口径本地无数据）；zf 的 Noon 广告 ×4=数据在月度不在日级（pl_monthly 33 个月 $59.4 万 vs noon_ads_daily 仅 onno 有行）——日级源缺失挂采集需求单，图上加占位说明待拍板。

Noon 主看板 4 张广告图恒空修复（ads_d 重复 fetchall 覆盖）+ KPI 全池公式对账 生产四门全过

KPI 公式全量对账（应用户问"所有 KPI 公式都对吗"）：19 卡 × 3 平台变体独立 SQL 重算 vs API 逐卡对比——57/57 全部吻合（营收/销量/订单/利润/佣金/尾程/费用倒算/各比率逐分对上）。发现一处 desc 与实现不符：退货/退款卡纯 Amazon 平台恒 0（代码查了 AMZ 退款数但丢弃，desc 却写"Amazon 退款件数+Noon 退款件数"，脚注还显示"Noon 口径"）——待拍板改代码还是改文案。

空白图表像素级扫描（彩色像素占比识别"有轴无数据"伪装空白）：抓到 Noon 主看板 4 张广告图（每日花费/CTR/CVR/CPS）无论品牌窗口恒空——根因 brandboard.py 的 ads_d = cur.fetchall() 连写两遍，第二遍取空覆盖真数据。修复后 onno 72 天真曲线恢复（截图）。剩余 6 张空白均为真无数据非 bug：Noon 墙 zf 品牌无日广告源 ×4（zf 广告走月度口径）、AMZ 墙分国家退款/摊销 ×2（90 天 refund=0；摊销列 222 口径下恒 0）——建议加占位说明卡（待拍板）。

注释完整性：KPI 卡 19×3 平台 foot 口径注释全覆盖 ✅；主墙 81 图 hint 全覆盖且 UI 渲染 ✅；Noon 墙 32 图仅 10 张有 hint（22 张缺）——待补。检查工具：本次对账/扫描脚本可复跑（/tmp/kpi_reconcile.py 思路入 changelog 存档说明）。

e2e 门堵漏：响应状态码断言（platform=noon 500 溜门案的根治） 生产e2e 全过

为什么 kpi-cards 500 能过四门：frontend_e2e 原来只监听 request 记 URL 不看响应状态——切 Noon 平台 500 时 KPI 卡残留 Amazon 旧值（非零），"请求已发出 + 值非零"两条断言照样 PASS；响应监听又注册在交互段之后。

堵法（4 处）：①失败响应监听提到页面创建时全程生效（/api/ ≥400 全记）；②节 3b 加"kpi-cards platform=noon 无 ≥400"回归锚；③节 1-5 工作台交互全程无 ≥400 汇总断言；④全页面遍历逐页归因 API 失败。监听机制已用必然 404 路径自证可捕获；全量 e2e 跑两遍 ALL PASS。

全链路质量审计（34 路由×tab 全遍历）+ 工作台 Noon KPI 500 修复 生产四门全过

审计范围：DOM 层 34 路由全遍历（NaN/undefined/null/原始字段码/图表渲染/console 错误，269 张截图存档 screenshots/audit-2026-09-16/）+ DB 层（全库唯一索引键 NULL 扫描/无唯一索引表纯重复/新鲜度/跨品牌同单号）+ API 层（audit_nodes 106 端点 2905 数值节点、16 基准）。

抓到并已修的真 bug：工作台切 Noon 平台时 /api/dashboard/kpi-cards 500——_kpi_deck 的 fees_monthly 只在 Amazon 分支赋值、vals 字典无条件引用（UnboundLocalError），为本日早些时候 onno 费用重构引入的回归。修复=初始化外提到平台分支前；实测 noon 平台 200，值合理（3,852 单/$64.6k，fees30 倒算=rev−profit−adsp 精确吻合）。回归门覆盖缺口已记：e2e/audit_nodes 从未以 platform=noon 调 kpi-cards。

其余结论：全站 0 NaN/undefined/字段码暴露、0 导航失败；全库唯一索引键 0 NULL、0 纯重复；已知源头问题维持登记态（onno 广告双表止于 08-31 手动更新、跨品牌同单号 2 对、fg 8 月 Pending 209/860 残余）。裸 /dashboard 为死路由（无 UI 入口，零影响）。/today Noon 表格视图、/ads 表格月度稀疏 0、promotion 测评站域名表均甄别为设计如此/真实数据。

sku_mapping 630 行克隆根治：ON CONFLICT NULL 失配修复 + 存量清理 生产四门全过

重复数据扫描收尾（上一条挂账的"630 行要清吗"）——挖出根因不是误导入，是 ingest 冲突键失配：14 个 Noon SKU 在 222 源表 country 为 NULL，而 PostgreSQL 唯一索引与 ON CONFLICT (brand,sku,platform,country) 对 NULL 不判重（NULL≠NULL），每日 04:30 全量同步每天给这 14 个 SKU 各插一份纯克隆，累计 46 份/组（约 8 月初起）。另 53 组"×2 重复"经查是 AE+SA 两国各一行的合法映射，不是重复。

三层修复：①ingest222._MAP_FULL 冲突键列 coalesce(platform/country,'')（空串可被索引判重）；②映射编辑器 /api/mapping/edit 同病同修（空值曾转 NULL 插入）；③存量单事务清理：按键去重删 630 行（ZFH24BEX000ME 保留 cost_rmb=15.00 版本）+ 14 行存活行 country 规范化为 ''，1763→1133 行，0 重复 0 NULL。

防复发实测：走真实 ingest 通道单跑 sku_mapping 全量源（1132 行）upsert 后 行数零变化（修复前每天净增 14 行）——克隆机制已死。映射页自检：总行 1,133 = Amazon 1,013 + Noon 120，与库内一致。桌面 · 移动

onno 佣金/尾程全链路修复：order_fees 真源 + promo 口径修正 生产四门全过

用户三连实锤"佣金尾程不对/好多国家还是0/你自己不检查吗"——根因三层：①_kpi_deck 佣金/尾程从 amazon_orders 的 NULL 列算（onno 采集没抓订单级财务，列全空）；②我上一轮"回退 finance_monthly"只在无国家筛选时生效，选国家就 0；③order_fees 的 promo 列把 zf 源表的 promo_rebates（负值=亚马逊返利）abs() 成费用，利润多扣 $2,122。

修复：①_kpi_deck 佣金/尾程改走 order_fees 真源（经 amazon_orders JOIN 获国家/日期/品牌过滤，订单级、国家维度有值）；②onno 两个 order_fees 分支 promo 口径改 0（与 finance_monthly promo_usd=0、fg 同款一致）；③audit_nodes 基准 SQL 同步 order_fees 口径。实测 onno：佣金 $274 / 尾程 $1,230 / 费用 $1,524 / 利润 $1,996（此前利润 -$126 虚低 / 更早 $3,940 虚高）；GB 佣金 $25/尾程 $49、AU 佣金 $12——各国家费用全部有真值。

截图自检：桌面·onno 费用最终版

onno 订单双计根治：幽灵行清理 + items 全字段补齐 + 防复发对账删除 生产四门全过

用户实锤"onno 数据混了 zipforce"→ 深挖出三层问题：

①双计根治：onno 近 30 天订单虚高一倍（394 vs 真实 194）——历史上游把 zf 卖家账号的西欧单（ES/FR/GB/IT 等）brand 误标 onno，SaaS 摄入后上游改正为 zipforce，upsert 只增不删留幽灵行。清理：删 SaaS 中不在 mercury 权威视图（v_onno_orders_unified）的 onno 行 347 条 + 删 zipforce 侧冗余行 252 条（同号双品牌各一行、营收完全相同的冗余）。②items 全字段补齐：onno 订单 sku_list 曾全空（采集 8-31 才上线、ingest 只读一张 items 表）——ingest 改为 UNION 双表（onno_amazon 自有市场 + zipforce_amazon 西欧七国），并写一次性回填脚本（/opt/collection/tools/backfill_onno_items.py，252 单 SP-API 全字段补齐，FK 按源表归属路由）。③防复发：ingest_all 全量摄入后加对账删除（删 SaaS 中源头已不存在的 (brand, amazon_order_id) 行）+ zf 分支排除 brand='onno' 行（v_order_master 无 brand 列，EXISTS 排除）。

最终口径（30 天）：onno 344 单 / $5,577 / SKU 覆盖 344/344（100%）；zipforce 396 单 / $3,792；品牌间同号残留 2 单（mercury 源头 zf+fg 两表各有的真实边缘案例，$44 影响挂源头需求单）。onno 看板 SKU 图表组全部点亮（此前为空）。

截图自检：桌面·onno 去重后看板

四维矩阵补品牌过滤（用户实锤"sku chart 有 zipforce 产品"） 生产门全过

根因：/api/matrix/{data,charts,dimensions} 三个端点从未接受 brand 参数（SQL 全品牌 CROSS JOIN），MatrixSection 收了 brand prop 也没传——顶栏选 onno，四维矩阵的 SKU 列/图表照样是全品牌（zipforce 占多数）。修复：三端点加 brand 过滤（空=全部），前端 fetch 带 brand 且随品牌切换重查。实测 onno：SKU 分布只剩 onno:11、趋势品牌只剩 onno、表格品牌列纯 onno ✔。

关联发现（诚实交代）：onno 的 amazon_orders 392/392 条 sku_list 全空（采集侧缺 items 明细）→ 主看板的 SKU 图表组对 onno 为空、Country/SKU 表显示"(无SKU)"——这是源头数据缺口（需采集侧补订单 items），SaaS 不硬造。映射表 sku_mapping 本身存在且 onno 有映射（平台区块 top_skus 正常列出 onno SKU 即证明）。顺手修 brandboard_country_sku 因上轮批量替换误加 country 引用导致的 500。

onno 平台费缺失修复 + 佣金/尾程进默认卡组 生产门全过

用户实锤"onno 没有平台费"：根因——onno 的 amazon_orders 费用列全 NULL（0/392 有佣金/FBA，zf/fg 100% 有），导致费用卡=0 且利润虚高（未扣平台费 $3,940 vs 实际 $3,368）。onno 费用存在于 finance_monthly（结算口径）。修复：_kpi_deck 订单级费用缺失时回退 finance_monthly 月度费用（窗口月份对齐，同 Noon 月度逻辑；脚注标注"平台费按月度财务"；选了国家过滤时不回退、如实显示缺失）。默认卡组并入佣金、尾程（替换 tacos/units30 位）。

平台费构成（口径说明同步）：佣金 + 尾程FBA + 促销 + 其他平台费（广告另算）。实测 onno：佣金 $122 / 尾程 $450 / 费用 $572 / 利润 $3,368 = 5997−572−2057，与 finance_monthly 逐分对账一致。

截图自检：桌面·onno 费用修复后

KPI「ⓘ 口径说明」上线：19 卡计算方式进产品 生产e2e 全过

应用户确认，把逐卡核算的口径表放进产品：KPI 概览标题旁「ⓘ 口径说明」按钮，展开完整计算方式表（收入与利润 7 项 / 平台费用 2 项 / 广告 5 项 / 订单状态 5 项，含公式与数据源）+ 三条口径边界（Noon 金额按月对齐非日切 / 订单含全状态 / Cancelled 单件混合）。此前每卡仅有悬停一句话提示。

截图自检：桌面·口径面板展开 · 手机·同

KPI 卡组按用户要求合并（非二选一）并置于图表上方 生产门全过

用户纠正上一轮去重方向："kpi 是合并，不是 2 选 1，而且要放到 chart 上面"。落地：①指标池合并——看板五卡独有的四个指标并入 KpiDeck 池（近30天订单/近30天费用(营收−利润−广告倒算)/客单价/取消率，池 15→19 项，任何卡位可换选）；②默认卡组=两套并集（订单/营收/利润/费用/利润率/客单价/广告花费/ACOS/TACOS/销量）；③布局修正——KPI 概览卡从看板下方(1.8 万像素深处)移到图表墙上方（此前集成看板时插错了顺序）。实测：合并卡组 10 张数值齐全，KPI y=172 < 图 y=773 ✔。

截图自检：桌面·合并KPI在图表上方

工作台 KPI 卡片去重：只留一套 生产e2e 全过

用户问"为什么有 2 套 KPI 卡片"——历史叠加：KPI 概览卡（自研，10 卡可换指标+账号记忆）与主看板内嵌自带的 UVPVP 固定五卡重复。处理：工作台保留 KpiDeck 一套（跟随品牌/平台/国家/时间全部筛选器）；看板自带五卡在内嵌模式隐藏（/dashboard 全屏页保留），Noon 板的 FBN 库存预警卡独有信息保留。

截图自检：桌面·单套KPI

API 接入入口上线：租户自管平台 API 与服务商凭据 生产四门全过

应用户需求"新账号要添加自己的平台 API，需要设置入口，包括货代等服务商"。新页面 /settings「API 接入」（侧边栏·账户组，仅 owner/admin 可见）：两个 tab——🔌 平台 API（Amazon SP-API 三区 token / Amazon Ads / Noon 合作伙伴）与 🚚 服务商（货代/物流 + 其他第三方），目录驱动的动态表单。

安全设计：Fernet(AES128-CBC+HMAC) 加密落库（密钥由 GLOBAL_SECRET 派生）；明文提交即丢弃——任何接口只回掩码（如 yw-key…3456），编辑=整包重录不预填；变更全程只追加审计（触发器拦截改删）；SP-API 凭据支持一键 LWA 连通验证（真换 access token）。实测：录入→掩码列表→明文零泄露检查通过→删除清理。

阶段边界（如实）：v1 为"管理+验证"闭环；凭据自动接入采集管线（替代 /opt/collection/secrets 服务端文件，采集侧按 tenant_credentials 优先、文件兜底）为下一期。

截图自检：桌面·凭据列表 · 手机·同

主看板国家选择器联动修复 生产四门全过

用户报"检查切换国家功能"→ 实测坐实历史同款坑：KPI 概览卡与平台区块跟随国家（US $2,517 / ES $4,005 / 全部 $32,435 变化正常），但 Amazon/Noon 主看板完全忽略国家选择器（BrandBoard 请求硬编码 country=""，页面上排头的 KPI 卡正是看板自己的，造成"切国家数字不变"的观感——与记忆中"_units 派生查询漏 cf 过滤"为同类病灶）。

修复：BrandBoard/NoonBoard 接受 country prop（请求参数 + 缓存键第四维）；/api/brandboard/noon 三表（orders/pl_monthly/ads_daily）与 /api/brandboard/orders 增加 country 过滤；charts 端点 cf 过滤本就现成。实测：全部国家 546 单 → 切 US 看板 2 单（2026-09-02→09-07），与 DB 交叉验证一致（zipforce US 30 天=1 有效+1 取消）。e2e 增加"主看板请求带 country=US"契约。

截图自检：桌面·切US后看板跟随

图表墙 API 精确 from/to 日区间（自定义区间不再近似） 生产四门全过

应用户拍板"肯定能做就做"。四个端点加 frm/to（YYYY-MM-DD，同时提供时覆盖 days 拖尾窗）：/api/dashboard/charts（订单基准 BETWEEN + 小时表 BETWEEN，81 图全部自动跟随）、/api/brandboard/{orders,country-sku}、/api/brandboard/noon（日表 + 月表 mon BETWEEN 对齐）。前端看板缓存键升级为 天数|from|to（同天数不同区间不再撞缓存），内嵌提示行显示精确区间。

对齐实测（8 月整月）：KPI 582 = 看板 582 单（2026-08-01 → 2026-08-31）✅ 双视口一致；旧拖尾近似为 567/08-17 起的偏差消除。e2e 新增三条契约断言（看板 frm/to 请求、KPI date 区间请求、看板窗口标签）。预设档（7/30/60/90/全部）行为不变。

截图自检：桌面·自定义8月精确区间 · 手机·同

工作台统一时间选择器：7/30/60/90/全部 + 自定义 from/to 生产e2e 全过

应用户要求"看板和 KPI 用 7/30/60/90/全部 + from/to"。工具栏时间选择器重做：7天/30天/60天/90天/全部 预设 + 自定义日期区间，一个选择器同时驱动 KPI 概览卡、平台区块（内部统一映射 period=day&date..date2）与 Amazon/Noon 主看板（days 受控 prop，内嵌时看板自己的时间窗按钮隐藏，全屏页保留）。KPI 卡标签随窗口自适应（"30天营收"/"90天营收"…）。

对齐实测：默认 30 天 KPI 546 = 看板 546（08-18→09-15）；切 7 天 42 = 42（09-10→09-15）；切 90 天 1,643 = 1,643（06-19→09-15）✅。已知边界（如实标注）：自定义区间时 KPI 为精确日区间，图表墙按"区间天数拖尾窗"近似（如 8/1~8/31 → 08-17→09-15），看板窗口行有提示文案——精确日区间需图表墙 API 扩展 from/to（81 图深改，待排期）。顺带清理：旧"日粒度不适用 Noon"提示卡删除（noon 日窗口实测有数）、月/年下拉移除。

截图自检：桌面·30天默认 · 桌面·90天 · 桌面·自定义8月 · 手机·30天

「全部平台」合并视图下架（临时禁用） 生产e2e 全过

用户反馈"全部平台数据不好用，先 disable 不显示"。平台选择器移除「全部平台」，工作台默认直接进 Amazon 视图（KPI 概览卡 + Amazon 主看板），Noon 按需切换。MergedOverview 组件与 /api/dashboard/merged-kpi 端点代码全部保留（复活只需恢复按钮与默认值，合并口径已通过四品牌交叉对账：all=AMZ+Noon ✅）。e2e 品牌联动断言回到 kpi-cards 契约。

截图自检：桌面·默认Amazon视图 · 手机·默认Amazon视图（双视口确认无"全部平台"残留、看板与KPI正常渲染）

合并 KPI 日级窗口 C+ 方案落地 生产门全过

用户选定 C+：近30天/按日时金额卡主值保持 "—"（忠于所选窗口，不冒充），脚注展示最新完整月合计参考（如"2026-08合计 $92,453 · 此窗口金额不可加"）。实现：merged-kpi 日级响应附 ref{month, all}（最新完整月聚合，月度聚合抽为 _merged_month_agg 共用函数）；订单/件数仍为日级真合并（4,545 = AMZ 1,857 + Noon 2,688）。未采 A(单侧AMZ数=回潮"粘")/B(窗口错位) 的理由已与用户对齐。

上线实况截图(2026-09-16 存档)： 桌面·月模式 · 桌面·近30天(C+参考值脚注) · 手机·月模式 · 手机·近30天

合并 KPI 接入时间选择器（四窗口模式） 生产四门全过

应用户指出"卡片没有时间选择器"：/api/dashboard/merged-kpi 增加 mode/date/date2，工作台时间选择器（近30天/日/月/年）直接驱动合并卡——

· 月/年窗口：金额+订单全量合并（区间聚合，脚注仍是两平台拆分）；默认打开=月模式·最新共同完整月（8月：5,079 单 / $92,453 营收）。视图默认规则：全部平台=月（金额可合并），平台页=近30天；用户手动选过则尊重选择。
· 近30天/按日窗口：订单与件数日级真合并（AMZ 订单≠Canceled + Noon distinct order_nr/件级行，实测 4,543 = 1,855+2,688）；金额两端返回 null 显示"—"（Noon 无日级金额源，硬加=误导），脚注引导切月/年看金额。
· 排障：合并视图此前误收"筛选器自动兜底月"（当月残月 2026-09），改为只传用户显式选择，空则端点回退最新完整月。

全部平台合并 KPI 修正：真正等于两平台之和（单位统一 USD） 生产四门全过

用户实锤：上一版合并视图实际只算了 Amazon——full.matrix 仅含 finance_monthly（Noon 行是 API 层另组数组，从未进 matrix）。修正：新端点 /api/dashboard/merged-kpi（audit_nodes 104 端点）取最新共同完整月（排除当月残月），AMZ（finance_monthly 结算口径 + 广告/回款运行时并集，与 /api/finance/full 同源同列）+ Noon（pl_monthly settlement 折USD 锚定汇率 + 对账单回款 abs 口径）逐项相加；工作台合并卡每张脚注展示平台拆分（如 "AMZ $42,017 + Noon $50,436"），卡片自身即可对账"全部=平台之和"。实测 8 月：订单 2,063+3,016=5,079，营收 $42,017+$50,436=$92,453，净利 $24,648+$30,531=$55,179。口径不同的取消率/ACOS 仍显示 "—"。Noon 回款月度对账单滞后（8 月未出→0，脚注注明）。

排障记录：finance_monthly 实际列名 commission_usd/fba_usd/promo_usd 且无 ad/payout 列（full 是运行时并集）；noon 结算列名 settlement 非 net；noon_statement payouts 需 abs（与 full 一致）。e2e 品牌联动断言改验 merged-kpi。

工作台「全部平台」改为数据合并视图 生产e2e 全过

应用户指令"全部平台不可硬把不同平台的页面粘在一起，要合数据"：全部平台视图 = 合并 KPI + 四维矩阵 + 平台入口——6 张合并卡（订单/营收/净利/费用/回款按 finance_monthly 最新完整月跨平台同源加总：AMZ USD + Noon 折USD；净利率由加总值派生；取消率/ACOS 因跨平台口径不同显示"—"）；两个主看板、KPI 概览卡、平台区块全部退到各自的平台页（Amazon/Noon 平台页按钮一键直达）。选定具体平台时视图与之前完全一致。顺带解决了此前挂账的"全部平台≈Amazon"观感问题。

e2e 前端契约同步：品牌联动断言改验 /api/finance/full?brand=；国家/时间联动移到平台页内验证（全部平台视图按设计不消费这两个筛选）。

选品情报台移除四维矩阵 tab 生产e2e 全过

应用户要求移除。背景：9-12 独立 /matrix 页撤掉时 MatrixSection 被散装塞进三处（工作台卡/财务底部/选品tab），选品这份无业务必然性且与情报台市场研究气质不符。移除后主 tab 为 选品情报台/数据探索/监控池/决策台；四维矩阵保留两处——财务页底部（用户指令位置）与工作台卡片。

页面合并：上传并入 Listing 生产e2e+pen 全过

应用户要求，/upload（📁 文件 + 📄 A+ 内容）并入 /listings：Listing 页 tab 变为 任务 / 工作台 / 导出回流 / 模板库 / 📁 文件 / 📄 A+ 内容 六个。文件与 A+ 组件原样搬迁（upload/FilesTab.tsx 抽出 + AplusTab 复用，零逻辑改动）；/upload 路由 308 重定向到 /listings（老链接/收藏不受影响）；侧边栏移除"上传"入口（Listing 一个入口收口内容生产）。e2e 第 16 节 A+ 断言同步改址。

Listing 期2b：类目属性批量预取 + AI 对官方字段填写闭环 生产四门全过

应用户要求"把每个类目的属性拉下来以便 AI 填写"——此前只有按需拉取（绑定时），本批完成全量预取与对接：

①批量预取（tools/prefetch_pt_meta.py，幂等可重跑）：453 个产品 → 品名 PT 搜索 → 428 条产品→类目建议入新表 listing_pt_suggest(pg-init/50)，13 个唯一类目的官方 schema 全量入 listing_category_meta（如 SECURITY_CAMERA 168 字段 / BRA 135 字段 / POTABLE_WATER_FILTER 123 字段，均含必填标记与枚举）。②建任务自动带 PT：Amazon 任务创建即查建议表自动绑定 product_type。③AI 对官方字段填写：_task_schema 统一四处（详情/生成/编辑/批准）——绑定 PT 后规则+AI 全部对官方 schema 工作；实测文胸产品：规格书 9 条 → AI 映射 9 项到官方字段（fabric_type/bra_cup_coverage/bra_design/care_instructions，"34B"被拆为 band=34 + cup=B）+ AI 英文标题五点。

排障记录：spapi zf 市场 token_region 大小写笔误（31 产品报错后修正重跑 0 错）；RLS 下批量脚本需 SET app.tenant_id。真推（PUT listingsItems）仍待用户拍板单 SKU 实测。

Listing 期2上线：SP-API 类目元数据 + 直推管线 生产四门全过

11 步流程的 ③⑨⑩⑪ 步落地（Amazon 侧）：①新模块 api/spapi.py——LWA 换 token、PT Definitions 搜索/Schema（schema.link 实为 {resource:预签名S3URL} 对象，已实测修正）、Listings Items put/get；品牌独立 decodo 代理 + 出口 IP 断言（采集铁律同款，10 分钟缓存）；凭据直读 /collection/secrets/（fg_amazon.json / zf_lwa/ / onno_amazon_creds.md），零复制零新密钥。②新表 listing_category_meta（pg-init/49，官方属性元数据缓存 7 天；坑：表+序列都要 GRANT portal_app）。③四个新端点：pt-markets（品牌市场表，采集器同源）/ pt-search / pt-schema / bind-pt（绑定后工作台属性编辑器自动切换为 168 个官方字段，含必填标记与枚举下拉）；submit（dry_run 预检 + 真推 putListingsItem → 回写状态/ASIN/报错）。④状态机扩展 submitting/submitted/failed。

实测链路：建任务→规则生成→PT 搜索(light bulb security camera→SECURITY_CAMERA)→绑定(168 字段/6 必填)→approve→dry_run 预检精准报缺 brand/country_of_origin/supplier_declared_dg_hz_regulation。audit_nodes 快照 100→103 端点。

挂账：真实推送（PUT listingsItems）已实现未实推——等用户指定首个 SKU 补齐必填后拍板单点实测；Noon 直推为期3。

Listing 期2 前置调研：凭据总账 + SP-API 只读实测通过 调研·无生产改动

为 11 步 Listing 流程的期2（类目元数据 API + 平台直推）完成凭据与出口盘点。本页只记位置与 IP，凭据内容永不落此页。

① 平台 × 品牌 × 凭据 × 出口 IP 总账（权威源 /opt/collection/TOPOLOGY.md，出口 IP 今日逐项实测一致 ✅）：

出口铁律在运行：run.py 每次采集前 assert_exit_ip 断言，漂移即拒采+报警；端口映射 10001/04→fg、10002/05→onno、10003/06→zf。

② SP-API 只读实测（fg 凭据，纯 GET）：LWA 换 token ✅ 200 → Product Type Definitions 搜索 ✅ 200（"security camera light bulb"→SECURITY_CAMERA）→ PT Schema ✅ 200（schema.link+propertyGroups）。期2 第3步（类目元数据拉取）可行性确认；Listing 写入 scope 待期2 实施时单 SKU 受控验证。

③ 项羽(mercury /opt/six-codex Codex 机器人)：profile 单 provider(scienceedu/gpt-5.6-sol)，余额不足(INSUFFICIENT_BALANCE)不可用，需充值或经批准改指其他 LLM 端点。

Listing 期1：AI 抽取/映射/生成上线 生产四门全过

11 步目标流程的 4/5/6 步 AI 化（规则打底、LLM 兜底，任一失败静默回退纯规则）：①规格书上传后规则命中不足时 LLM 补抽 KV（条目标 ai:true）；②生成时 LLM 把规格值映射到未填类目属性（带枚举的属性强制从枚举选，gen_meta.attr_sources 记 ai:map）；③LLM 生成英文标题+五条卖点（20~200/3~6 条校验通过才采纳）。gen_meta.engine=rules-v1+ai-v1，工作台显示"AI映射 N 项 · AI标题 · AI五点"来源标识。generate 加 ?ai=0 纯规则秒回通道（pen_tests 回归走此路径）。实测 onno 摄像头灯泡产品 9 秒出 AI 标题+五点，质量达标。紧急开关 LISTING_AI=0。AI 调用计入 aiusage 额度。

挂账：期2（类目元数据 API + SP-API 直推）与期3（Noon API）待凭据——mercury 上的 Codex 机器人"项羽"因模型账户余额不足(INSUFFICIENT_BALANCE)未能回答凭据问题，需充值后再问。

主看板去按钮化：看板常驻直出 生产e2e 全过

应用户要求（截图圈选"这几个按钮都不要"），移除工作台全部看板控制按钮：「📊 Amazon/Noon 主看板 ▲ 收起」两个开关、「全屏打开 →」×2、「收起 ▲」×2。现在两个主看板常驻直出，无任何外壳开关；品牌选"全部"时仅保留品牌快切小签（ZipForce/Fittingirls/ONNO 与 ZipForce/ONNO）。实测 0 按钮残留、137 canvas 正常渲染、手机视口验证通过。

挂账待决：用户指出"全部平台 ≈ Amazon 平台"观感问题——实测语义正确（全部=双平台分算都显示），但 Amazon 内容（81 图看板）全在页面前部，Noon 内容被推到十余屏之后。三个方案待拍板：A 按平台分组重排（节标题吸顶）/ B 仅在 Noon 内容起点加分隔标题 / C 不动。

UVPVP 预览站彻底下线 基础设施

应用户要求移除 preview.zipforcehub.com：删除 compose web-preview 服务与容器、Caddyfile 显式站点块（重启网关后该域名 TLS 握手即被拒——按需签发 ask 门不放行非租户域）、web-preview/ 源码目录、镜像。UVPVP 绿色主题两件套（globals.css + 顶部 tab 外壳 AppShell.tsx）已随整目录归档至 backups/code-2026-09-15/web-preview-decommissioned.tar.gz（127 文件），将来要上该主题可直接取回。生产 zipforce.zipforcehub.com 全程无感（验证 200）。

Noon 主看板同步集成进工作台 生产e2e 全过

与 Amazon 主看板同法：Noon 品牌看板主体抽为 components/NoonBoard.tsx（5 区块 32 图 + FBN 库存预警卡 + 数据审计说明卡），路由页 /dashboard/noon/[brand] 变薄壳。工作台工具栏新增「📊 Noon 主看板 ▼」展开按钮（选 Noon 平台或全部平台时可见），品牌快切支持 ZipForce / ONNO；默认展开（同 Amazon 看板，用户拍板落地即见）。实测内嵌 32 图 + FBN 卡与独立页逐项一致。

本变更日志页上线 基础设施

应用户要求建立全站改动台账：/audit/changelog.html（静态直出，主域与租户子域均可访问）。约定：每次生产/预览改动上线后在此页顶部追加条目（环境/验证/回滚锚点三要素），与 backups/code-<日期>/ 快照目录互为印证。

品牌主看板集成进工作台（去链接化） 生产e2e 全过

应用户要求，工作台的「📊 品牌主看板 →」跳转链接改为页内展开式区块：点击按钮就地展开完整看板（8 区块 81 图 + KPI 条 + 订单/Country-SKU 表格），默认展开（初版默认折叠被用户否决：集成=落地即见），按钮可收起。顶栏品牌切换自动跟随；"全部品牌"时提供 ZipForce/Fittingirls/ONNO 快切。实现：看板主体从 /dashboard/[brand]/page.tsx 抽为共享组件 components/BrandBoard.tsx（独立全屏页保留为薄壳，ChartGrid 拖拽持久化 pageKey 不变）。顺带修正工作台四维矩阵卡过时的"64 组"文案。

选品「分析报告总结」对题修复 生产四门全过

问题：报告内容与搜索词无关——后端 /api/ai/sourcing 从未读取前端传的 country/term，把自营 SKU/财务数据交给 LLM 写"加码建议"，与选品情报台的搜索语境完全错位。

修复：带 {country, term} → 基于该词的 ABA 月度席位序列 + 上榜 ASIN Keepa 档案（与 explorer 同源同口径）生成竞争格局报告；无参数保留旧自营模式（向后兼容）。响应新增 term/country 字段供前端校验。

Keepa 真实历史曲线（按需拉取） 生产四门全过

新增 GET /api/sourcing/keepa-history：单 ASIN 按需拉 Keepa 原始时序（1 token/ASIN，Redis 缓存 24h，计入每日选品额度）。csv 索引经实测校验（1=New价 2=Used 3=BSR 4=List 16=评分 17=评论数；BuyBox 需更贵的 offers 参数暂未开）。前端 Keepa 子页新增「⚡ 拉取原始曲线」按钮，7 张历史图（New/Used/List/Amazon 价 · BSR · 评分 · 评论数）升级为真曲线（≤720 点 + 缩放滑块）。audit_nodes 快照 99→100 端点。

ABA 分席位份额曲线点亮 生产四门全过

本地 aba_search_terms 一直有 Top1/2/3 点击·转化份额六列（快照每天从 mercury 拉全列），但 explorer 组装 timeline 时只保留了 Top3 汇总、丢掉了分席位值，导致「Top1/2/3 点击/成交份额曲线」两张图长期"暂无数据"。补齐 6 字段（本地快照 + Dell 实时两条路径），曲线 12/12 月全量点亮。

选品页 Keepa 空白图分层治理 生产四门全过

根因：aba_keepa_full 是快照表（当前值 + 窗口聚合），无原始时间序列；39 张单 ASIN 图里的"历史曲线"只有 1~2 个点可画，大画布上孤点视觉等同空白。

处理：纯 line 且非空点 <3 的图不再画布，降级为「快照摘要卡」（显示可用当前值 + 说明）；真无数据的显示"无数据"；卡片标题栏注明快照近似边界。实测 13 张转摘要卡、9 张无数据、40 张真图保留。

品牌正名：fittinggoals → fittingirls（全库） 生产四门全过

SaaS 建库时把 fg 品牌写成了 fittinggoals（笔误；mercury 源库 schema 本为 fittingirls_amazon.*，UVPVP 页面 tab 亦为 Fittingirls）。一次性正名：21 张表 133,248 行 + tenant_brands/brands_source 注册表 + api 6 文件 + web 4 文件 + tools 5 文件；采集链路同步改名，次日定时任务直接写新名。改名前 pg_dump 全量备份。

广告页图墙：空窗自动回退 + 断更标注 生产四门全过

问题：Noon 广告与 onno-Amazon 数据止于 08-31（手动更新模式），切"近 7/14 天"整个图墙全空；symbol:"none" 使单点序列不可见；Amazon 的 ATC 恒 0 画空坐标。

修复：①当前窗口无数据时自动探测全量时段，有历史则自动切"全部"并黄条提示数据止点（用户手动选短窗口只提示不强切）②数据止于 3 天前挂「数据止于 MM-DD」徽标 ③点数稀少时显示数据点 ④Amazon ATC 图换占位说明。

UVPVP 主题预览站（骨架重做） 预览生产未动

preview.zipforcehub.com 上按 UVPVP 形态重做外壳：顶部 sticky 白头（品牌 logo + 绿点 + 用户区）+ pill tab 导航行（替换深色侧边栏）、内容区 1280→1600、图表两列→三列、卡片标题绿下边框、表头灰底、KPI 六列。生产 zipforce.zipforcehub.com 保持原版靛蓝。回滚镜像 tag：zipforce-saas-web:rollback-20260915-pre-uvpvp。

四维矩阵分析：tab → 财务页底部固定 生产四门全过

应用户要求，财务页「🔢 四维矩阵」tab 移除，整块固定为页面最后一个区块（口径脚注之下、不受 full 数据块加载影响）。顺带修三处：①维度组合已扩到全量（10,644 行），表格无分页曾把页面撑到 39 万像素高 → 客户端分页 20/页 + 受控全局排序；②默认收入降序（否则前几页全是 $0 空组合）；③死 Tailwind 类换 CSS 变量着色。已知留白：platform 维为 SQL 合成维度，同组合重复 4 行同值（动 API 需过口径门禁，挂账）。