xinyouhe/yunke
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
411 Commits 1 Branch 0 Tags
8f9ef747cce312a1623a12e8ab12d3eca537b74c
Commit Graph

211 Commits

Author SHA1 Message Date
浅念 8f9ef747cc fix: prune 改逐行删——asyncmy 拒 tuple IN 的 list 参数 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 13:54:34 +08:00
浅念 3d2889bcde fix: prune 块漏 import sqlalchemy——NameError 中断对账 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 13:48:06 +08:00
浅念 422a726ee8 feat(management): 驾驶舱KPI环比(prev_kpis+delta)+异常卡带员工名跳详情+列表进详情带筛选 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 12:20:28 +08:00
浅念 be0d6f844e feat(group-members): 群列表对账云客总数+群详情成员墙(头像+昵称) 
用户报两点:①微信群列表与云客群统计总数不一致(实测云客 1,864 vs 本地
2,012——friend_list/es 时代残留的 148 行 owner 组合已不在 getChatroomList
返回里);②群详情成员列表全是 wxid 无法识别。

- chatroom-stats 全窗模式加对账:名单取满(>=声明 total)才删本地不在
  云客名单里的 chat_group(wechat)行——页脚从此与云客一字不差;短页宁
  可不对账防误删
- backfill_group_members 增强:头像列(消息最新一条 sender_head_url)+
  customer 兜底 UPDATE(member_id=friend_id 命中本司好友补昵称/头像,
  覆盖未发言成员);full_sync 8b 原位生效
- 群详情 drawer 成员墙:头像+昵称网格(群昵称>好友昵称>wxid 回退+wxid
  副行),替代原 memberIds 原始串;仅微信 tab(WA 群成员未派生)

722 后端测试绿,前端构建过。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 12:11:42 +08:00
浅念 4e53a99629 fix(media): upsert_media MySQL 悬空 new.fetched_at——录音本地化停更多日 
第二轮同步审计实测复现(最小用例 0.3s 即炸):upsert_media 的 update_cols
取了全部表列,而 values 只含 11 个业务列——server_default 列
(fetched_at/updated_at)不在 INSERT 列集,MySQL 编译 ON DUPLICATE 时生成
new.fetched_at 悬空引用 → 1054 Unknown column → 每夜 full 的
call_recordings 步骤(录音下载本地化)自生产部署起**每夜静默失败**,
新录音一直没本地化(异常被 SyncRun 吞成 failed 日志,序列继续)。

修:update_cols 只取 values 里实际有的列(对齐 _build_upsert_stmt 的
「只更新实际插入列」原则);updated_at 在冲突重下时刷 now()。

SQLite 分支(excluded 引用宽容)同逻辑修正;722 测试绿。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 11:54:14 +08:00
浅念 602bee8fdf fix(sync): 空对话「已扫」记忆——根除 2,468 个无消息对话的每轮全量翻史 
前项审计的深挖:带窗验证发现活跃仅 27 对话,但访问集仍有 2,493 个——
2,468 个「从未扫过」的对话(纯语音/从未聊过客户)水位恒 0,拉完 0 条
仍是 unscanned,下一轮又被全量翻史(~2.6s/个,每 4h×每晚都翻)——
这才是消息任务时长的真正黑洞(昨夜 53,682 条绝大部分源于此)。

修:复用 sync_state 表记扫描标记(entity_type={channel}_conv_empty)——
- 拉到 0 条有效消息即打标(微信/WA 1:1)
- 发现层排除「已扫空且不活跃」的;客户一旦发消息(last_chat_time 进
  活跃窗)自动回到访问集——不会漏新消息
- 周日 full_history 强制全访问兜底(云客补历史场景)
- 空群(115 个,每轮 ~5min)本轮不动,量小

722 测试绿。预期效果:4h 序列访问集 2,493→~30,时长分钟级。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 11:24:59 +08:00
浅念 a9197f696a fix(sync): 同步链路审计修复——水位边界白拉/全量无超时/群活跃窗判定源 
全项目数据同步审计发现四漏洞(前项为证据):

