Merge branch 'main' of https://gitea.shaguabijia.com/WonderableAI/shaguabijia-app-server into feat/client-applog-ingest

# Conflicts:
#	.env.example
#	docs/api/README.md

docs/api/ad/ad-pangle-callback.md

@@ -15,7 +15,15 @@ GroMore 以 GET 回调,关键参数:
 | `trans_id` | string | 交易号（**幂等键** + **唯一参与签名的字段**） |
 | `reward_name` | string | 奖励名（广告位配置,入库备注） |
 | `ecpm` | string\|null | GroMore 回调携带的 eCPM。普通激励视频优先用它计算金币 |
-| `extra` / `gromoreExtra` / `gromore_extra` | string | 客户端透传 JSON。支持 `ad_session_id`、`reward_scene`;`reward_scene=signin_boost` 表示签到膨胀 |
+| `extra` / `gromoreExtra` / `gromore_extra` | string | 客户端透传 JSON。支持 `ad_session_id`、`reward_scene`、`srv_env`、`boost_round_id` |
+
+### `extra` 里的 `boost_round_id`
+
+客户端生成的「这条广告属于哪一轮膨胀」标签(32 位十六进制,同 `ad_session_id` 格式),随发奖记录存进 `ad_reward_record.boost_round_id`。
+
+**它不参与任何发奖判定** —— 发多少、发不发完全不受影响,只是让 [`/ad/reward-result`](./ad-reward-result.md) 能把同一轮的 granted 记录求和成 `round_coin`(客户端「恭喜累计获得奖励」弹窗显示的数)。
+
+轮次边界由客户端定(只有它知道用户点没点「放弃赚钱」):点「去膨胀」新生成一个 → 点「继续看视频膨胀」复用同一个 → 点「放弃赚钱」/ ✕ / 返回 / 到每日上限 / 跨天 则丢弃。不带此字段(老客户端 / GroMore 偶发丢 extra)时存 NULL,`round_coin` 返 `null`。
 | `mediation_rit` | string | 代码位 ID（GroMore 带,目前仅入 raw 备查） |
 | `prime_rit` | string | 广告位 ID（同上） |
 | `adn_name` | string | 实际出广告的 ADN 名（同上,可用于收益分析） |
@@ -40,6 +48,6 @@ GroMore 以 GET 回调,关键参数:
 **发奖唯一可信入口**:验签 → 取 `user_id`/`extra` → 按 `reward_scene` 分流 → 幂等处理（按 `trans_id` 去重）。客户端不直接发奖,被破解也刷不到钱。
 
 - `reward_scene=reward_video` 或缺省:普通激励视频。金币按 `eCPM / 1000 * eCPM因子 * 当日次数因子 * 10000` 计算;若回调没有 `ecpm`,会按 `extra.ad_session_id` 查客户端 `/ad/ecpm-report` 的上报值;两边都没有 eCPM 时不发币,记录 `status=ecpm_missing`。
-- `reward_scene=signin_boost`:签到膨胀。要求用户当天已签到且不是 Day14;看完视频固定发 `2000` 金币,写 `signin_boost_record` 与 `coin_transaction.biz_type=signin_boost`。
+- ~~`reward_scene=signin_boost`~~(签到膨胀):**2026-07 已下线**。它按固定 3000 金币发、与广告实际收益脱钩,产品确认非设计内口径。签到弹窗的「看广告膨胀」现与福利页看视频同走 `reward_video`。现在传 `signin_boost` 会落到「未知场景」分支(不发币,`status=unknown_scene`)。
 - 未知 `reward_scene`:不发币,记录 `status=unknown_scene`,返回 `is_verify=false/reason=1`。
 - 验签过但参数缺/坏或 user 不存在 → 不发（`is_verify=false` + `reason`）;granted / capped / ecpm_missing / 业务不满足已记录 → `is_verify=true` + `reason=0`。

docs/api/ad/ad-reward-result.md

