# 2026-11-02 规则调整（三条）

## 1. 四层改为并行，互不压制
原来「零成交（转化层）」会压制「成交未核销 / 核销率低（履约层）」—— 这是把四层当成漏斗了。
现在拆开：转化层、履约层各自独立判定；只有**履约层内部**保留根因去重
（成交未核销 → 核销率低，同一根因不报两条）。
文档和规则地图里的「互斥」表述同步改为「履约层内命中则不再判…」。

## 2. 隐藏「点亮后的投稿数」
`lit_posts` 实测只有 14 / 1413 家非零（合计 42 次），数据不可信。
它本来就没有在任何界面展示过；这次更进一步，**同步时不再向生意经请求该指标**
（`visible_checkin_item_cnt_1d`），少一列无用数据。

## 3. 上榜信息作为检测指标
数据实况：980 家「-」（未上榜）、433 家有内容（「入围XX榜」或「XX榜第N名」）。

新增两条 T 级规则（流量层）：
| ID | 判定 | 问题文案 |
|---|---|---|
| RANK0 | 上榜信息为空或「-」 | 未上榜（好评榜/人气榜均未进入） |
| RANK_IN | 有内容但没有「第 N 名」 | 仅入围未进榜：{榜} |

- `db.aggregate_period` 新增 `rank_note`（取最近一次有内容的）
- 接口 payload 增加 `rank`
- 表格新增「上榜」列：显示最好名次（绿色「第2名」）/「入围」/「—」
- 抽屉里显示完整榜单内容（金色左边框的提示块）
- 文案配置面板新增 4 个模板字段

### 当前命中（2026-11-02 周期，1413 家）
未上榜 980（69%）、仅入围 155（11%）、有点名次 278 家。
规则总数 15 → **17 条**，平均每家 7.24 个问题。

### 表格
新增「上榜」列后 14 列；收紧内边距与列宽后 1148px < 容器 1155px，无横向滚动条。

## 同步数据改为「弹窗确认」

### 原因
`同步数据` 一点就执行 —— 但这个操作会消耗平台配额、跑 3~9 分钟、还会弹出浏览器窗口，误点代价不小。

### 实现
点按钮先查 `/api/sync/status`：
- **有任务在跑** → 不发新请求，提示「同步正在进行中（21:23 开始），完成后会自动刷新」
- **空闲** → 弹出确认框

确认框内容：
| 项 | 值 |
|---|---|
| 统计窗口 | 2026-10-04 ~ 2026-11-02（前端按今天往前 29 天算） |
| 数据来源 | 抖音来客 · 生意经报表集市 |
| 预计耗时 | 3 ~ 8 分钟（平台排队时间不定） |
| 会消耗 | 1 次建任务配额（每天约 30 次） |
| 上次同步 | 2026-11-02 01:04 |

底部提示：同步期间会弹浏览器窗口、不影响继续使用工作台、每天 01:00 也会自动同步。
按钮：取消 / 开始同步；支持 Esc、点遮罩、× 关闭。

### 实测
- 直接调用 `showSyncDialog()` 渲染正常，字段与按钮齐全
- 点击按钮时因当时正有同步在跑，正确走了「进行中」提示分支（没有重复发起）
- 该次手动同步最终 21:23:10 → 21:32:06 成功，下载 294KB 并自动入库

### 备注
同步期间如果同时用 ego 浏览器做别的自动化，会和同步脚本抢浏览器，导致变慢。
这次手动同步用了 9 分钟（平时 3~5 分钟），期间我正好在用 ego 核对界面。

## 导入历史增加「导出」按钮

### 需求
「每一条历史导入数据后面加一个导出按钮，可以用于导出历史报表」

### 实现
- 每行历史记录右侧加【导出】按钮，点击下载该批次的检测清单
  `GET /api/export.csv?period=<批次周期>`
- 文件名自带周期：`门店检测清单_2026-11-02.csv`
- 若该批次的周期在当前数据库里已不存在（早期批次记录的是旧值 `2026-11`），按钮置灰，
  悬浮提示「该批次的数据已被后续导入覆盖，无法导出」
