2 Commits

Include renames

Author	SHA1	Message	Date
yml2213	253571730a	feat(account): 补上改备注接口，remark_changed 事件从此有发射点 ... `remark_changed` 此前是「定义了事件类型、但压根没有改备注的接口」，于是永远不发。 按 S4 的原则（留着一个永远不发的类型比删掉更糟 —— 看代码的人会以为它有数据）， 补接口而不是删类型。 ## 接口 `PUT /api/accounts/{id}/remark`，权限点 `account:remark`（授予 super_admin / operation / support，与 `account:tag` 一致）。 - 与改标签一样走 `record_account_action()`：**审计 + 账号时间线一次写完**， 审计带 `account_id`，事件 detail 带 `{from, to}`； - **只做单个、不做批量**：备注是自由文本，给一堆账号写同一句备注没有实际意义 （标签是短枚举才有批量）； - 内容 trim 后截断到 256（与 `accounts.remark` 列宽一致），清空也记一条事件； - 备注没变化时直接返回、**不写事件**：否则时间线会被「点开保存了一下但没改」刷满。 ## 权限点新增前的安全检查 新权限点会被 `custom_permissions` 覆盖，所以先查了库： `admin` / `kf1_test` 的 `custom_permissions` 是 **JSON null**（不是 SQL NULL）， Python 侧取出来是 `None` → `get_user_permissions` 走角色默认。 也就是说**没有任何用户在用自定义权限列表**，新增权限点不会把谁的能力锁掉。 （这一点很容易看错：`IS NULL` 判出来是「有自定义权限」，`JSON_LENGTH` 还是 1。） ## 前端 - 详情页「备注」一行改为可编辑（铅笔 → 输入框 → 保存/取消，回车即存）； - `EVENT_STYLE` 补 `remark_changed`，时间线里能看到备注的每次变更。 ## 一个自己踩到又修掉的坑 第一版把两个 `useState` 写在了 `if (!accountId) return <Empty/>` **之后** —— 正是本次会话刚在 LoginTasksPage 修掉的那类 hooks 顺序违规（`react-hooks/rules-of-hooks` 直接报错）。已上移到早期 return 之前的 state 区块。lint 抓到，构建不报，属于 「能跑但迟早炸」的那类问题。 ## 验证 - `TZ=Asia/Shanghai`：**426 passed / 6 skipped**（S4 后 420 → 新增 6 条） - `TZ=UTC`（相关文件）77 passed；ruff check/format 全绿 - 前端 `tsc -b && vite build` 通过、`npm run lint` 0 errors - 新增用例：写入并带 from/to 事件与审计关联、未变化不写事件、清空也记一条、 trim + 截断到 256、账号不存在 404、**新权限点确实在三个角色的默认权限里** （防止「加了接口但没人能用」）	2026-10-04 15:21:48 +08:00
yml2213	0a922ce56d	feat(account): S4 事件发射点补齐 —— 审计与时间线打通、批量事件、ck_invalid 只认转变 ... S3 让 `status` 可信，S4 让**时间线完整**：账号上发生的事，时间线里都能查到。 ## 补齐「定义了却从没发过」的事件 `assigned` / `tag_changed` 这两个类型早就定义了、前端 `EVENT_STYLE` 也渲染了， 但**全仓没有任何代码发过**（`grep` 只有定义处）。本次接上： - 单个分配 / 批量分配 → `assigned`（detail 带 assigned_to / assigned_username） - 单个改标签 / 批量改标签 / 按筛选批量改标签 → `tag_changed`（detail 带 from/to） ## 新增 `ck_cleared`，并修掉 `ck_invalid` 的刷屏 - **`ck_cleared`**：清 CK 是**不可逆**操作（重登当前成功率极低），时间线里却不留痕。 现在单个清除与批量清除共用 `account_lifecycle.on_ck_cleared()`。 - **`ck_invalid` 改为只在「由好变坏」时发**。旧实现每轮巡检只要判定 invalid 就发一条， 源码注释写着「避免每轮刷屏」，**但代码并没有做到** —— 6 小时一轮、失效一周就是 28 条一模一样的事件。判定失效是**一次状态转变**，不是每轮读数。`error`（查不到） 同样不改变结论、不发事件。 ## 审计与时间线一次写完（防漏一边） 新增 `audit_service.record_account_action()`：**审计 + 账号事件一起写**，并把 `account_id` 落到审计上。这两件事必须成对出现 —— 只写审计，时间线就缺「谁改了什么」； 只发事件，合规审计就缺一条。分成两次调用写，迟早有人漏一边（`assigned` 就是这么漏的）。 顺带把批量删除的审计补上被删账号 id（`detail.account_ids`，截前 200 条）： 删账号会**连带删掉它的事件时间线**（外键），审计是唯一痕迹 —— 这正是 10-03 那次事故要留的东西。 ## 批量操作不再逐条开 SAVEPOINT 批量分配/改标签可能覆盖几千个账号，而每个账号的时间线都该各留一条。 逐条走 `emit()` 会给每条开一个 SAVEPOINT，几千条时请求明显变慢。 新增 `emit_bulk()`：一次 executemany，整批包在**一个** SAVEPOINT 里， 与 `emit()` 一样**绝不抛异常**（整批失败就整批丢弃 + warning，不影响业务写入）。 ## 检测入口收口：4 处 → 1 个 `on_ck_verdict()` `ck_health` / 人工检测 / 工作台执行前检测 / 重登后复检 原本各自写 `ck_check_status` + `ck_check_result` + `ck_checked_at` + 发事件 + 调 `sync_status`， 口径容易分叉（`ck_invalid` 的刷屏就是这么来的）。现在统一走 `account_lifecycle.on_ck_verdict()`，顺序固定：**写结论 → 由好变坏记事件 → 重算状态**。 至此 `account_lifecycle` 成为**唯一**写生命周期字段的模块，并加了一条**源码扫描用例** 把它钉死（任何地方直接 `acc.status = ...` 都会让它红，并指出 file:line）—— 比写在文档里的约定可靠。虎牙的 `huya_accounts.status` 是同一个病，但属另一套模型， 已在用例里显式排除并注明。 ## 接口与前端 - 时间线支持 `?category=` 筛选（lifecycle / auth / business / ops）； 响应补 `category` / `subject_*` / `actor_*` - 前端 `EVENT_STYLE` 补上 `status_changed`（**S3 我漏的**：加了事件类型却没加样式， 页面上显示成原始英文）与 `ck_cleared`；时间线加「分类」筛选 ## 验证 - `TZ=Asia/Shanghai`：**420 passed / 6 skipped**（S3 后 404 → 新增 16 条） - 迁移链 3 passed；ruff check/format 全绿；前端 `tsc -b && vite build` 与 `npm run lint`（0 errors）均通过 - **两条关键用例都做过「反向验证」**（先注入旧行为确认会红）： - 把 `ck_invalid` 改回「每轮都发」→ 用例报 `3 == 1`； - 在路由里直接写 `acc.status = ...` → 不变量用例给出精确 file:line。 - 新用例还覆盖：批量分配/改标签逐账号发事件、清 CK 事件与审计关联、 `emit_bulk` 的跳过与容错、时间线分类筛选、批量删除的 id 留痕。 未做（后续）：S5 业务事实直发事件 + `douyu_tasks` 保留策略、S6 账号页重构 + `bind_status` 三列拆解。`remark_changed` 目前没有改备注的接口，故无发射点（已在文档标注）。	2026-10-04 15:09:46 +08:00