① 消息增量边界白拉(证据:昨夜 wa-messages fetched=53,682 而真实新消息
   仅 321 条,99.4% 是白拉白写的已入库旧消息)——云客 chatRecords/msg-chats
   的 start 参数是 inclusive(返回 ts>=start 含边界),四个消息实体(微信
   1:1/WA 1:1/微信群/WA 群)统一在归一化后过滤 ts<=watermark 的边界行,
   不计数不写库(省 99% 写放大,计数从此反映真实新增)
② full_sync_all.sh 无超时——极端情况(常态 10-20h)拖进次日相位把 02:00
   全量又挤掉(前两天事故同型);加 22h 上限
③ 周日 full-history 无超时——4 实体全历史可能 24h+,必挤周一;单实体
   加 6h 上限
④ 群消息活跃窗判定源是昨晚 full 的 chat_group.last_chat_time 快照——
   「昨天安静、今天突然活跃」的群会被 24h 窗口漏到明晚;4h 序列在
   group-messages 前加 chatroom-stats 全窗(~1min)刷新群活跃判定源

722 测试绿(4h 序列断言 9→10 命令+chatroom-stats 位序)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 11:08:15 +08:00
浅念 e3fadfe1a6 fix(scheduler): 调度根治——4h 增量只扫活跃对话+账号表进 4h+超时保险丝 
用户报「员工列表时间与云客差 2 天」。根因链:4h 增量序列全对话遍历
(WA 9,357 对×~3.5s≈9h,整序列 15h+)超过自身 4h 间隔→与 02:00 全量在
asyncio.Lock 上背靠背互相排队→近两晚全量被挤掉→账号表(仅全量刷)停更
两天,员工列表「数据更新/最新消息时间」显示 09-08 快照。

三层修复:
- 活跃窗:_discover_conversations/群发现加 active_since_ms——已扫过的
  对话仅保留 last_chat_time 在窗内的(云客 lastChatTime 滞后小时级,
  24h 窗足够容错),从未扫过的(新覆盖优先)不受限;陈旧对话无新消息,
  每日 full 兜底。CLI --active-window-hours,四消息实体透传
- 4h 序列头部加 accounts/wa-accounts(~2min)——员工列表时间最多滞后
  4h,不再依赖每晚全量
- 超时保险丝:_page_subprocess 加 timeout(超时 kill 返回 124,上游
  break 下轮补)——messages 各实体 15-80min 预算,单命令拖不死相位;
  full/full-history 不设限

722 测试绿(序列断言 7→9 命令+窗口参数)。干跑验证:近 24h 活跃私聊/
群相对全量降一个数量级(本地旧库群 2011→537;私聊依赖 friends 先刷,
序列顺序已保证)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 10:38:47 +08:00
浅念 940762e7ff fix(management): drilldown行补channel字段——前端聊天路由判渠道用(契约冻结前补齐) 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-10 09:49:59 +08:00
浅念 9fbd572bb7 docs(management): 批次B终评收尾——validate_config补源名唯一性+遗留观察项归档 
批次B终评Approve后两处闭环:
- validate_config补源指标名跨维度唯一校验(comparisons按源名建键的
  静默覆盖防线)+测试
- 观察项归档:call_band样本基数(批次F)/源名唯一(已修)/性能与winsorize(批次F)
 2026-09-09 19:28:48 +08:00
浅念 3d5644c42a fix(management): drilldown生命周期历史改peer键控对齐批次A口径+comparisons键域统一+补测试 
评审修正(I1/M1-M4/M6):
- I1 lifecycle_customers 历史改 (channel,peer) 键控跨owner合并,归属仍由
  Customer.owner_account_id 决定——与批次A _lifecycle_daily 同口径;新增
  共享客户测试(历史在他人账号下仍全量呈现)
- M3 employees 行 comparisons 键域统一为指标源名(config code→spec.metric
  映射,active_friends_band/call_band 不再出现),与 sections 一致
- M4 未回复分支空 owners 先短路,免去无效 finalize 调用
- M1 employee_metrics._percentile 改公有 percentile 供同包复用,删除
  api_assembly.percentile_nearest(存储层 _percentile 不同层保留)
- M2 drilldown 内联 SQL(FirstReplyFact/PhoneCall)下沉 api_assembly
  (fr_fact_rows/user_calls_page),路由层无裸查询
- M6 补 start>end→422 断言;新增 config_source=db 测试(激活配置
  min_days=9→五天数据员工翻 insufficient_sample,守护生效可见)