- 历史行的文件名改为单行省略号截断，右侧固定显示周期 + 时间 + 按钮

### 顺带修复
导出的 CSV 里有 153 个单元格带换行（来自动作文案里的 `\n`，如「1. 检查…⏎2.点亮…」），
Excel 打开会出现多行单元格。现在导出时把 `\r\n` 统一压成空格。

### 验证
- 点击第一个可用按钮 → 下载 `门店检测清单_2026-11-02.csv`，1414 行 × 16 列，含诊断结论/主因/全部问题/整改动作
- 2026-11 的两条历史记录按钮正确置灰
- 导出后 CSV 里不再有换行单元格

## 导出改为「纯门店数据」

### 需求
「导出就导出实际门店参考就好，不用计算问题诊断、原因和整改动作这些。这些内容在单家门店查询时展示即可」

### 改动
导出（左侧栏【导出数据】+ 导入历史每行的【导出】）不再包含诊断内容。

原来 16 列里有 4 列是诊断：`诊断结论 / 主因 / 全部问题 / 整改动作` —— 全部移除。

现在是 17 列纯指标：

```
门店ID, 门店名称, 城市, 评分, 访问次数, 成交券数, 核销券数, 核销率, 核销金额,
待核销券(估算), 商责退单率, 投诉率, 差评率, 评价回复率, 发布视频数, 门店点亮数, 上榜信息及排名
```

顺带调整：
- 文件名 `门店检测清单_<周期>.csv` → `门店数据_<周期>.csv`
- 左侧栏按钮 `导出清单` → `导出数据`
- 导出接口内部不再调用 `rules.fmt_tpl` 渲染文案，只输出数字

### 保持不变
筛选条件（KPI 卡 / 城市 / 问题类型 / 评分区间 / 搜索）仍然生效——
问题类型筛选需要先判定，所以内部还是会跑诊断，只是**结果不进导出文件**。

### 验证
2026-11-01 导出：1414 行 × 17 列，列名与内容均无诊断字段；
左侧栏按钮点击下载 `门店数据_2026-11-02.csv` 正常。

## 导出改为「原样返回导入的原始文件」

### 问题
用户指出导出的仍是加工数据。核对后发现：
1. 生意经原始文件有 **40 列**，我们库里只存了 23 列
2. 导出里混了 3 个计算列：核销率（核销券÷成交券）、待核销券（成交券−核销券）、差评率（中差评÷评价数）
3. 其中 **经营风险差评率是平台直接给的**，我们却自己算了一遍，数字可能对不上

### 方案（用户选择）
**导出 = 原样返回当时导入的文件**，不含任何计算列。

### 实现
- `batches` 表新增 `file_path`，记录原始文件在 `data/processed/` 下的文件名
- 收件箱导入：先算归档名 → 导入时写入批次 → 再移动文件
- 上传接口 `/api/import`：同样把原件保存一份到 `data/processed/`
- 老批次自动回填：用 `created_at` 的时间戳匹配 `processed/` 里的文件名前缀
  （如 `2026-11-02T21:32:14` ↔ `20261102_213214_门店数据_....xlsx`）
- 新接口：
  - `GET /api/batch/<id>/file` —— 指定批次的原始文件
  - `GET /api/export.file?period=` —— 该周期最近一次的原始文件
- 下载时文件名去掉时间戳前缀，恢复成 `门店数据_2026-10-04_2026-11-02.xlsx`
- 前端：左侧栏按钮改为【导出原始数据】，导入历史每行按钮改为【原始文件】；
  没有留存原件的批次（早期 Windows CSV）按钮置灰
- 移除不再使用的 `exportCsv()`；`/api/export.csv` 保留为「筛选结果 CSV」接口

### 验证
- `/api/batch/11/file` 下载得到 40 列 × 1428 行，与原始 xlsx 完全一致
- 左侧栏点击 → `门店数据_2026-10-04_2026-11-02.xlsx`
- 历史列表 8 条：5 条可下载，3 条（2026-10 的 CSV、一条重导入）置灰