@@ -0,0 +1,66 @@
+# GET /api/v1/ad/reward-result/{ad_session_id} — 查本次广告的权威发奖结果 + 本轮累计
+
+客户端看完激励视频后轮询本接口，拿**本次实发金币**和**本轮累计**用于「恭喜累计获得奖励」弹窗。不再用余额差 / `coin_per_ad` 估算。
+
+**纯只读**：发奖仍只由验签过的 S2S 回调完成，本接口不写库、不产生任何奖励。按 `user_id` 收窄，被刷也只能查到自己的记录。
+
+## 鉴权
+
+需要 Bearer token。
+
+## 路径参数
+
+| 参数 | 类型 | 约束 | 说明 |
+|---|---|---:|---|
+| `ad_session_id` | string | 长度 8~64 | 本次广告会话 id，客户端生成，与 `mediaExtra` / `ecpm-report` 同值 |
+
+## 响应
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| `ad_session_id` | string | 回显请求值 |
+| `status` | string | `pending`(S2S 未到账，继续轮询) / `granted` / `capped`(当日超限) / `ecpm_missing` / `closed_early`(提前关闭) |
+| `coin` | int \| null | **本条**实发金币。granted 为真实到账额；未发奖的状态为 0；pending 为 `null` |
+| `round_coin` | int \| null | **本轮累计已发金币**(含本条) ← 弹窗显示的就是它 |
+
+```json
+{ "ad_session_id": "3f2a9c1b7e4d8a60", "status": "granted", "coin": 20, "round_coin": 60 }
+```
+
+### `round_coin` 的口径
+
+「轮」= 用户点「去膨胀」到点「放弃赚钱」之间连看的若干条广告，边界由客户端的 `boost_round_id` 定（见 [ad-pangle-callback](./ad-pangle-callback.md)）。
+
+```sql
+SELECT COALESCE(SUM(coin), 0) FROM ad_reward_record
+WHERE user_id = :user_id                        -- 恒带，轮 id 是客户端生成的不可跨用户信任
+  AND boost_round_id = :该会话记录的 boost_round_id
+  AND status = 'granted'
+```
+
+由服务端求和而非客户端自己累加：客户端进程被杀 / 低内存重建后本地累计会丢，发奖记录不会。
+
+**要守住的不变量：弹窗数字 == 本轮实际到账之和 == 用户看到的余额涨幅。** 三者对不上，用户就会认为少发了钱。
+
+| 情形 | `round_coin` |
+|---|---|
+| 本条 `granted` | 本轮累计（含本条） |
+| 本条 `capped` / `closed_early` / `ecpm_missing` | **仍返本轮累计**，该条按 0 计（撞上限那下的 toast 要能显示前几条的总额，不能是空） |
+| `status=pending`（没记录） | `null` —— 连属于哪一轮都不知道。**不是 0**，0 会被读成「本轮没赚到」 |
+| 该记录没有 `boost_round_id`（老客户端 / extra 丢失） | `null`，客户端退回只显示单条 `coin` |
+
+## 错误
+
+- `401`: 未登录
+- `422`: `ad_session_id` 长度不在 8~64
+
+**查不到记录不返 404**，而是 200 + `status="pending"`。404 只应表示路由不存在；两者混在一起客户端没法区分「后端没部署」和「再等等」。
+
+## 实现注意
+
+同一 `ad_session_id` 可能有多条记录，取值时**显式优先 `granted`**，不能只取最近一条：
+
+- 客户端先报 `closed_early`、S2S 随后姗姗来迟 → 两条，`granted` 反而是后写的
+- 本地联调重复调 `test-grant` → 同 session 多条 `granted`（`trans_id` 各不相同）
+
+都没有 `granted` 才取最近一条，让客户端知道没发的原因。

docs/api/ad/ad-test-grant.md

@@ -9,7 +9,8 @@
 
 | 字段 | 类型 | 必填 | 默认 | 说明 |
 |---|---|---|---|---|
-| `reward_scene` | string | 否 | `reward_video` | 模拟发奖场景。`reward_video`=普通激励视频；`signin_boost`=签到膨胀 |
+| `reward_scene` | string | 否 | `reward_video` | 模拟发奖场景。当前**只支持** `reward_video`；`signin_boost`（签到膨胀）已于 2026-07 下线，传它返 `422` |
+| `boost_round_id` | string | 否 | `null` | 本次广告属于哪一轮膨胀。正式链路走 S2S 的 `mediaExtra`，本接口不经 S2S 拿不到 extra，故由 body 补。**不传的话 debug 包 `/ad/reward-result` 的 `round_coin` 恒为 `null`**，「弹窗 40 → 60 → toast +60」那套累计验收在本地跑不起来 |
 | `ad_session_id` | string(8~64) \| null | 否 | null | 本次广告会话 id(与 [ecpm-report](./ad-ecpm-report.md) 同值)。**仅 `reward_video` 场景生效**:据此查回客户端已上报的真实 eCPM,走与正式发奖相同的公式发奖;查不到或 eCPM≤0(测试应用常返 0/假值)时兜底 200,保证本地联调仍出非零金币 |
 
 ## 出参
@@ -33,4 +34,4 @@
 
 `reward_scene=reward_video` 时按上面 `ad_session_id` 查回的真实 eCPM 走金币公式发奖(取不到兜底 200)——便于本地用 [admin 金币审计](./admin-ad-coin-audit.md) 核对「看广告→金币」是否按公式计算。
 
-`reward_scene=signin_boost` 时复用签到膨胀业务规则:必须当天已签到、非第 14 天、当天未膨胀过,成功后写入 `signin_boost` 金币流水。它让已登录客户端能自助发奖 = 绕过反作弊,**严禁在生产开启**。
+它让已登录客户端能自助发奖 = 绕过反作弊,**严禁在生产开启**。

docs/api/admin/ad/admin-ad-revenue-report.md

@@ -28,6 +28,8 @@
   | `user_id` | int | 全部 | 只看某用户;不传=所有用户 |
   | `ad_type` | string | 全部 | `reward_video` / `feed` / `draw`;不传=全部类型 |
   | `feed_scene` | string | 全部 | `comparison`(比价)/ `coupon`(领券)/ `welfare`(福利);**全局筛选**,同时作用于明细 / 合计 / `daily`·`hourly` 趋势;不传=全部场景 |
+  | `app_env` | string | 全部 | `prod`=正式应用 / `test`=测试应用;同时过滤客户端预估与穿山甲汇总 |
+  | `revenue_scope` | string | `all` | `business`=仅业务代码位,用于同口径对账 / `all`=应用全部代码位,包含广告测试等非业务曝光 |
   | `granularity` | string | `day` | `day`=按天 / `hour`=按小时(聚合键再加北京时间小时 0–23);**区间>1 天建议用 day** |
   | `limit` | int(1~1000) | 500 | **每页条数**(分页大小);`total`/`total_*`/`daily`/`hourly` 按全量统计不受分页影响 |
   | `offset` | int(≥0) | 0 | 分页偏移(已跳过条数)=(页码−1)×`limit` |
@@ -131,5 +133,5 @@
 - **历史 Draw 不可拆**:迁移(Draw→普通信息流)前,Draw 发奖混在 `ad_feed_reward_record` 且无类型标记,金币侧统一记 `feed`;迁移后 Draw 不再产生新数据。展示侧 `ad_type` 由客户端上报区分,故 `draw` 桶基本为空。
 - **来源字段从上线起齐全**:`app_env`/`our_code_id` 是本期新增列,历史记录为 NULL(报表来源列留空)。
 - **逐条/明细的收益是预估**:`items[].revenue_yuan` 基于客户端上报的 eCPM 折算,非穿山甲后台结算值。
