track

Files

duxingchen 192c8ee9cc feat(audit): 扩大 GET 采集范围 + 修正动作文案

【扩大采集：核心业务数据的「查看详情」】
新增 _TRACKED_READ_PREFIXES（notifications / tasks / orders /
products / records）—— products 是补的：GET /products/scan/{sn}（扫码查询）
是整个车间最高频的读操作，不采它等于没采"活跃度"。

_should_audit 的 GET 分支改为三级判断：
  敏感读(export/download/print) → 受跟踪前缀且非裸列表 → 否则不采

用 _is_bare_list 跳过「拉整个列表」：
  · 列表接口被前端高频轮询（消息、任务列表尤其明显），逐条留痕会让
    audit_logs 迅速膨胀，真正有价值的操作反而被淹没；
  · 只有「查看详情」(/tasks/{id}) 才代表用户真的点开了某条业务数据。
  判定用「去掉末尾斜杠后是否恰好等于某前缀」，天然排除查询串。

【修正文案】
- "read": "查询" → "查看详情"（前者易被误解成"随便搜了一下"）
- 新增 "mark_read": "标为已读"，并在 _SEGMENT_ACTION 补 "read" 映射 ——
  否则 PUT /notifications/{id}/read 会回退到 _METHOD_ACTION(PUT→update)，
  把"点开一条通知"记成"修改了某样东西"
- "refresh": "刷新令牌" → "上线"（token 2 小时一换，业务上视作一次上线）

⚠️ 两点须知：
1. notifications / orders 目录下【只有列表路由】，而列表按规则不采集，
   故这两个模块不会产生查看记录 —— 后端没有"查看单条消息"的接口。
   且消息列表被前端轮询，采集它反而会造成日志爆炸，跳过是正确的。
2. products 被纳入后，工人每扫一次码就多一条记录（50 人 × 每天数百次
   ≈ 上万条/天）。若嫌吵，去掉该前缀一行即可。

注：读接口鉴权已在上一提交补齐，故这些"查看详情"记录能正确挂上操作人。

2026-09-21 13:47:44 +08:00