tests/test_management_api.py: 21 passed;全量 721 passed

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 18:59:45 +08:00
浅念 31cd2d92aa feat(management): 只读管理API六端点——dashboard/employees/detail/sections/drilldown白名单/指标定义 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 18:34:58 +08:00
浅念 b0ebe8a15a feat(group-stats): 微信群列表对齐云客「微信群统计」——getChatroomList 数据源+窗内统计 
用户报微信群列表数据/内容不对,应对齐云客「沟通→微信号管理→微信群统计」
(/cms/wechat/wechatgroup)。真机探明(表单登录+页面导航抓 network):

- 数据源=POST /wechatweb/chatroom/getChatroomList(form:departmentId+
  startTime/endTime 窗+分页;信封 data.overviews[]/totalCount 1,854 行)
- 云客窗是任意时间窗实时算:沟通消息数实测同群全史 417/7天 36/单日 6
- **修正存量映射错误**:member_count 原存 friendNum(员工好友数),真群成员
  数是 friendCount/getChatroomList.memberCount
- 新增/退出成员数云客按窗实时算,本地无事件流 → 按天积累

实现:
- ChatGroup 补 group_remark 列(备注仅 friend_list/es 携带,两归一化均
  「有值才写」防互清);迁移含存量 raw_json 回填(须先于基线抓取执行)
- 新表 chat_group_member_stats(渠道×账号×群×天一行 added/lost)
- 新实体 chatroom-stats:全窗刷档案列(真成员数/群备注/员工信息,owner
  经 wechat_account alias 解析)+ --day 单日窗落进出日行;full_sync 5c 步
- /api/groups 扩展:msg_start/msg_end 窗内聚合(window_msg_count=
  msg_daily_stats 按天和、window_added/lost=日表和)、last_start/end
  最新消息窗、group_remark 子串;行补员工微信/员工信息关联列
- GroupList 微信 tab:统计时段(默认近7天)/最新消息时间段/群名称/群备注/
  员工下拉/查询 + 9 列(群信息|群备注|员工微信|员工信息|群成员数量|
  新增成员数|退出成员数|沟通消息数|操作);WA tab 不动

700 测试绿(新增窗聚合/筛选/员工列 3 例)。本地实测:基线 1,854 群=云客
total 一字不差,今日日窗 added 407/lost 166 落表,页面 9 列/员工列渲染正常。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 18:09:20 +08:00
浅念 03c08881b6 feat(management): 确定性异常规则×4——P90恶化/回复率骤降/活动骤降/过载+derive_metrics公有化 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 18:06:08 +08:00
浅念 07c9d091a1 fix(management): validate_config补grade_bounds形状与跨维度code唯一性校验 2026-09-09 17:56:55 +08:00
浅念 c9f8c844d6 feat(management): 评分引擎——三类标准化/维度归一/样本保护/等级/四对比明细+期末active_friends接口修订 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 17:42:57 +08:00
浅念 b51b32a14b fix(management): 期聚合active_friends按(uid,peer)去重——多账号共享客户不再双计;reply计数并入Python/单一METRIC_VERSION 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 17:32:34 +08:00
浅念 729710da63 feat(management): 期聚合查询——fact精确分位/期末存量跨渠道合并/distinct活跃/前窗基线窗口 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 17:18:33 +08:00
浅念 8b555a5ad4 refactor(management): 种子函数移入management包+深拷贝冻结配置+清理死代码 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 17:06:14 +08:00
浅念 afc71e61ef feat(management): 指标元数据+试算评分配置v1.0+种子CLI——权重校验/幂等落库 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 16:51:56 +08:00
浅念 7758a3351f docs(management): 批次A终评修正——部署顺序理由/data_complete语义/通话类型注释 
终评 Approve 后三处文档级修正:
- CLI help与DEPLOY的顺序理由改为事实(宽表不读fact,先跑不会出0;
  顺序约定保留,fact是批次B评分/下钻数据源)
- data_complete 注释改为预留语义待批次B定义(当前恒True)
- EmployeeCallDaily 注释通话类型实测值(voice_call/wa_voice_call)
 2026-09-09 16:30:05 +08:00