-- **穿山甲后台收益(汇总/趋势级)**:`total_pangle_revenue_yuan`(预估 `revenue`)与 `total_pangle_api_revenue_yuan`(收益Api `api_revenue`,更接近结算)来自穿山甲 **GroMore 数据 API**(`integrations/pangle_report` + `scripts/sync_pangle_revenue` 按天 T+1 拉取入 [ad_pangle_daily_revenue](../database/ad_pangle_daily_revenue.md))。穿山甲**不提供分用户/设备/类型/场景维度**(官方明确),最细到 日期×应用×代码位,故只用于汇总与按天趋势的对照,**不挂到逐条事件行**;且仅在全量视图(未按 user/类型/场景过滤)展示。配置见 `.env` 的 `PANGLE_REPORT_*`。
+- **穿山甲后台收益(汇总/趋势级)**:`total_pangle_revenue_yuan`(预估 `revenue`)与 `total_pangle_api_revenue_yuan`(收益Api `api_revenue`,更接近结算)来自穿山甲 **GroMore 数据 API**(`integrations/pangle_report` + `scripts/sync_pangle_revenue` 按天 T+1 拉取入 [ad_pangle_daily_revenue](../database/ad_pangle_daily_revenue.md))。穿山甲**不提供分用户/设备/类型/场景维度**(官方明确),最细到 日期×应用×代码位,故只用于汇总与按天趋势的对照,**不挂到逐条事件行**;且仅在未按 user/类型/场景过滤时展示。`app_env` 与 `revenue_scope` 会同时过滤客户端和穿山甲数据，其中 `business` 排除广告测试等非业务代码位。配置见 `.env` 的 `PANGLE_REPORT_*`。
 - **对账聚合级 + 逐条下钻**:行级 `matched` 给出该组(用户×类型×应用×代码位)应发是否==实发;**展开 `records` 即可看该组逐条明细**(eCPM/因子1/份数/LT/因子2/应发/实发/一致)定位到具体记录。独立逐条审计接口 [admin-ad-coin-audit](./admin-ad-coin-audit.md) 仍保留(同一复算口径,可全局按场景/只看不符筛选)。

docs/api/admin/admin-audit-logs.md

@@ -1,6 +1,6 @@
 # GET /admin/api/audit-logs — 审计日志(谁改了什么,游标分页)
 
-> 所属:Admin·Audit 组（前缀 `/admin/api/audit-logs`） | 鉴权:Bearer admin_token（角色:任意已登录 admin） | [← 返回 API 索引](../README.md)
+> 所属:Admin·Audit 组（前缀 `/admin/api/audit-logs`） | 鉴权:Bearer admin_token + `audit-logs` 页面权限 | [← 返回 API 索引](../README.md)
 
 ## 入参（query）
 | 字段 | 类型 | 必填 | 默认 | 说明 |
@@ -29,7 +29,8 @@
 
 ## 错误码
 - `401` 未带 admin token / token 无效或过期 / 管理员被禁用
+- `403` 当前管理员没有 `audit-logs` 页面权限
 
 ## 说明
-- 整组(`/admin/api/audit-logs`)守卫为 `get_current_admin`,任意已登录 admin 均可查看,无角色限制。
+- 整组(`/admin/api/audit-logs`)守卫为 `require_page("audit-logs")`，默认仅超级管理员和技术角色可查看，也可由超管给自定义角色授权。
 - 审计日志只增不改不删,任何写操作经 `write_audit` 落一条。数据表见 [admin_audit_log](../database/admin_audit_log.md)。

docs/api/admin/admin-device-liveness.md

@@ -1,6 +1,6 @@
 # /admin/api/device-liveness — 设备存活监控(#80)
 
