257 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
exinglang	1bf45ed4f7	fix(migration): align guide video revision with main head	2026-07-29 15:37:59 +08:00
exinglang	6d15e4aa61	Merge remote-tracking branch 'origin/main' into fix-guideVideoFix	2026-07-29 15:32:11 +08:00
marco	4bd4e66678	重构比价结果页取数据逻辑 (#195) ... Reviewed-on: #195 0.5.4	2026-07-29 01:59:31 +08:00
linkeyu	90c6fe599a	修复：统一用户Draw信息流eCPM统计口径 (#190) ... ## 问题 业务收益详情的平均 Draw eCPM 仅平均成功发奖记录，会排除未发奖的真实展示，导致数值系统性偏高，且与广告收益页口径不一致。 ## 修复 - `feed_avg_ecpm` 改为从 `ad_ecpm_record` 的全部 `draw/feed` 实际展示计算 - 成功发奖、未发奖展示均纳入，每次展示等权 - 日期、正式/测试环境、业务代码位、领券/比价场景支持与广告收益页对齐 - 奖励份数仍基于成功发奖表，不混用展示数据源 - 复用广告收益报表的业务代码位集合 ## 线上数据复算 2026-07-25、正式业务、用户 #33： - 旧口径（只看成功发奖）：`29.9117 元/千次` - 新口径（333 次真实展示）：`19.9926 元/千次` - 新值与广告收益报表一致 ## 验证 - 新增成功/未发奖、场景、环境、业务代码位回归用例 - `tests/test_admin_read.py` + `tests/test_admin_ad_revenue_scope.py`：29 项全通过 - Ruff 改动文件检查通过 ## 上线顺序 本 PR 需先于管理后台配套 PR 上线。 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #190 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-28 17:58:23 +08:00
linkeyu	e529112a90	修复中途退出比价的 LLM 成本回填 (#191) ... ## 问题 比价记录进入中途退出后未触发 LLM 成本回填，周期补偿也未扫描 cancelled，导致实际已有 LLM 调用的记录长期显示成本、LLM、TOKEN 为空。 ## 修改 - finalize 落库后立即追加 LLM 成本回填 - 周期补偿范围加入 cancelled - 保持无有效调用和全调用失败记录不伪造成本 - 增加即时回填和周期补偿回归测试 ## 验证 - ruff 检查通过 - 相关测试 28 项通过 - 全仓 626 项通过；主干既有失败已在未修改的 origin/main 复现 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #191 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-28 17:57:52 +08:00
guke	50da718e35	比价记录失败卡展示具体原因(新增 fail_reason) (#189) ... 失败记录不再一律「网络开小差」:新增记录级 fail_reason 派生列——information 具体则直出,笼统则从 platform_results 救出业务原因(找不到店/菜、未起送、打烊、 单点不配送等),纯系统失败为 None → 端侧品牌兜底。store_closed/no_delivery 被 pricebot 漏成 status=failed 的按 reason 补判,打烊脏店名统一简短模板。接入 harvest_done 与灰度期 upsert_record 两条写路径。 - models: comparison_record.fail_reason 列 - repositories: _derive_fail_display + 补判/清洗 helper,两条写路径接入 - schemas: ComparisonRecordOut 暴露 fail_reason - alembic: 加列 + 回填老 specific 失败记录 - tests: _derive_fail_display 单测(8 例)+ harvest 失败落库集成测试 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #189	2026-07-28 14:04:36 +08:00
guke	ed76820e97	feat(sms): 短信验证码可切换多 provider(极光/阿里云/创蓝),默认极光零改动 (#188) ... 读完了两份 spec + 分派器,这分支的全貌清晰了。下面是可直接粘进 Gitea PR 的 MR 说明(标题 + 正文): 建议标题 feat(sms): 短信验证码可切换多 provider(极光/阿里云/创蓝),默认极光零改动 MR 正文(复制以下 markdown): ## 概述 把原单文件 `app/integrations/sms.py` 重构为**可切换 provider 包** `app/integrations/sms/`,在保留极光(默认、行为零改动)的基础上,新增两家验证码短信 provider: - **阿里云号码认证 dypns**(Mode A:阿里云生成/存储/校验验证码,核验免费) - **创蓝云智 253**(Mode B:本服务自管码,httpx 直连 + HMAC 签名) Provider 由 `SMS_PROVIDER` 按调用实时选择,默认 `jiguang`。短信=花钱 + 登录关键路径,故新 provider **opt-in、可灰度、秒级回退**,默认路径零变更。 ## 为什么 现有极光路径本地内存存码(多 worker 不共享,已是技术债),且单一供应商无法灰度/切换。引入 provider 抽象后:阿里云托管码可消除存码债,创蓝作为备选降低单点依赖,三家随配置切换与回退。 ## 改动内容 **架构(`app/integrations/sms/`)** | 文件 | 说明 | |---|---| | `__init__.py` | 对外仍暴露 `send_code/verify_code/SmsError`(auth 导入不变);按 `SMS_PROVIDER` **每次调用**分派;未知值回退 `jiguang` | | `base.py` | `SmsError`(status_code→HTTP) + provider 无关的 `mock_verify` | | `jiguang.py` | 原 `sms.py` 逻辑**原样迁入**,行为零改动(git 识别为 rename) | | `aliyun.py` | 新增,Mode A:`SendSmsVerifyCode` + `CheckSmsVerifyCode`,惰性加载 SDK | | `chuanglan.py` | 新增,Mode B:自管码 + `tpl/send` + HMAC 签名 | **两种验证码模式** - Mode A(阿里云):不本地存码,阿里云 `##code##` 托管生成+校验;本地仅留 per-phone 失败计数防爆破。 - Mode B(极光/创蓝):`secrets` 生成 N 位 → 进程内存 → 供应商只下发;本地一次性校验 + 失败 N 次作废。创蓝**复制**极光存码机器(不重构极光,零回归风险)。 **配置(`config.py` + `.env.example`)** - `SMS_PROVIDER = jiguang | aliyun | chuanglan`(默认 jiguang) - `ALIYUN_SMS_*`(AK/签名/模板/方案名/时长…) + `aliyun_sms_configured` 门控 - `CHUANGLAN_SMS_*`(账号/密码/模板/签名/endpoint…) + `chuanglan_sms_configured` 门控 - 复用现有 `SMS_MOCK / SMS_CODE_LENGTH / SMS_CODE_TTL_SEC / SMS_SEND_INTERVAL_SEC / SMS_MAX_VERIFY_ATTEMPTS` - 切到某 provider 却未配齐 → `send_code` 抛 `SmsError(503)`,不静默 **auth.py(最小改动)** - `verify_code` 现在可能抛 `SmsError`(阿里云降级 503)→ `sms_login`、`wechat_bind_phone_sms` 两处各包 `try/except SmsError → HTTPException`,与 `send_code` 现有写法一致。 **依赖** - `pyproject.toml` 增 `alibabacloud_dypnsapi20170525`(仅阿里云 provider 惰性 import;jiguang/chuanglan 不加载)。创蓝零新依赖(httpx + 标准库)。 **测试** - 新增 `test_sms_aliyun.py` / `test_sms_chuanglan.py`(均 monkeypatch 网络接缝,不发真短信) + `test_sms_dispatch.py`(分派/回退)。 - `test_auth.py` 相应更新。 - 现有测试走 `SMS_MOCK=true` 在分派层短路,不受影响。 **文档** - 设计 spec:`docs/superpowers/specs/2026-07-25-aliyun-sms-verify-design.md`、`2026-07-26-chuanglan-sms-verify-design.md` - 接口调研:`docs/integrations/aliyun/*`、`docs/integrations/chuanglan/tpl-send.md`、`docs/integrations/sms.md` ## 兼容性 & 回退 - **默认 `SMS_PROVIDER=jiguang`,线上行为与现状完全一致**;不改极光逻辑、不动 API 层频控与测试账号短路。 - 切阿里云/创蓝仅改环境变量,出问题秒切回极光;未知 `SMS_PROVIDER` 一律回退极光,防误配打挂登录。 --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #188	2026-07-28 09:20:57 +08:00
guke	f05dd1cf74	docs(applog): 客户端运行日志批量上报→落文件→SLS 采集 设计(spec) (#187) ... Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #187 0.5.2 0.5.3	2026-07-27 18:00:23 +08:00
linkeyu	b5962464e8	为比价记录补充是否下单状态 (#184) ... ## 改动说明 - 后台比价记录列表与详情增加 ordered 字段 - 按当前页批量查询真实下单记录，避免逐行查询 - 判定口径与 C 端一致：同一用户、同一店铺且 source=compare - demo 数据不计为真实下单 - 增加列表和详情接口回归测试 ## 验证 - tests/test_admin_read.py：19 项通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #184 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 17:33:09 +08:00
linkeyu	36ce18a250	修复比价记录机型与 ROM 版本展示 (#183) ... ## 改动说明 - 比价记录列表和详情接口补充可读机型名 - 列表接口返回 ROM 大版本 - 保留原始设备编码，方便排查 - 增加列表与详情接口回归测试 ## 验证 - 后端测试：20 项通过 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #183 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 16:38:56 +08:00
linkeyu	58d609e5d2	修复提现审核汇总按来源和状态统计 (#185) ... ## 问题 邀请提现页的汇总接口未按提现来源过滤，导致页签数字、顶部“待审核/待审核金额”与邀请提现细则不一致；同时接口缺少已到账、已拒绝和全部的历史总数。 ## 改动 - 汇总接口支持并校验 `source=coin_cash|invite_cash` - 页签数量及顶部待审核数量、金额统一按提现来源过滤 - 增加 `success_count`、`rejected_count` 和 `total_count` - 保留今日到账/拒绝指标，并同步按来源过滤 - 增加逐来源、逐状态校验“汇总数 = 列表 total”的回归测试 - 增加“顶部待审核金额 = 当前来源待审核细则金额之和”的回归测试 ## 验证 - 提现审核专项测试通过 - 后台读取接口测试：19 项通过 - Ruff（排除主干既有规则告警）通过 - 线上数据库只读复核：其他提现与邀请提现的待审核数量、金额已按来源分别核算 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #185 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 16:26:02 +08:00
guke	8e01ae0bf9	修复:ComparisonResultIn 补 skipped_dish_count(逐平台缺菜数落库) (#186) ... pricebot 把逐平台缺菜数冗余进 comparison_results 每行,但上报入参 schema ComparisonResultIn 未声明该字段,model_dump() 会在 POST 路径静默丢弃, 记录页三平台网格拿不到逐格「缺少 X 个菜品」。显式声明补齐 + 回归测试。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #186	2026-07-27 16:13:54 +08:00
linkeyu	7e17df4130	完善提现审核与用户风险管理 (#175) ... ## 改动内容 - 拆分邀请提现与其他提现的筛选、统计和详情数据口径 - 增加人工高风险标识、备注、权限和数据库迁移 - 完善微信失败原因查单、退款兜底与审核操作 - 移除人工处理超时订单接口和提现账本校验功能 - 补充提现审核、邀请详情、风险操作与微信失败原因回归测试 ## 验证 - 相关后端测试：82 passed - Ruff F/I：通过 - 新数据库迁移 upgrade/downgrade/upgrade：通过 ## 说明 - 本地 seed mock 脚本未提交 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #175 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 16:03:31 +08:00
linkeyu	46f68b88e3	修复：统一广告收益分类 eCPM 口径 (#178) ... ## 本次改动 - Draw 信息流 eCPM 合并 `draw + 历史 feed` - 看视频 eCPM 合并 `reward_video + withdrawal_video` - 直接按每次真实展示的 SDK eCPM 加权，不再由发奖状态修正后的收益反推 - 增加经营分类聚合接口字段和专项测试 ## 验证 `tests/test_admin_ad_revenue_scope.py`：3 passed。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #178 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 16:02:40 +08:00
linkeyu	1226bc8365	修复比价记录平均 TOKEN 成本采集与回填 (#182) ... ## 问题原因 - 新版客户端通过服务端 harvest 落库，但完成路径没有触发 LLM 调用明细与 TOKEN 成本回填。 - 内部共享密钥不一致或 PriceBot 实例切换后，拉取失败只留下空值，后续没有自动补偿。 ## 本次改动 - harvest 完成后立即异步回填 LLM 调用、TOKEN 数及成本快照。 - 抽取统一、幂等的成本回填服务，并增加定时补偿 worker。 - 增加 PriceBot 内部鉴权预检、错误日志和多实例查找兜底。 - 仅回填当前价格配置生效后的终态记录，避免用现价误算更早历史数据。 - 补充环境配置、部署说明和单元测试。 ## 验证 - 相关测试：36 passed。 - 静态检查通过，diff check 通过。 - 本地页面显示 ¥0.0139，与数据库精确均值 0.013916 的四舍五入结果一致。 ## 上线注意 部署时需确保 app-server 与 PriceBot 的 INTERNAL_API_SECRET 完全一致并重启两个服务；worker 启动后会自动补齐符合条件的历史空值。 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #182 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 15:51:19 +08:00
exinglang	bf02b846a7	feat(guide-video): 支持领券和比价独立视频奖励配置	2026-07-27 15:14:37 +08:00
linkeyu	22a1105000	修复用户反馈机型与系统版本补全 (#181) ... ## 改动说明 - 反馈列表按同一用户、同一设备编码和反馈提交时间，补全可读机型、厂商及 ROM 大版本 - 补充常见线上机型编码映射 - 更新本地 mock 数据并增加时间边界回归测试 ## 验证 - 反馈相关测试：3 项通过 - Ruff 检查通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #181 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 13:33:55 +08:00
guke	b2a528eba1	fix(comparison): 派生 best 排除缺菜店, 避免虚低价当"最低价" (#176) ... pricebot comparison_results[].rank 是纯价格排序(含缺菜店), server 派生 best 若照单全收, 会把缺菜(漏菜)店的虚低总价当 best_price → 记录页戴"最低"红框 + 算出虚假省额。 - _derive / _derive_from_results 派生 best 时按 platform_results[pid]. skipped_dish_count 排除缺菜店; 源平台永远全菜, 全目标缺菜时回落到源 (is_source_best、saved=0), 不虚报省额。 - platform_results 内层结构宽松(老客户端透传可伪造), _is_short 用 isinstance 兜底, 值非 dict 时按"不缺菜"处理, 不打 500。 - harvest_done 传入 done_params.platform_results; 不传→纯 rank/price 老行为不变。 - 新增纯函数测试: 排除缺菜 / 全缺菜回落源 / 不传保持老行为 / 内层非 dict 不崩, 覆盖 _derive 与 _derive_from_results 两条路径。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #176	2026-07-27 10:35:15 +08:00
linkeyu	cdd49c6421	修复：补齐收益明细广告网络来源 (#179) ... ## 本次改动 - 激励视频发奖记录按用户与 `ad_session_id` 回填展示侧 ADN - 信息流明细保留每条发奖自身上报的 ADN 与底层代码位 - 历史记录仅在 `用户 + trace_id + eCPM` 候选网络唯一时安全回填 - 多网络候选保持空值，避免错误归因 ## 验证 专项测试 4 passed，覆盖不同 ADN 明细及唯一/歧义回填场景。 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #179 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 10:24:32 +08:00
linkeyu	775a503d6f	修复广告收益用户详情加载失败 (#180) ... ## 问题原因 - 奖励统计接口用完整 User ORM 判断用户存在，滚动发布或表结构未同步时会因无关字段导致 500 - 金币记录合并广告与签到数据后直接排序，PostgreSQL 中 aware/naive datetime 混排会抛异常 ## 修复内容 - 新增只投影 user.id 的用户存在性检查，保持不存在用户返回 404 - 金币记录排序前统一转换为 aware UTC 排序键 - 增加旧表结构投影与混合时区回归测试 ## 验证结果 - tests/test_admin_read.py：18 项全部通过 - 线上只读数据库回归：近期 7 个活跃用户统计与金币明细全部正常返回；用户 #33 返回 1514 条记录 - 语法/未定义引用检查通过 - 全量测试 532 通过、9 失败；失败均在未修改的 origin/main 基线上复现，和本 PR 无关 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #180 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-27 10:15:54 +08:00
linkeyu	7bf04f2655	功能：新增风控监控与处置能力 (#174) ... ## 修改内容 - 新增短信、一键登录、比价三类风控事件与规则聚合 - 新增管理员忽略、封禁、解封、重置报警和阈值配置接口 - 风险列表返回当前有效限制的 restriction_id，供后台已封禁视图解除 - 在短信/一键登录、比价、任务领奖、提现链路接入风险记录与限制 - 新增通用行为流水、风险事件、主体限制模型及 Alembic 迁移 - 新增本地演示数据脚本与风控测试 ## 验证 - ruff check：通过 - Alembic 全新 SQLite upgrade head / downgrade -1：通过 - 风控测试：通过，覆盖封禁列表 restriction_id 与解除链路 - 全量测试：532 passed，8 failed；其中 7 项在干净 origin/main 独立复现，另 1 项独立复跑通过，未发现本分支新增回归 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #174 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai> 0.5.0 0.5.1	2026-07-25 17:56:23 +08:00
marco	5f6593eaf2	fix(alembic): 缩短 withdraw 迁移 revision id 至 varchar(32) 内 ... drop_withdraw_active_unique_index (33 字符) 超过 alembic_version.version_num 的 varchar(32) 上限,生产 alembic 写版本号时 StringDataRightTruncation 报错、 部署中断。改短为 drop_withdraw_active_uniq_idx (29 字符):迁移逻辑(drop_index) 一字不变、无下游引用、仍为唯一 head。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> 0.4.6 0.4.7	2026-07-24 20:32:38 +08:00
guke	e11f506e1e	docs: 提现允许在途时继续提交申请 设计spec (#173) ... ## 摘要 取消「同一用户同时仅一笔在途提现」限制:已有 reviewing/pending 提现单时可继续发起新申请。 - 删应用层在途单检查(WithdrawTooFrequentError)+ 删 DB 分区唯一索引 ux_withdraw_order_user_active(含迁移) - 清理失效死代码;IntegrityError 兜底瘦身为仅处理 out_bill_no 幂等 - 既有约束不变:建单先扣款(防超提)、coin_cash 每日档位次数、out_bill_no 幂等、解绑退款、admin 审核/对账均按单号维度 ## 测试 - 新增:多笔在途并存放行(coin_cash & invite_cash)、第二笔仅受余额约束(409 现金余额不足) - 迁移 upgrade→downgrade→upgrade 回环验证 - 提现域全绿(test_withdraw / test_invite_cash_withdraw / test_withdraw_ledger_check) ## 注意 - 客户端:每次提交需生成新的 out_bill_no;未开免确认时多笔 pending 各返回一个微信确认页,App 需能处理多笔待确认 - 无并发硬上限(产品拍板):coin_cash 由每日档位次数天然封顶,invite_cash 仅受余额约束 --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #173	2026-07-24 16:40:57 +08:00
guke	addc30817f	修复：coupon_claim_event 回填按 (trace_id, coupon_id) 去重，避免上线迁移唯一约束冲突 (#172) ... 旧回填 INSERT ... SELECT 从 coupon_claim_record 整表 1:1 复制进 coupon_claim_event。 两表唯一键不同:源表按 (device_id, coupon_id, claim_date) 去重,trace_id 可空且不在 唯一键里;新表按 (trace_id, coupon_id) 唯一。一次会话的 /step 帧跨零点(Asia/Shanghai) 时,同一 (trace_id, coupon_id) 会落在相邻两天两行,复制时撞 uq_coupon_claim_event_trace_coupon, 整个迁移事务回滚,线上发车中断(线上命中 (1581db0e..., mt_banjia_zhoumo))。 回填改为按 (trace_id, coupon_id) 只取 id 最大(最近写入)的一行,SQLite/PostgreSQL 通用。 运行期写入路径(record_claims 按 (trace_id, coupon_id) upsert)本就无重复,仅此一次性回填未做防御。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #172	2026-07-24 15:12:20 +08:00
linkeyu	e165fcfc5e	修复：自动查单关闭不再标记为支付异常 (#170) ... ## 改动说明 - 自动查单关闭时不再写入微信提现配置异常列表。 - 保留自动查单状态字段、部署开关和运营开关，不改变 worker 实际行为。 - 明确自动查单属于非阻断运维能力，避免与“无法微信打款”混淆。 ## 验证 - `pytest tests/test_withdraw_ledger_check.py tests/test_admin_config.py -q` - 8 项测试全部通过。 - 本地管理 API 健康检查确认不再返回自动查单关闭问题。 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #170 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 14:51:31 +08:00
zuochenyong	3f7b5167fa	功能：新手引导视频 + 美团券首页分页索引 (#167) ... Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: 左辰勇 <exinglang@gmail.com> Reviewed-on: #167 Co-authored-by: zuochenyong <zuochenyong@wonderable.ai> Co-committed-by: zuochenyong <zuochenyong@wonderable.ai>	2026-07-24 14:48:40 +08:00
linkeyu	9e88ca72d3	修复提现审核详情点击用户后提示操作失败 (#171) ... ## 问题现象 在“提现审核”页点击用户所在行后，提现单主详情可以打开，但用户统计和金币记录区域为空，页面连续提示“操作失败”。 ## 原因说明 打开抽屉时前端会继续请求两个子接口： - `/admin/api/users/{user_id}/reward-stats` - `/admin/api/users/{user_id}/coin-records` 这两个接口原来都使用 `select(AdRewardRecord)` 加载完整 ORM 对象。SQLAlchemy 会把模型映射的所有列自动展开到 SQL 中，其中包括后来新增的 `boost_round_id`。当旧本地数据库或滚动发布中的数据库尚未补齐该列时，即使提现详情本身完全不使用这个字段，查询仍会报 `no such column: ad_reward_record.boost_round_id`，两个接口均返回 500。 前端的统一错误处理只会展示响应 JSON 中字符串类型的 `detail`；该 500 返回的是普通 `Internal Server Error`，因此最终回退成通用文案“操作失败”。本地前端开启了 React Strict Mode，初始化副作用在开发环境会执行两次，所以两个失败接口会形成截图中的四条“操作失败”提示。 ## 修复方案 - 用户奖励统计只查询实际需要的 `ecpm_raw`、`coin` 等字段。 - 金币记录只查询页面展示、排序所需字段。 - 同步缩小信息流广告和签到记录的字段投影，避免将来新增无关 ORM 列再次拖垮详情页。 - 增加 SQL 级回归测试：主动拦截任何包含 `ad_reward_record.boost_round_id` 的详情查询，并验证两个接口仍返回 200。 该改动不会改变统计口径或返回结构。数据库迁移仍应正常执行；这里增加的是旧库及滚动发布期间的向后兼容保护。 ## 验证结果 - `pytest tests/test_admin_read.py -q`：17 passed - 新增回归测试覆盖 `reward-stats` 与 `coin-records` - `git diff --check`：通过 - 本地实际提现用户接口验证：两个接口均返回 200 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #171 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 14:04:04 +08:00
linkeyu	21a4d0af5b	后台审核新增批量处理接口 (#164) ... ## 改动 - 新增低价审核与用户反馈的批量通过、批量拒绝接口 - 单条仍保持独立事务、审计、发奖和通知；单项失败不影响同批其它记录 - 批量响应返回每条记录的成功状态或失败原因，供前端保留失败项重试 - 反馈审核补充行锁，降低并发重复发奖风险 ## 验证 - `ruff check`（相关路由、Schema、测试） - `pytest tests/test_admin_write.py -q`：22 passed --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #164 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 12:04:41 +08:00
guke	f7a7a49281	fix(withdraw): 免确认授权已开启判定加 authorization_id 非空,与打款一致 (#168) ... 免确认授权已开启判定加 authorization_id 非空,与打款一致 --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #168	2026-07-24 11:17:09 +08:00
linkeyu	71aef455f4	修复：签到膨胀金币归入看视频分类 (#169) ... ## 修改内容 - 将历史 `signin_boost` 金币从“常规任务金币”分类移出。 - 将 `signin_boost` 与 `reward_video/ad_reward` 一起计入“看视频金币”。 - 保留独立的 `signin_boost_coin_total` 历史审计字段。 - 增加不重不漏回归测试，确认分类调整前后本期发放总额保持不变。 ## 本地验证 - `tests/test_admin_read.py`：16 项通过。 - Ruff 与 `git diff --check`：通过。 - 全量后端测试：505 项通过；8 项为 `main` 现有无关失败。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #169 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 11:16:38 +08:00
linkeyu	66527f6cdc	修复：领券单券成功率按任务独立统计 (#166) ... ## 修改内容 - 新增按 `trace_id + coupon_id` 幂等的逐次单券事件表。 - 保留每日资产记录，同时独立保存每次领券事件，避免同设备同日重跑串场。 - 后台逐场成功率和单券明细改为读取逐次事件。 - 增加历史数据回填迁移、本地 mock 脚本和回归测试。 ## 验证结果 - 领券相关测试：22 项通过。 - 全新 SQLite 数据库执行 `alembic upgrade head`：通过。 - 全量测试：508 项通过；另外 8 项为现有无关失败。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #166 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 11:15:09 +08:00
linkeyu	b4a2a8c31d	功能：限制每位用户每天最多发起 100 次比价 (#165) ... ## 变更内容 - 登录用户按北京时间自然日计算比价发起次数，每人每天最多 100 次。 - 第 101 次起返回 HTTP 429，并提示“今日已比价超过100次，请明天再试”。 - 同一 trace_id 的网络重试按幂等处理，不会重复计数。 - 使用用户行锁串行化同一账号的并发请求，避免并发突破上限。 - 复用现有 comparison_record 的 running 记录，无需新增数据库迁移。 ## 本地验证 - 比价额度专项测试 11 项通过。 - 本次修改涉及文件的 Ruff 检查通过。 - 已覆盖未登录、重复 trace_id、跨自然日、第 100 次放行及第 101 次拒绝。 --------- Co-authored-by: CodexSandboxOffline <798648091@qq.com> Reviewed-on: #165 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-24 11:14:31 +08:00
marco	ceceeb3458	fix(db): 合并 3 个 alembic 迁移 head（发车 0.4.4 前置，no-op merge 节点） 0.4.4 0.4.5	2026-07-23 17:55:35 +08:00
linkeyu	31f61f6aad	增强：CPS 每日自动对账增加可回查日志 (#163) ... ## 背景 PR #162 已合并。本 PR 为其后续日志增强，方便人工按一次任务完整回查美团、京东每日自动对账。 ## 日志内容 - 每次运行生成唯一 `run_id`，记录 `scheduled` / `startup_catchup` 触发来源 - 记录北京时间计划日期、近 3 天回拉窗口、环境、数据库方言、主机名和 PID - 分平台记录开始、成功、跳过、失败及执行耗时 - 成功结果记录 fetched / inserted / updated / pages / api_requests，京东额外记录小时窗口数 - 京东上游失败记录具体小时窗口、页码和请求序号；美团记录失败页码 - 最终汇总记录 success / partial_success / failed、失败平台、是否需要人工补跑和下次执行时间 - 日志使用现有 `extra` 结构化字段写入 JSON 日志，便于 SLS/人工检索 ## 兼容性 - 手动对账接口、事务和返回模型不变 - 不记录密钥、Token、完整上游响应或订单明细 - 仓储层仅增加可选审计上下文和请求计数；不改变拉取及 upsert 逻辑 ## 验证 - `pytest tests/test_cps_reconcile_worker.py tests/test_cps_admin.py tests/test_admin_read.py tests/test_observe.py -q`：44 passed - 相关文件 Ruff 检查通过（忽略文件原有 UP017 提示） - `git diff --check` 通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #163 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-23 11:57:37 +08:00
linkeyu	b7cfcf7495	功能：美团和京东 CPS 每日自动对账 (#162) ... ## 需求 - 保留现有后台手动对账逻辑不变 - 每天北京时间 05:00 自动刷新 CPS 对账 - 当前仅处理美团和京东 - 每次按更新时间回拉近 3 天，覆盖延迟更新和订单状态变化 ## 实现 - 新增进程内 CPS 自动对账 worker，并接入应用生命周期 - 美团使用更新时间查询类型 2，京东使用更新时间查询类型 3 - 复用现有仓储层对账及 order_id 幂等更新逻辑 - 美团和京东独立会话、独立异常处理，单个平台失败不阻塞另一平台 - 增加单实例锁、开关、执行小时、回拉天数和轮询间隔配置 - 服务在 05:00 后重启时会补跑当天任务 ## 验证 - `pytest tests/test_cps_reconcile_worker.py tests/test_cps_admin.py tests/test_admin_read.py -q`：27 passed - 相关文件 Ruff 检查通过 - `git diff --check` 通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #162 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-23 10:51:20 +08:00
linkeyu	77f772f47c	性能：比价和领券分位数改为 PostgreSQL 聚合 (#161) ... ## 背景 - 比价记录页和领券记录页前端已经只拉当前页，并直接展示后端 summary。 - 原后端仍会将筛选区间内的全部耗时值取回 Python 计算分位数，生产数据量增大后会放大数据库读取和应用内存开销。 ## 修改内容 - 比价记录：成功耗时 P5/P50/P95/P99、平均耗时以及中途退出耗时 P5/P50/P95 改用 PostgreSQL percentile_cont/AVG 聚合。 - 领券记录：发起数、完成数、平均耗时和完成耗时 P5/P50/P95/P99 合并为一条 PostgreSQL 聚合查询。 - 日期、用户、环境、状态、店铺和商品等筛选条件继续与列表共用，统计口径不变。 - SQLite 不支持 percentile_cont，仅在本地和测试环境回退读取耗时单列；不加载完整业务记录。 - API 字段与前端展示保持不变，无需前端改动。 ## 验证 - 比价/领券及关联广告收益、点位、按券统计测试：26 passed。 - 本次涉及文件 ruff 检查通过。 - PostgreSQL SQL 编译测试确认使用 ordered-set percentile_cont 聚合。 - 全量测试：497 passed；8 个现有失败集中在邀请奖励、提现档位和代理转发等无关模块。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #161 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-23 10:35:41 +08:00
linkeyu	cb8e8ccc1d	修复：激励视频未完成时预估收益归零 (#160) ... ## 问题 激励视频在 onAdShow 时已经上报 eCPM，用户随后提前关闭或播放时长不足时，报表仍按 eCPM/1000 计入预估收益，导致明细、合计、趋势和分类统计虚高。 ## 修改 - reward_video 的 closed_early / too_short 有效预估收益统一归零 - capped / granted 保持原收益口径 - 更新 API 字段说明 - 增加明细、日汇总、小时汇总、类型汇总回归测试 ## 验证 - ruff check（本次修改文件）通过 - pytest tests/test_admin_ad_revenue_scope.py tests/test_admin.py -q：10 passed - 全量 pytest：489 passed，7 个失败已在未修改的 origin/main 基线复现，与本次改动无关 ## 关联前端 WonderableAI/shaguabijia-admin-web#64 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #160 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai> 0.4.3	2026-07-22 17:38:51 +08:00
linkeyu	fda82fe313	后台：新增监控审计权限分组并加强接口鉴权 (#159) ... ## 变更 - 权限目录新增一级分组“监控审计”，统一设备存活、埋点成功率、埋点日志和审计日志。 - 补齐 `analytics-health` 页面权限，技术角色默认拥有四项监控审计权限；运营默认仅保留设备存活。 - 新增服务端 `require_page` 守卫，四组 API 不再只依赖前端隐藏导航，直接调用也会校验角色或个人页面权限。 - 增加迁移，为存量技术角色补上 `analytics-health` 权限，并同步接口文档。 ## 验证 - 改动文件 `ruff check` 通过。 - `tests/test_admin_roles.py tests/test_analytics_health.py`: 24 passed。 - Alembic 从空库 upgrade 到 head，再 downgrade 本迁移：通过。 - 全量测试：443 passed、6 failed；6 项失败在干净 `origin/main` 上原样复现（主干为 442 passed、6 failed），与本 PR 无关。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #159 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-22 17:22:09 +08:00
zuochenyong	28a86c3b2c	feat(compare): 比价记录列表增加分页 (#156) ... GET /api/v1/compare/records 新增 ordered / keyword 两个查询参数,过滤全部下推到 SQL。 不能分页之后再由客户端 filter —— 一页里可能一条都不命中,列表看着就是空的, 得翻很多页才蹦出一条。 顺带修掉这条链路上几处随数据量线性变慢的地方: - 列表查询 defer raw_payload / llm_calls / llm_price_snapshot 三个重型 JSON 列。 出参 ComparisonRecordOut 根本不读,却是每页几百 KB~几 MB 的白读 + 白反序列化, 是「比价记录/全部记录」页慢的主要来源;详情接口不 defer,raw_payload 照常返回。 - 「已下单」标记改为只按本页店名(≤ limit 条)反查 savings,不再把该用户全部下单 店名捞进内存跟 50 条记录取交集。 - 新增 (user_id, created_at, id) 复合索引:反向扫恰好等于列表的 ORDER BY created_at DESC, id DESC,PG 免排序直接取前 n 条。 迁移走 CREATE INDEX CONCURRENTLY,不阻塞线上 harvest 写入。 - keyword 转义 LIKE 通配符后再匹配,避免搜一个「%」把整表拉回来。 - nginx 对 application/json 开 gzip:此前 gzip off + gzip_types 只含 text/html + gzip_proxied off 三个默认值凑一起,等于所有接口都在裸奔;记录列表这种 字段名和中文店名高度重复的 JSON 压缩比稳定 8~10 倍。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: 左辰勇 <exinglang@gmail.com> Reviewed-on: #156 Co-authored-by: zuochenyong <zuochenyong@wonderable.ai> Co-committed-by: zuochenyong <zuochenyong@wonderable.ai>	2026-07-22 17:18:26 +08:00
Ghost	0717c09721	基于 main 接入各厂商直推服务端 (#118) ... 改动：新增厂商推送配置、设备 push_vendor/push_token 字段、device push-test 接口、心跳超时厂商直推发送逻辑和对应测试。 验证：python -m pytest tests/test_device_push.py tests/test_auth.py tests/test_health.py 通过。 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: 左辰勇 <exinglang@gmail.com> Co-authored-by: lowmaster-chen <1119780489@qq.com> Reviewed-on: #118 Co-authored-by: Ghost <> Co-committed-by: Ghost <>	2026-07-22 15:42:25 +08:00
linkeyu	2eb36b44c8	fix(admin): 按任务白名单聚合常规任务金币 (#157) ... ## 背景 大盘“常规任务金币”原先采用“全部正向金币减排除清单”的反向口径。线上新增 `feed_ad_reward_coupon` / `feed_ad_reward_comparison` 后未同步加入排除清单，导致领券和比价奖励误计入常规任务金币。 ## 修改 - 改为明确白名单：`signin`、历史 `signin_boost`、全部 `task_` 任务、`price_report_reward`、`feedback_reward` - 未知新 `biz_type` 默认不进入常规任务桶 - 增加覆盖领券、比价、广告、邀请、管理员及未知类型的回归测试 - 顺带修复改动文件已有的 Ruff `UP017` ## 验证 - 线上只读 PostgreSQL：新口径全量为 108,022，领券/比价误计差额为 450,675 - Ruff：通过 - `pytest tests/test_admin_read.py tests/test_cps_admin.py -q`：23 passed --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #157 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai> 0.4.2	2026-07-22 12:09:06 +08:00
linkeyu	510df176b3	feat(admin): 返回逐场领券点位分数与明细 (#153) ... ## 变更内容 - 按 trace_id 批量统计每场领券成功数/尝试数 - success、already_claimed 计成功，failed 计尝试，skipped 排除 - 返回每个点位的名称、ID、状态和失败原因 - 无有效逐券埋点时返回空值，不伪造 0/0 - 用户领券记录抽屉同步返回点位分数及明细 ## 性能 - 当前页全部 trace_id 一次批量查询，不产生逐行请求 ## 验证 - 16 项后端测试通过 - 覆盖成功、已领、失败、跳过及失败原因 --------- Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #153 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-22 11:46:00 +08:00
zuochenyong	73970087ff	feat(ad): 膨胀弹窗改用服务端权威金额 + 本轮累计口径,下线 signin_boost (#154) ... Co-authored-by: guke <guke@wonderable.ai> Co-authored-by: 左辰勇 <exinglang@gmail.com> Reviewed-on: #154 Co-authored-by: zuochenyong <zuochenyong@wonderable.ai> Co-committed-by: zuochenyong <zuochenyong@wonderable.ai>	2026-07-22 10:53:21 +08:00
linkeyu	9286b82b6d	feat(admin): 优化比价记录概览统计与加载 (#152) ... ## 变更内容 - 新增比价记录概览聚合接口，主耗时均值及 P5/P50/P95/P99 仅统计 success - 比价列表支持按北京自然日过滤，概览和列表复用同一筛选口径 - 后端聚合成功率、成本、低价率及中途退出指标 - 修复单条样本分位数错误返回 0 的边界问题 - 增加成功/失败/退出及日期分页回归测试 ## 验证 - Python compileall - SQLite 聚合、日期边界和分页检查 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #152 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-22 10:42:24 +08:00
linkeyu	f9a62bffbe	功能：广告收益支持环境与业务代码位筛选 (#155) ... ## 修改内容 - 客户端预估与穿山甲汇总统一支持正式、测试、全部环境筛选 - 支持业务代码位与全部代码位两种对账范围 - 保留已上线正式业务代码位，避免配置切换后历史报表漏数 - 补充接口文档和筛选口径测试 ## 本地验证 - 相关后端测试 10 项通过 - Ruff 检查通过 - 本地后台页面联调通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #155 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-22 10:41:52 +08:00
linkeyu	beadce31ed	fix(ad): 服务端强制不足一秒曝光收益为零 (#150) ... ## 改动 - eCPM 上报新增可选 exposure_ms，兼容旧客户端 - exposure_ms < 1000 时保留展示记录并强制有效 eCPM 为 0 - 失败领券任务允许保留短曝光零收益 trace，后台显示 0 而不是未填充 - 其他失败后的迟到曝光仍按原规则解绑 trace ## 验证 - 相关 pytest：10 passed - Ruff：通过 - compileall：通过 依赖：先合并 Server #149。 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #150 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-21 13:53:10 +08:00
guke	f39467ec08	docs(welfare): 15天不活跃清零金币/现金 设计文档(spec) (#151) ... 对齐前端首页可见事件home_visible --------- Co-authored-by: guke <guke@autohome.com.cn> Reviewed-on: #151	2026-07-21 13:52:40 +08:00
linkeyu	1f874819fd	fix(ad): 失败领券任务不再归属迟到广告收益 (#149) ... ## 修复内容 - coupon 广告上报到达时校验对应领券 session 状态 - session 已 failed 时保留全局广告收益记录，但清空 trace 归属，失败明细不再显示收益 - 增加失败 trace、其他场景和未知 trace 的回归测试 ## 验证 - 相关 pytest：7 passed - Ruff：通过 - compileall：通过 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #149 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-21 13:41:28 +08:00
zuochenyong	c53ce896f7	feat(huawei-review): 华为审核开关(admin 可切 + 客户端下发 + 审计) (#147) ... 华为应用市场审核要求新手引导的「快速设置」权限步必须可被用户关闭,平时又要 保住权限开启率,故做成后台可切的两态开关,送审期间切开、过审后收回。 - app_config 新增 huawei_review 行(default / review),空库与脏值一律回退 default = 上线至今的现状,宁可不给退出按钮也不误放开 - admin: GET/PATCH /admin/api/huawei-review,权限 operator/tech,切换写审计 - 客户端: GET /api/v1/platform/huawei-review 不鉴权(引导页在登录前就展示), 下发 onboarding_closable;机型 gate 由客户端做,故此处不判 ROM Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: 左辰勇 <exinglang@gmail.com> Reviewed-on: #147 Co-authored-by: zuochenyong <zuochenyong@wonderable.ai> Co-committed-by: zuochenyong <zuochenyong@wonderable.ai>	2026-07-21 10:43:58 +08:00
linkeyu	ed26935b14	feat(admin): 数据大盘比价指标改为后端聚合 (#146) ... ## 修改内容 - 数据大盘比价指标改由后端按日期区间聚合 - 增加完成数、中途退出数、成功率、中位数、P95 和 TOKEN 总成本 - 成功率分母排除中途退出，耗时仅统计 success/failed - 增加后端聚合口径测试 --------- Co-authored-by: unknown <798648091@qq.com> Reviewed-on: #146 Co-authored-by: linkeyu <linkeyu@wonderable.ai> Co-committed-by: linkeyu <linkeyu@wonderable.ai>	2026-07-21 10:11:39 +08:00