浅念 0fce21aaf7 fix(management): 回填CLI通话日并集——消息空窗日的通话不再漏(8天27条实测) 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 16:11:04 +08:00
浅念 b2e8edacc2 feat(management): 两条回填CLI——first-reply-facts/employee-metrics全量重建幂等 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 14:55:16 +08:00
浅念 ad3beb7625 fix(management): 宽表生命周期hist改时点语义(≤as_of累积)——历史日dormant不再被未来消息虚增;补正向同源/percentile None判别+防御性flush 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 14:44:35 +08:00
浅念 2bb4cee76d feat(management): 员工指标宽表——1:1口径/串类与fact同源/生命周期列/幽灵过滤/纯生命周期日出行 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 14:19:25 +08:00
浅念 a38170d205 test(management): 通话followup判别补强——未接通反例/渠道收窄正反例/任一账号 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 14:09:21 +08:00
浅念 08614ddb3f fix(wa-customers): link 路径 LEFT JOIN 档案带 raw_json——WA 好友列表列空白 
用户报 WA 员工列表点「好友列表」数据都不显示。根因:owner 过滤切
customer_account_link 后,link 快照只有客户侧字段;而 WA 客户表格大量列
只存在于档案 raw_json(userName/salePhone/salesNickName/createTime 等
员工侧 camelCase 字段),link 行 raw_json=None → cellText 全部落空,整表
只剩号码可看。

修:_list_owner_links 按 friend_id LEFT JOIN customer 带出 raw_json
(+version)。raw_json 全局一人一份、挂谁名下内容相同;已知口径:共享
客户的员工侧字段是「最后写入员工」的记录(1,967/12,578),客户自身字段
不受影响——完美对齐需 link 补员工快照列,另行评估。

647 测试绿(新增 raw_json 透传测试)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 14:08:44 +08:00
浅念 b2e1b699eb feat(management): 通话日聚合小表——无渠道维/接通=duration>0/24h任一账号跟进(渠道按通话类型收窄) 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 13:51:11 +08:00
浅念 99773f69b9 fix(staff-stats): 统计tab新客户/删除客户/红包昵称切 link——共享好友不再漏计 
全项目同型审计结论的收尾项:统计分析 tab 按 owner 查全局单行档案表,
共享好友(档案挂别的员工名下)不计入——

- _new_customers(新客户):主体 Customer → CustomerAccountLink(add_time
  窗+首条消息兜底 JOIN 平移到 link.owner);数字变大=对齐云客按员工口径
- _del_customers(删除客户):_flag_customers 参数化 model,del 走 link
  (delete_flag per-relation);blocked 保留档案口径(is_block 未镜像进
  link,已知偏差=他人员工名下拉黑不计,注释标明)
- _red_transfer 昵称:link 优先档案兜底(同 sessions._meta 模式)

审计同时确认无需修:群侧(chat_group 复合主键天然多对多)、搜索/长语音
(按 friend 全局直查)、analytics(全局口径)、WA(与微信共用同批修复,
12,578 行 link 已回填,1,967 共享客户在册;无昵称行=WA 联系人本身没存
名字,与云客一致显示号码)。

644 测试绿(新增共享好友新客户判别测试;存量测试种子补 link 行镜像
生产写路径)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 13:45:42 +08:00
浅念 9dc22cd1e6 feat(management): 生命周期判定纯函数——距今天数口径/7天新客/30天沉睡/历史门槛5条 
TDD(批次A Task4):classify/day_add/days_between 纯函数,供 Task6 宽表
生命周期 4 列计算。口径已确认:新客=首次互动≤7 天(含当天共 7 天)、
cooling [7,30)、沉睡≥30 天且历史≥5 条(对齐 churn real min_msgs=5)、
回流=当日互动(last_day==as_of)且前次间隔>30 天(严格大于,恰好 30
天不算);未激活或历史不足的长期静默返回 None。analytics 现有页暂不
切换(v2 §5 口径差异另标),不动 636 既有测试。