-> 所属:Admin 子应用(前缀 `/admin/api`) | 鉴权:admin | 表 [device_liveness](../../database/device_liveness.md) | [← 返回 API 索引](../README.md)
+> 所属:Admin 子应用(前缀 `/admin/api`) | 鉴权:admin + `device-liveness` 页面权限 | 表 [device_liveness](../../database/device_liveness.md) | [← 返回 API 索引](../README.md)
 
 无障碍保护存活的后台视角:哪些设备开过保护(`ever_protected`)、现在在线还是掉线(心跳超时,#107 起阈值 1 小时)、首次开启时间(`first_protected_at`)。
 
@@ -13,3 +13,4 @@
 
 ## 说明
 - 「在线」= `last_heartbeat_at` 距今 < 超时阈值;掉线召回链路(worker 置 `kill_alert_pending` → 客户端 pull)见表文档。
+- 无 `device-liveness` 页面权限时返回 `403`。

docs/api/admin/admin-event-logs.md

@@ -1,6 +1,6 @@
 # /admin/api/event-logs — 埋点日志(#83)
 
-> 所属:Admin 子应用(前缀 `/admin/api`) | 鉴权:admin | 表 [analytics_event](../../database/analytics_event.md) | [← 返回 API 索引](../README.md)
+> 所属:Admin 子应用(前缀 `/admin/api`) | 鉴权:admin + `event-logs` 页面权限 | 表 [analytics_event](../../database/analytics_event.md) | [← 返回 API 索引](../README.md)
 
 客户端埋点(`POST /api/v1/analytics/events` 批量上报)的后台检索页。
 
@@ -13,3 +13,4 @@
 ## 说明
 - 纯只读;无聚合报表(要分析导出后自己算)。
 - 时间轴用 `client_ts`(事件真实发生时刻),入库时间受客户端攒批影响。
+- 无 `event-logs` 页面权限时返回 `403`。

docs/api/admin/admin-stats-overview.md

@@ -37,8 +37,8 @@
 | `feed_ad_watch_count` | int | 信息流广告有效完成视频数(`ad_feed_reward_record.status=granted`) |
 | `signin_coin_total` | int | 签到累计发放金币(`biz_type=signin`) |
 | `signin_count` | int | 签到次数(`signin_record`) |
-| `signin_boost_coin_total` | int | 签到膨胀累计发放金币(`biz_type=signin_boost`) |
-| `signin_boost_watch_count` | int | 签到膨胀有效视频数(`signin_boost_record`) |
+| `signin_boost_coin_total` | int | **历史口径**:签到膨胀累计发放金币(`biz_type=signin_boost`)。功能已下线,数字不再增长,保留供对账 |
+| `signin_boost_watch_count` | int | **历史口径**:签到膨胀次数。膨胀 2026-07 已下线、`signin_boost_record` 表已 drop,改数 `coin_transaction.biz_type='signin_boost'` 的入账笔数(一次膨胀 = 一笔,与原口径等价),只会停在历史值不再增长 |
 
 **DashboardCash**
 | 字段 | 类型 | 说明 |

docs/api/compare/compare-records.md

@@ -10,6 +10,12 @@
 |---|---|---|---|---|
 | `limit` | int | ❌ | 20 | 1–100 |
 | `cursor` | int | ❌ | null | 上一页末条 `id`,首页不传 |
+| `ordered` | bool | ❌ | null | `true`=只出「已下单」(店名命中本人真实下单)的记录;不传=不筛 |
+| `keyword` | string | ❌ | null | 按店名 / 菜名模糊搜索,忽略大小写,≤64 字符;纯空白等同不传 |
+| `include_trace` | bool | ❌ | false | 客户端开了本机 agent 调试模式时带 `true`,放行**本人**记录的 `trace_url` |
+
+`ordered` / `keyword` 都在服务端过滤后再分页,客户端不要拿一页结果自己 filter ——
+分页之后一页里可能一条都不命中,列表会看着像空的。
 
 ## 出参
 响应 `200`：`{ items: ComparisonRecordOut[], next_cursor: int|null }`（分页见 [索引#游标分页约定](./README.md#游标分页约定)）
@@ -38,6 +44,9 @@
 | `items` | object[] | 下单菜品 `{name, qty, specs?}` |
 | `comparison_results` | object[] | 逐平台对比（price 单位元，已按 rank 升序） |
 | `skipped_dish_names` | string[] | 被跳过的菜名 |
+| `ordered` | bool | 「已下单」店级标记:店名命中本人 `source='compare'` 的下单记录即 `true`。**瞬态字段,不在表里**,每次查询现算 |
+| `ad_coins_earned` | int | 本次比价看信息流广告实发的金币(按 `trace_id` 聚合)。同为瞬态字段 |
+| `trace_url` | string \| null | pricebot 调试链接。未开 `debug_trace_enabled` 且未带 `include_trace=true` 时为 `null` |
 | `created_at` | datetime | 时间 |
 
 ## 错误

docs/api/meituan/meituan-feed.md

@@ -30,7 +30,8 @@
 ## 各 tab 行为
 - **`rec` 智能推荐**:走【离线库 `meituan_coupon`】筛佣金率 ≥ 3%,`DISTINCT ON(dedup_key)` 去重后按销量降序分页。**纯库查询、不打美团、不依赖 MT 凭证**。库为空(prod 刚部署 / ETL 未跑完)→ `empty`;库异常 → `degraded`。**不显示距离**(库里距离相对城市默认点,对用户无意义)。
   - 为何不实时:实测同城热销榜中位佣金 ~0.8%,筛佣金≥3% 后每页剩 0–1 条,既撞 402 又填不满,故从库出;库空时也**不回退实时**(回退同样填不满)。
-- **`distance` 距离最近**:外卖搜「外卖」+ 到店搜「美食」(均 `sortField=6`),两路并行顺序翻页,实时按你坐标算距离、由近及远。两路**都失败**且无结果 → `degraded`;否则有结果 `ok` / 无结果 `empty`。
+- **`distance` 距离最近**:外卖搜「外卖」+ 到店搜「美食」(均 `sortField=6`),两路并行翻页,实时按你坐标算距离、由近及远。两路**都失败**且无结果 → `degraded`;否则有结果 `ok` / 无结果 `empty`。
+  - 翻页成本:美团搜索只能靠 `searchId` 续页,本接口又是无状态的(客户端只传页码)。服务端把沿途 `searchId` 按「量化坐标(~1km)+平台+关键词」缓存 10 分钟(`utils/mt_search_cursor`),**稳态下每翻一页恒定 1 次上游请求**(改前是「取第 N 页 = 发 N 次」);缓存冷/过期才从最近的已知页往后重放。缓存是进程内的,多 worker 不共享 —— 只影响快慢,不影响结果。
 - **默认(空 tab)**:逐轮分页的混合 feed(2 外卖 + 1 到店交叉,写死 3 页:爆款 / 今日必推 / 精选+限时),第 4 页返空。两路榜单都失败 → `degraded`。
 
 ## 错误码

docs/api/meituan/meituan-top-sales.md

@@ -17,6 +17,7 @@
 
 ## 说明
 - 从 `meituan_coupon` 取 `sale_volume_num` 非空 **且 `city_id` = 反查城市** 的券(#116,同城销量榜),`DISTINCT ON(dedup_key)` 跨源去重(每个「品牌|名|价」只留销量最高一条,同销量再按佣金),按销量降序分页;每页只对当前 ~20 条做 `from_raw` 解析(翻页快,不全表拉取)。
+- 分页查询分两步(与 `rec` 共用 `_paged_dedup_ids`):**① 只在 `id + 排序键` 这几个小列上去重/排序/分页,② 再按 id 回表取本页 `raw`**。`raw` 是整条美团原始返回(JSONB,每行数 KB),让它参与排序会把整城数据推过 `work_mem`、落盘做外部归并,而且每翻一页都重来一遍 —— 这是此前「滑到底越来越慢」的主因之一。配套索引 `ix_meituan_coupon_city_dedup_sales` / `..._comm`(见 `alembic/versions/meituan_coupon_feed_indexes.py`)让 `DISTINCT ON` 顺着索引流式去重,免掉排序。
 - **不依赖 MT 凭证**(纯库查询)。库为空(prod 刚部署 / ETL 未跑完)→ `status=empty`;库查询异常 → `status=degraded`。均返 `200`、不抛 5xx。
 - **仅 PostgreSQL**(`DISTINCT ON` 为 PG 专用)。
 

docs/api/notifications.md

@@ -0,0 +1,132 @@
+# 消息通知中心(notifications 族)
+
+> 所属:notifications 组(前缀 `/api/v1/notifications`,源 `app/api/v1/notifications.py`) | 鉴权:**全部 Bearer**(消息按用户隔离) | [← 返回 API 索引](./README.md)
+>
+> 对应 PRD《消息通知中心》(通知类型清单 / 点击跳转 / 字段元素 / 未读红点 / Push 文案)。
+> Push 侧(厂商直推 + 测试)见 [push-vendor-test.md](./push-vendor-test.md)。
+>
+> **数据落库**:消息存 `notification` 表(`app/repositories/notification.py`,按用户隔离,`sentAt` 倒序)。业务事件统一走 `app/services/notification_events.py` 下发(站内消息 + 厂商 push 一条链路,业务事务 commit 后触发、失败只 log 不影响业务)。**已接入 6 类真实触发**:
+>
+> | type | 触发点 |
+> |---|---|
+> | `withdraw_success` | 提现单转账到账(免确认直达 / 查单归一化 / 对账兜底,`repositories/wallet.py`) |
+> | `withdraw_failed` | 提现退款收口 `_refund_withdraw`(微信侧失败、审核拒绝、解绑退回) |
+> | `feedback_reply` | admin 反馈审核「拒绝」(原因/留言用户可见,`admin/routers/feedback.py`) |
+> | `feedback_reward` | admin 反馈审核「采纳」发金币(必带官方留言) |
+> | `report_approved` | admin 上报更低价「通过」发金币(`admin/routers/price_report.py`) |
+> | `invite_order_reward` | 被邀请好友首次成功比价 → 邀请人发 2 元(`repositories/invite.try_reward_on_compare`) |
+>
+> 其余类型(奖励过期 ×2、权限异常 ×4、好友催单)业务侧尚未接入。要造联调数据,用 [POST /api/v1/push/test](./push-vendor-test.md) 的 `createNotification:true` 逐条插入。
+>
+> ⚠️ **字段命名**:本组接口(含 push 测试组)对外为 **camelCase**(`sentAt` / `isRead` / `pageSize`…),与库内其他 snake_case 接口不同——按 PRD 前端契约对接,勿混用。
+
+## 通知类型速查(13 种)
+
+列表**服务端已排好序:全列表按时间倒序**(最新在前,**不做分类分组**——PRD §1 的"按分类分组"为笔误,2026-07-14 需求方确认取消),前端按返回顺序渲染即可。category 仅用于卡片头部的分类标签展示。
+
+| category | 分类标签 | type | 类型 | cardStyle 版式 | actionText 操作行 | extra 里带什么 |
+|---|---|---|---|---|---|---|
+| withdraw_assistant | 提现助手 | `reward_expiring` | 金币现金奖励即将失效 | dual_amount 双金额卡 | 立即激活您的收益 | `batchId` |
+| withdraw_assistant | 提现助手 | `reward_expired` | 金币现金奖励已失效 | dual_amount 双金额卡 | 立即赚取新收益 | — |
+| withdraw_assistant | 提现助手 | `withdraw_success` | 提现成功 | withdraw 提现卡 | **null(无操作行,点击仅消红点)** | — |
+| withdraw_assistant | 提现助手 | `withdraw_failed` | 提现失败,款项已退回 | withdraw 提现卡 | 重新提现 | `withdrawId` |
+| system | 系统通知 | `perm_accessibility` | 比价功能异常(无障碍) | plain_text 纯文本卡 | 去开启 | `permission:"accessibility"` |
+| system | 系统通知 | `perm_battery` | 比价续航保护异常(省电策略) | plain_text 纯文本卡 | 去开启 | `permission:"battery"` |
+| system | 系统通知 | `perm_autostart` | 比价启动保护异常(自启动) | plain_text 纯文本卡 | 去开启 | `permission:"autostart"` |
+| system | 系统通知 | `perm_overlay` | 比价按钮异常(悬浮窗) | plain_text 纯文本卡 | 去开启 | `permission:"overlay"` |
+| feedback | 我的反馈 | `feedback_reply` | 官方回复 | plain_text 纯文本卡 | 查看详情 | `feedbackId` |
+| feedback | 我的反馈 | `feedback_reward` | 反馈奖励(必带官方留言行) | coin_reward 金币奖励卡 | 查看反馈详情 | `feedbackId` |
+| report | 我的爆料 | `report_approved` | 爆料审核通过 | coin_reward 金币奖励卡 | 查看爆料详情 | `reportId` |
+| invite | 好友邀请 | `invite_order_reward` | 好友下单奖励到账 | friend_cash 好友现金卡 | 邀请更多好友赚现金 | `inviteeNickname` |
+| invite | 好友邀请 | `invite_remind` | 好友催单提醒 | plain_text 纯文本卡 | 去提醒 TA | `inviteeNickname`, `scrollTo:"remind"` |
+
+点击跳转逻辑按 PRD §2 由客户端按 `type` 分发;点击目标 = 整张卡片(不区分主体和操作行),任何点击都先调 `POST /read` 消该条红点。
+
+## GET /api/v1/notifications — 消息列表(分页)
+
+**入参(query)**
+
+| 参数 | 类型 | 必填 | 说明 |
+|---|---|---|---|
+| `page` | int | ❌ | 页码,1 起,默认 1 |
+| `pageSize` | int | ❌ | 每页条数,默认 20,最大 100 |
+
+**出参**
+
+```jsonc
+{
+  "items": [
+    {
+      "id": 90001,
+      "category": "withdraw_assistant",   // 分类 key(5 种,见上表)
+      "categoryLabel": "提现助手",         // 卡片头部左上角分类标签
+      "type": "reward_expiring",          // 类型 key(13 种,决定点击行为)
+      "cardStyle": "dual_amount",         // 版式:dual_amount/withdraw/plain_text/coin_reward/friend_cash
+      "title": "金币现金奖励即将失效",      // 卡片标题
+      "coins": 86,                        // 金币数,整数;无金币的版式为 null
+      "cashCents": 1280,                  // 现金金额(分);无现金的版式为 null
+      "cashYuan": "12.80",                // 现金展示串(元,两位小数),与 cashCents 同源
+      "infoRows": [                       // 信息行,已按 PRD 拼好文案,逐行 label: value 渲染
+        { "label": "过期说明", "value": "您有86金币和12.80元现金即将失效，完成一次一键领券或一键比价即可激活收益" },
+        { "label": "过期时间", "value": "3天后失效" }
+      ],
+      "actionText": "立即激活您的收益",    // 操作行;null = 无操作行(提现成功卡)
+      "extra": { "batchId": "batch_20260714" },  // 跳转/联动参数,按 type 取用(见上表)
+      "sentAt": "2026-07-14T14:59:58+08:00",     // ISO8601 带时区
+      "isRead": false                     // false → 分类标签右侧显示 6px 红点(#E53935)
+    }
+  ],
+  "page": 1,
+  "pageSize": 20,
+  "total": 16,
+  "hasMore": false,
+  "unreadCount": 12    // 与 /unread-count 同口径,进页面可顺手刷角标
+}
+```
+
+**时间显示规则(前端处理 `sentAt`)**:今天 →「今天」;昨天 →「昨天」;当年 →「M月D日」(不补零);跨年 →「YYYY年M月D日」。`sentAt` 恒带 +08:00(服务端已归一,与库底层用 SQLite/PostgreSQL 无关)。
+
+**数值约束(PRD §3)**:金币整数不带小数;现金/提现金额两位小数(直接用 `cashYuan`)。
+
+## GET /api/v1/notifications/unread-count — 未读总数(首页铃铛角标)
+
+无入参。**出参**:
+
+```jsonc
+{ "count": 12, "badgeText": "12" }   // count>99 时 badgeText="99+";count=0 时 badgeText=null → 整个角标隐藏
+```
+
+刷新时机(PRD §4):进入首页时、从通知中心/其他页面返回首页时(原型监听 `pageshow`)。
+
+## POST /api/v1/notifications/read — 标记已读
+
+**入参(JSON),两种模式二选一(同时传时 `all` 优先)**
+
+| 模式 | body | 使用场景 |
+|---|---|---|
+| 单条/多条 | `{ "ids": [90001, 90003] }` | ① 点击某张消息卡片(点击后无论跳转/弹窗/无动作都算已读);② 用户点击 push 直达落地页后,客户端拿 push extras 里的 `notificationId` 同步置读 |
+| 全量清零 | `{ "all": true }` | 进入通知中心自动清零(只浏览列表就消红点,无需逐条点击;退出通知中心时也可再调一次兜底) |
+
+**出参**
+
+```jsonc
+{ "ok": true, "markedCount": 2, "unreadCount": 10 }   // unreadCount = 处理后剩余未读,可直接刷新角标
+```
+
+幂等:不存在/已读的 id 忽略,重复调用 `markedCount=0` 不报错。
+
+**错误**:`400` ids 与 all 都没传(或 ids 为空数组);`401` 未鉴权。
+
+## 联调小抄
+
+```bash
+# 1. 登录拿 token(SMS mock:任意手机号 + 任意 6 位验证码)
+curl -X POST :8770/api/v1/auth/sms/send  -d '{"phone":"13800001234"}'
+curl -X POST :8770/api/v1/auth/sms/login -d '{"phone":"13800001234","code":"123456"}'
+# 2. 列表 / 角标 / 置读
+curl ":8770/api/v1/notifications?page=1&pageSize=20" -H "Authorization: Bearer $TOKEN"
+curl ":8770/api/v1/notifications/unread-count"        -H "Authorization: Bearer $TOKEN"
+curl -X POST ":8770/api/v1/notifications/read" -d '{"all":true}' -H "Authorization: Bearer $TOKEN"
+```
+
+列表初始为空,登录后先用 [POST /api/v1/push/test](./push-vendor-test.md) 的 `createNotification:true` 插几条(可指定 `type` 覆盖不同版式),再验列表 / 角标 / 置读全流程;它同时把 `notificationId` 放进 push extras,可闭环验证「push → 站内已读联动」。

docs/api/platform/platform-huawei-review.md

@@ -0,0 +1,36 @@
+# GET /api/v1/platform/huawei-review — 华为审核开关
+
+> 所属:Platform 组（前缀 `/api/v1/platform`） | 鉴权:无 | [← 返回 API 索引](../README.md)
+
+华为应用市场审核要求:新手引导的**「快速设置」权限步必须可被用户关闭**（引导视频页不在要求内）。本端点把运营后台配的开关下发给客户端,决定该步左上角是否出现退出按钮。
+
+**不鉴权**:引导页在登录之前就展示,此时客户端必然没有 token。
+
+值来自 `app_config` 表的 `huawei_review` 行（admin 页 `GET / PATCH /admin/api/huawei-review` 可改），空库回退 `default`。
+
+## 入参
+
+无。
+
+## 出参
+
+响应 `200`:`HuaweiReviewOut`
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| `mode` | string | `default`（强制展示,不可关闭 = 上线至今的现状）/ `review`（可关闭,过审用）。仅供排查时看后台切成了哪态 |
+| `onboarding_closable` | bool | 快速设置权限步是否允许用户退出（= `mode == "review"`）。**客户端只读这一个字段决策** |
+
+Mock 出参:
+```json
+{
+  "mode": "review",
+  "onboarding_closable": true
+}
+```
+
+## 说明
+- **只有华为 ROM 客户端会来拉**（HarmonyOS / EMUI；荣耀 MagicOS 不拉）。机型判断在客户端做（`OemDetector`），服务端不看 UA，也就不用维护机型名单。
+- 客户端在进新手引导前拉一次并本地缓存；请求失败/超时用上次缓存值，从未拉到过则按 `onboarding_closable=false`（宁可不给退出按钮，也不误放开）。
+- 脏值兜底:DB 里 `mode` 不在枚举内时服务端一律回退 `default`。
+- 切回 `default` 即可一键收回退出按钮（审核通过后无需发版）。

docs/api/push-vendor-test.md

@@ -0,0 +1,103 @@
+# 厂商推送测试三件套(push 族)
+
+> 所属:push 组(前缀 `/api/v1/push`,源 `app/api/v1/push.py`) | 鉴权:**全部 Bearer** | [← 返回 API 索引](./README.md)
+>
+> 发送实现:`app/integrations/vendor_push.py`(荣耀 / **华为** / 小米 / OPPO / vivo 五通道,
+> `send_notification()` 通用入口)。站内消息中心见 [notifications.md](./notifications.md)。
+> 与 `POST /api/v1/device/push-test`(无障碍召回通道延迟自测)互补:本组面向消息中心 13 类 push 的文案/参数/通道联调。
+>
+> 字段命名同 notifications 族:**camelCase**。
+
+## 链路总览
+
+```
+真实业务事件(提现回执/反馈审核/爆料通过/好友下单 已接入;奖励过期等待接)
+      └→ services/notification_events(先落 notification 表,再向该用户全部已注册设备直推)
+              └→ vendor_push.send_notification(vendor, token, title, body, extras)
+                      extras = { type, notificationId, ...业务参数 }  ← 客户端深链 + 已读联动的钥匙
+客户端点击 push → 按 extras.type 直达落地页(与站内点击一致)
+              → 调 POST /notifications/read {ids:[extras.notificationId]} 同步消红点(PRD §4)
+```
+
+推送目标来源:客户端集成各厂商 push SDK 拿到 regId/token 后,通过 `POST /api/v1/device/register` 上报 `push_vendor` + `push_token`,服务端存 `device_liveness` 表。
+
+## GET /api/v1/push/vendors — 厂商配置状态
+
+检查 5 家厂商服务端凭据是否配齐(只读 .env,不打厂商接口)。`missingKeys` 即还要补的配置键;mock 测试不依赖任何凭据。
+
+```jsonc
+{ "vendors": [
+    { "vendor": "honor",  "label": "荣耀", "configured": false, "missingKeys": ["HONOR_PUSH_APP_ID", "HONOR_PUSH_CLIENT_ID", "HONOR_PUSH_CLIENT_SECRET"] },
+    { "vendor": "huawei", "label": "华为", "configured": false, "missingKeys": ["HUAWEI_PUSH_APP_ID", "HUAWEI_PUSH_APP_SECRET"] },
+    { "vendor": "xiaomi", "label": "小米", "configured": true,  "missingKeys": [] },
+    { "vendor": "oppo",   "label": "OPPO", "configured": false, "missingKeys": ["OPPO_PUSH_APP_KEY", "OPPO_PUSH_MASTER_SECRET"] },
+    { "vendor": "vivo",   "label": "vivo", "configured": false, "missingKeys": ["VIVO_PUSH_APP_ID", "VIVO_PUSH_APP_KEY", "VIVO_PUSH_APP_SECRET"] }
+] }
+```
+
+## GET /api/v1/push/templates — 13 类通知的 push 模板预览
+
+PRD §5 的 13 条 push 文案(标题固定 ≤11 字不带变量;正文 `{var}` 为变量,示例值即 PRD 示例)。对文案、看变量名用。
+
+```jsonc
+{ "templates": [
+    {
+      "type": "withdraw_success",
+      "category": "withdraw_assistant", "categoryLabel": "提现助手", "cardStyle": "withdraw",
+      "pushTitle": "提现到账提醒",
+      "pushBodySample": "¥0.50已存入您的微信钱包，点击查看到账详情",   // 用示例值渲染后的效果
+      "pushBodyTemplate": "¥{amount}已存入您的微信钱包，点击查看到账详情",
+      "variables": ["amount"],
+      "sampleVars": { "amount": "0.50" }
+    }
+    // ... 共 13 条,顺序即 PRD 编号
+] }
+```
+
+## POST /api/v1/push/test — 测试发送(默认 mock)
+
+**入参(JSON)**
+
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|---|---|
+| `vendor` | string | ❌* | `honor/huawei/xiaomi/oppo/vivo`,中文「华为」「小米」等别名也识别;留空时用 `deviceId` 设备上报的 vendor |
+| `pushToken` | string | ❌* | 厂商 push token/regId;留空则按 `deviceId` 反查已注册设备(*mock 模式两者都缺时用占位 token,只看渲染结果*) |
+| `deviceId` | string | ❌ | 客户端 `DeviceId.get()` 的设备 id,用于反查 vendor+token |
+| `type` | string | ❌ | 13 种类型 key 之一 → 按 PRD 模板渲染;不传且没直给文案 → 发通用测试文案 |
+| `vars` | object | ❌ | 覆盖模板变量,如 `{"coins":"520","cash":"6.66"}`;缺省用 PRD 示例值 |
+| `title` / `content` | string | ❌ | 直接指定标题/正文(优先于 type 模板) |
+| `createNotification` | bool | ❌ | true = 同时往该用户消息中心插一条同类型未读 mock 通知,extras 带其 `notificationId` → 可闭环验证「点 push → 调 /notifications/read 消红点」(仅 type 合法时生效) |
+| `mock` | bool | ❌ | **默认 true = 不真调厂商 API**,回显渲染结果;false = 真发到手机(要求该厂商凭据已配) |
+
+**出参**
+
+```jsonc
+{
+  "ok": true, "mock": true, "vendor": "huawei",
+  "title": "反馈奖励已到账",
+  "body": "谢谢您帮傻瓜比价变得更好，300金币已到账，还有一条给您的留言～",
+  "extras": { "type": "feedback_reward", "feedbackId": "3002", "notificationId": "90017" },
+  "notificationId": 90017,          // createNotification=true 时的站内 mock 通知 id
+  "missingKeys": ["HUAWEI_PUSH_APP_ID", "HUAWEI_PUSH_APP_SECRET"],  // 真发前还缺的配置(真发成功时必为空)
+  "vendorResponse": null            // 真发时为厂商 API 原始响应
+}
+```
+
+**错误**:`400` vendor/type 非法、真发但凭据未配(detail 列缺失键);`409` 真发但拿不到 pushToken;`502` 厂商 API 返回失败(detail 带厂商原始错误)。
+
+**真发注意**:
+- 目标手机必须先装 App 且客户端已集成对应厂商 SDK、`/device/register` 上报过 token;
+- vivo 未上架前走测试推送(`VIVO_PUSH_MODE=1`),目标手机需在 vivo 开放平台加入测试设备;
+- 小米新设备需在开放平台把签名/包名配好,token 才有效。
+
+## 厂商凭据怎么拿(.env 键名)
+
+| 厂商 | 后台 | 需要的键 |
+|---|---|---|
+| 华为 | AGC 控制台 → 项目设置 → 常规 → 应用 | `HUAWEI_PUSH_APP_ID`、`HUAWEI_PUSH_APP_SECRET`(OAuth client_id 即 AppId) |
+| 荣耀 | 荣耀开发者服务平台 → 推送服务 | `HONOR_PUSH_APP_ID`、`HONOR_PUSH_CLIENT_ID`、`HONOR_PUSH_CLIENT_SECRET` |
+| 小米 | 开放平台 → 消息推送 → 应用秘钥 | `XIAOMI_PUSH_APP_SECRET`(服务端只要这个;AppID/AppKey 是客户端 SDK 用) |
+| OPPO | 开放平台 → 推送服务 | `OPPO_PUSH_APP_KEY`、`OPPO_PUSH_MASTER_SECRET`(注意是**服务端 MasterSecret**) |
+| vivo | 开放平台 → 推送 | `VIVO_PUSH_APP_ID`、`VIVO_PUSH_APP_KEY`、`VIVO_PUSH_APP_SECRET` |
+
+各家发送协议差异(鉴权方式/成功码/payload 结构)封装在 `integrations/vendor_push.py`,业务侧只面对 `send_notification()`。

docs/api/signin/signin-boost.md

@@ -1,33 +0,0 @@
-# POST /api/v1/signin/boost — 签到后看广告膨胀金币
-
-用户 Day1-Day13 当天已签到后，看完一条激励视频，由穿山甲 S2S 回调固定补发 2000 金币。本接口只用于 S2S 发奖后的确认。
-
-## 鉴权
-
-需要 Bearer token。
-
-## 请求体
-
-| 字段 | 类型 | 必填 | 说明 |
-|---|---|---:|---|
-| `ad_ref_id` | string | 是 | 穿山甲 S2S 回调的 `trans_id`。回调需先以 `extra.reward_scene=signin_boost` 完成发奖 |
-
-## 响应
-
-| 字段 | 类型 | 说明 |
-|---|---|---|
-| `coin_awarded` | int | 本次膨胀补发金币 |
-| `coin_balance` | int | 补发后的金币余额 |
-| `signin_date` | string | 被膨胀的签到日期，格式 `YYYY-MM-DD` |
-
-## 错误
-
-- `401`: 未登录
-- `409`: 缺少/无效广告回调记录，非本人广告，回调未发奖，当天未签到，Day14，或当天已经膨胀过
-
-## 数据写入
-
-- 本接口不直接发奖;实际写入发生在 `/ad/pangle-callback` 的 `reward_scene=signin_boost` 分支。
-- 回调写 `signin_boost_record` 新增一行，用 `(user_id, signin_date)` 唯一约束防重复。
-- 回调使 `coin_account` 增加固定 `2000` 金币。
-- 回调写入 `coin_transaction.biz_type=signin_boost`。