模块为纯叶子节点,禁止 import app.storage(防 storage→analytics 成环)。
7 例测试覆盖:new 窗口边界(as_of-6 含/不含)、回流 35/9/31 天与恰好
30 天、last_day==as_of 门槛、6/7/29/30 天落位、历史门槛 4/5、
day_add 跨月。全量 643 绿。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 13:37:22 +08:00
浅念 58d274096d fix(management): first_reply_fact 同毫秒并列主键冲突+定序抖动——reply_msg_id 进 PK/按(ts,msg_id)排序 
评审修正(代码质量评审 Critical#1 + Important#2/#3):
- reply_msg_id 进复合 PK(模型+migration b7c8d9e0f1a2 原地改,本地
  down/up 重建,表空未部署):同毫秒 F,T,F,T 交换的两个样本
  (thread_end_ts, reply_ts) 完全并列不再撞主键(原会中断整个
  recompute_all 事务);兼作下钻证据定位回复消息。
- load_conversation 增查 msg_id 并按 (ts, msg_id) 排序,
  compute_conversation 协议改 3 元组——SQL 等键顺序未定义,原实现
  同毫秒 [F,T] 归属随查询抖动(0/1 answered 摇摆)。
- recompute_pairs 每 500 会话显式 flush+进度日志(内存上界对齐
  summary.recompute_all 惯例,不再依赖隐式 autoflush)。
- 测试:旧 9 个更新协议;新增同毫秒 F,T,F,T 回归/并列确定性/
  空会话幂等清空,fr_sum 总量断言并入双串测试;
  test_management_models 构造补新主键列。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 13:18:08 +08:00
浅念 0b0dd0808b feat(management): 首响事实表跨日精确算法——跨夜串不丢/串末条归属日/同源日聚合 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 12:53:33 +08:00
浅念 373fb266a6 feat(management): 批次A建表迁移——六表幂等守卫/索引独立补齐/downgrade只删新表 2026-09-09 12:33:59 +08:00
浅念 2b1f91762b fix(management): 评审修正——config_json注解对齐NOT NULL+补3个约束测试 
- EmployeeScoreConfig.config_json 去掉 | None,注解与 DDL(nullable=False)一致
- 删测试死 import datetime as dt
- 补约束测试: metric_daily 复合PK防重/ call_daily PK防重/ config_json NOT NULL
  (JSON 列 Python None 序列化为 'null' 字符串,测 NOT NULL 须 sa.null())
- EmployeeScoreConfig docstring 补 JSON 列整列重赋值注记

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 12:24:02 +08:00
浅念 e0c764997f feat(management): 批次A六表模型——fact/宽表/通话小表+评分配置/快照/辅导 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 12:04:54 +08:00
浅念 2b516362cd fix(names): 会话/统计弹窗/zip 文件名的共享好友昵称读 link 快照 
用户报 Lily 聊天窗口「聊天好友」列表里 A**郑 显示成 wxid_ir6uxy2li8no22
——A**郑是 14 个员工共享的客户,档案行(customer 全局单行 last-wins)挂在
别的员工名下,按 owner 查档案查空,三个显示位回退 wxid:

- sessions._meta(会话列表名字/头像/delete_flag)
- staff_chat_stats._customer_names(五数字弹窗明细)
- chat-html-zip 文件名

统一改为优先 customer_account_link per-owner 快照(link 未覆盖回退档案,
空表过渡安全)。staff_stats(统计分析新客户等)仍是档案口径,属分析语义
另行评估。613 测试绿(新增会话共享好友昵称 2 例)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-09 11:44:58 +08:00
浅念 d42895337d feat(link): customer_account_link 账号↔客户多对多——共享好友员工维度对齐云客 
用户报「Lily 好友数 36,点进员工客户页只有 12」。真机探明根因:那 24 个
是共享客户(同一人加多个员工),云客 per-employee 各算一个;而 customer
表 PK=friend_id 全局单行、归属 last-wins,其他员工名下必然「消失」。
抓取器本身每员工都拿全了(日志 declared=36 rows=36),丢在入库模型层。

- 新表 customer_account_link(渠道×账号×客户一行,per-relation 快照:
  昵称/备注/头像/手机号/收发计数/最近沟通/add_time/fromType/isDel)
- 写:repos.upsert_customer 随档案同事务维护(所有好友抓取路径一处挂全);
  新增 prune_customer_links 对账
- 读:/api/customers?owner_account_id= 改读 link(与云客 contacts_num 口径
  一致);该账号 link 为空时回退档案路径(过渡安全);与 dept/user 等
  过滤组合时维持旧行为;CustomerOut 透传 from_type
- 抓取器:friends/wa-friends 逐员工整批 upsert 后按名单对账(取满声明
  total 才删,防半份名单误删)
- 前端:StaffFriends 数据来源列优先 link 的 from_type

611 测试绿(link 新 6 例);本地验证空表回退/造数接管/from_type 透传。
上线后需重跑 friends+wa-friends 回填 link(存量关系无法从档案反推)。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-08 17:17:06 +08:00
浅念 2e526cd056 feat(staff-friends): 员工客户列表独立页——对齐云客员工详情,好友数/微信群数下钻 
员工列表点「好友数」原先跳全局 /customers?owner_account_id=x,布局与全局
列表无异且计数/分页绑全局声明口径(同日 dfa4fdd 修的显示 bug),与云客
「员工名下客户列表」体验割裂。新页 /staff-friends/:ownerId/:tab:

- 微信客户/微信群两 tab(对齐云客截图);标题=员工显示名(入口直带,
  直链经 /api/accounts 解析),返回箭头回员工列表
- 搜索(昵称/微信号/备注名/手机号,服务端 q)+ 查询/导出 CSV
- 发送/接收条数=Customer.send_num/receive_num 累计值(CustomerOut 补
  两列,同步自云客 friend 记录,与截图同源)
- 勾选批量「导出聊天记录」:新端点 GET /api/export/chat-html-zip,复用
  chat-html 渲染器每会话一个 HTML 打 zip(文件名=备注>昵称>friend_id,
  非法字符清洗;单会话 5000 行截断告警;一次上限 50 会话防误选打爆)
- 行内:查看聊天记录→staff-chat;导出HTML聊天记录(时间范围弹窗)
- WA 行保持原入口(该页暂仅微信)

后端 605 测试绿(zip 新 4 例);本地浏览器端到端验证:过滤 9 条/勾选
激活/群 tab/返回箭头;zip 产物 application/zip 双会话双气泡。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-08 16:14:44 +08:00
浅念 9d3cc8e76e fix(messages): 聊天记录大对话超时——DESC首屏+keyset游标+群聊直达索引 
用户报:聊天记录多时「聊天记录加载失败：请求失败 (ECONNABORTED)」(2026-09-07)。
服务器 EXPLAIN ANALYZE 实测两级根因:
- 单聊 1 万条:ASC 末页 OFFSET 10486 逐条回表 2515ms(DESC LIMIT 15ms,167 倍);
- 群聊 16,290 条:查询刻意不带 owner(chat_group 去重后 owner 错位),现有
  (channel,owner,room,timestamp) 索引被 owner 挡住,退化到 room 单列索引+
  filter+filesort——count 4.7s/首页 5.1s/末页 10.7s;真凶群 53132846289@chatroom
  40,863 条,三段串行 ~40s 必撞前端 axios 15s 超时。

修法(不动共享 MySQL 配置,沿用既往修复模式):
1. 迁移 e6f7a8b9c0d1:message 补 (channel, room_id, timestamp) 索引,群查询
   seek+排序直达+覆盖 count;模型侧双声明防 autogenerate 反 DROP。
2. /api/messages 加 order=asc|desc(默认 asc 不变)与 before_ts/before_id
   keyset 游标(成对,单传 422)——排序列 (timestamp,msg_id) 全序,平手按
   msg_id 决胜,游标页恒 O(page_size)。
3. 前端 ChatMain/ChatTimeline 首屏改「order=desc 取最新 50 反转」单请求
   (原 page1 拿 total+深 OFFSET 末页两请求),「加载更多」改游标上翻;
   hasMoreOlder=已加载<总数。SessionPane 搜索等 order=asc 默认路径不受影响。

本地实测(37,532 条群):desc 首页 0.39s、游标上翻 0.24s,浏览器真机
渲染+上翻 150 条无错。测试 8 增(desc/游标/平手边界/422/窗口叠加/
前端流程不变式),全量 601 绿。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 16:59:04 +08:00
浅念 085a9b4fd3 feat(analytics): 管理层指标呈现——首响回复率上墙/客户资产总览/自定义日期/排行五新列 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 14:41:08 +08:00
浅念 feb3b98665 feat(analytics): 首响时长+回复率数据管道——消息串算法/日汇总扩展列/员工聚合 
批1(A1+A2):管理层要看「每个人的响应质量」。

- 迁移 d9e0f1a2b3c4:msg_daily_stats/stat_daily_staff 各加
  cust_threads/threads_answered/fr_sum_ms(NOT NULL server_default 0,
  幂等守卫照 9b0d0c133035 惯例;models.py 双声明同步)
- summary.py _thread_stats:串=客户连续消息不被员工消息打断的段,
  is_send=None 不参与串判定;fr=员工首条回复−串末条客户消息;
  日切近似 v1(日末未闭合串计 threads 不计 answered,口径写进 docstring)
- recompute_days/recompute_all 都先按 ts 排序再算串(乱序防护)
- staff_summary 聚合三列按账号→员工累加(fr_cnt≡threads_answered 不单列)
- 测试 +10:串算法矩阵 9 例+staff 聚合传递;全量 589 绿
- 本地 86 万行回填验证:daily-stats 60s/staff 10s,rollup 总和与
  明细完全一致,随机 5 行 SQL 独立复算全对

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 14:13:09 +08:00
浅念 bbfad520f2 feat(analytics): 员工排行条形图对比+近30天范围——幅度一眼可读/本地停更窗口也可用 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 13:43:23 +08:00
浅念 1aadc80d6b feat(analytics): 看板v2全平台口径——默认双渠道合计/拆分小字/双线趋势/跳转带query预选 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 12:20:18 +08:00
浅念 487f45b074 feat(analytics): 看板管理化补强——员工活跃排行表+预警行动入口卡片 
管理者反馈「纯汇总数字看不到有用信息」:overview 载荷扩
staff_ranking(全员行:msg_total rollup 优先/空表回退 msg_daily_stats
聚合,active_* 两路径统一走 msg_daily_stats 窗内 distinct peer——
stat_daily_staff 的 active_* 是当日快照,跨日 SUM/MAX 语义皆错;
call_cnt 按 user_id 落窗直查;环比同期对齐)+ actions(该回未回 2h/
真流失 30d/敏感词 pending,复用已测试查询路径各取 total)。

前端看板:toolbar 下三张可点行动卡(0 灰显仍可点,直达处置页,
随 channel 切换刷新)+ 趋势卡下员工排行表(max-height 420 滚动,
未映射小 tag,环比色同卡片惯例 None 显 '-')。

测试 574→577 全绿(rollup 聚合/回退/行动计数三新);build 过。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-07 11:48:24 +08:00
浅念 8499a74a72 fix(analytics): run_full水位前置防回填窗口漏扫+README/DEPLOY/脚本号收尾 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 23:27:41 +08:00
浅念 f839a6db20 docs(analytics): tick docstring锁竞争与时区措辞修正+测试名对齐4job 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 21:14:52 +08:00
浅念 6b99202e9b feat(analytics): 4h 调度分析链+CLI 回填+full_sync 夜间自愈步 
- scheduler: yunke_analytics_tick job(与消息增量同节奏 IntervalTrigger),
  _analytics_tick 纯 DB——stat_daily_staff 滚动3天刷新 + 敏感词增量扫描,
  不抢 _page_lock 无子进程,异常只记日志不断链;today 用 time.time()
  UTC epoch 喂 day_key,规避服务器非上海时区的 naive now 误判
- cli: staff-daily-stats(全量重建 rollup,幂等)+ sensitive-scan
  (默认增量水位扫描,--full 首跑建水位/新词回填历史;description 明示
  加词不回填历史)+ 幂等补种起步词库
- full_sync_all.sh: daily-stats 后追加 staff-daily-stats(rollup 随
  msg_daily_stats 重建同步自愈)
- 测试: tick 行为测试(今日 seed→stat_daily_staff 出行)+ 异常吞噬
  (monkeypatch 抛错不外抛);同步更新注册断言(3→4 jobs)

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 21:02:41 +08:00
浅念 6a1c904018 fix(analytics): 命中处置ids上限+disposition枚举校验+排序断言 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 20:51:32 +08:00
浅念 6e67e9e631 feat(analytics): C1 命中列表默认过滤+批量处置 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 20:37:44 +08:00
浅念 956f243fce fix(analytics): 扫描器水位>=/无水位自卫/迟到测试判别力/分片flush 
Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-04 20:30:34 +08:00