dsh-workbuddy-xdpool 1.0.1 → 1.2.0

package/CHANGELOG.md

@@ -4,6 +4,108 @@
 
 版本号遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
 
+## 1.2.0 (2026-09-23)
+
+把成长中心剩下的**八类客户端任务**也接进自动化。这些任务在任务中心里写的是「升级桌面客户端后点击某个入口」，听起来只有人坐在真实客户端前才能完成；实际上计分器看的是**行为事件流**，只要事件形状对、指纹对，任务就会涨进度。这一轮把每条链都在真实账号上跑通并回读确认了计分。
+
+### 新增的任务链
+
+| 任务 | 积分 | 判据 |
+| --- | --- | --- |
+| 探索优秀灵感 | +100 | `web_element_click` + `playbook_cta_click` + `playbook_prompt_send` 事件组（「发提示词」才是判据，不是卡片曝光） |
+| 使用 5 个模板 | +100 | 五组 `agent_task_created_with_template` + `template_used`，判据是**五个不同模板**，所以一次要发五组 |
+| 尝鲜热门技能 | +100 | 真实对话（**服务端** requestId）+ `skill_info`（润泽小馆·日报撰写），响应要标成 `finishReason: tool_calls` |
+| 体验「和平精英」主题 | +100 | `appearance/set` 存主题 + `appearance_skin_apply` 事件，两者缺一不可 |
+| 体验资料库 | +100 | 走 **web 指纹**上报 `library_doc_intro_click` |
+| 召唤 5 次专家 | +100 | 专家市场真实 id + 召唤链 + 带 `X-Expert-Id` 的真实对话 |
+| 召唤 3 次专家团 | +100 | 同上，`expert_type=team` |
+| 体验轻量云专家 | +100 | 同上，但用事件要 `mode: LOCAL`、`type` 留空、`cost=0` |
+
+### 这一轮踩到并修掉的两个坑
+
+**专家链之间必须留间隔。** 连着发两条专家使用，计分器会判成**同一次会话**，只涨一个进度。实测：间隔 300 毫秒时两条链只计一条，拉到 6 秒后每条都计。专家任务因此改为链间固定 6 秒（`EXPERT_SUMMON_GAP_MS`，测试里置 0）。
+
+**三类指纹不能混用。** 计分器按任务认不同的指纹家族：`Library_read` 只认 web 指纹，用桌面指纹发同样的 `web_element_click` 会被接受然后丢弃。事件链现在自带「走哪个通道」，由调度器分流到 `reportDesktopEvents` 或 `reportWebEvent`。
+
+### 其它改进
+
+- 事件链从调度器里搬到了独立的 `task-events.ts`：调度器决定**什么时候**发，这个模块决定**发什么**，每条链都是纯数据，好读也好测。
+- `WorkBuddyScheduler` 及其常量现在从包入口导出，方便直接写脚本验证，不用绕过卡片走 HTTP。
+- 新增 64 个测试（`task-events` 21 个 + 调度器链路 22 个 + 专家间隔等），全量 134 个通过。
+
+### 已知限制
+
+- **`Expert_team_use_3` 有个号停在 2/3**：该账号当天已用掉两次专家团，第三次不再计分，换未用过的专家团也不涨。怀疑是该任务对单账号有当日额度，跨天恢复，暂未确认。新账号不受影响（实测 0/3 → 3/3）。
+- **`Expert_Philanthropy` 不做**：需要真实捐款，没有可绕过的路径。
+- **`black_cat` 不做**：只在 23:00–08:00 计分，且纯对话无收益。
+- **`Model_chat_GLM5.2` 与 `wb_wechat_oa_subscribe_task` 未接入**：实现路径已明确（前者要真实 glm-5.2 对话 + 对齐模型字段上报），留下个版本。
+
+## 1.1.0 (2026-09-23)
+
+新增**积分自动化**：插件可以在后台替你完成成长中心的日常动作，不用每天手动点一遍。
+
+### 它是怎么工作的
+
+开启后，调度器每分钟醒一次，到点就跑当天的任务，每个任务每天只跑一次（按本地日期记「今天已跑」，过零点自动重置）。四个任务各有独立的执行时段，默认这样安排：
+
+| 任务 | 默认时段 | 做什么 |
+| --- | --- | --- |
+| 每日签到 | 09:00 | 领取当天签到奖励 |
+| 活跃上报 | 10:00 | 上报一次对话活跃 |
+| 任务奖励 | 11:00 | 报名开放任务 + 领取已达标的奖励 |
+| 连登奖励 | 12:00 | 连登档位兑换 + 抽奖（本轮先占位，下轮接入） |
+
+**为什么上报排在任务之前**：上报会点亮成长中心的任务进度，后跑的任务那一趟才能读到刚涨上去的计数。顺序反了就会出现「进度明明到了却没领到」。这不是随手排的，是实测出来的。
+
+### 一、任务中心自动领取
+
+每个账号走一遍：拉任务列表 → 把还没报名的任务批量报名 → 把已达标的奖励逐个领掉。卡片上汇总显示本次领取了几个任务、加了多少积分。
+
+两个动作都是**幂等**的，重复跑不会重复入账：报名对已报名的任务返回成功，领取对已领过的返回 `already_claimed` 并记为成功。所以某个账号中途失败、下一轮重跑是安全的。
+
+### 二、活跃上报
+
+按客户端 `chat_request_send` 事件的完整形状上报（37 个字段），而不是只发最小几个字段——上游对「字段不全」的表现是**返回 200 然后静默丢弃**，所以字段必须发全，且必须带 `userId`。
+
+上报成功后会回读连登天数做验证。这里有两个实测踩到的坑，都已规避：
+
+- 连登接口的路径**不带 `/v2` 前缀**（和任务的 `/v2/activity/growth/*` 不一样）。用错前缀不会 404，而是返回一个没有 `streak` 字段的响应；
+- 天数藏在 `data.streak.days` 里，读平铺的 `data.days` 会永远得到 0，从而把每一次成功的上报都误报成「静默丢弃」。
+
+另外，连登计数是**异步写入**的：上报后立刻回读可能还是旧值（实测某账号上报瞬间读到 0、一分钟后读到 1）。所以回读为 0 时只记一条提示日志，**不重试**——上报本身按天幂等，反复重发只会浪费每天一次的名额。
+
+### 三、只碰该碰的账号
+
+- **国际版账号全部跳过**：global 域没有成长任务体系，调用只会产生噪声。
+- **你在卡片上关掉的账号跳过**。
+- **正在冷却的账号跳过**。
+- **一个账号失败不影响其他账号**：出错的那个跳过，继续跑下一个，并在汇总里记下失败数量。
+
+账号之间默认间隔 800ms 串行执行，避免一排账号同时打上游。
+
+### 四、卡片上的自动化面板
+
+账号卡片新增「积分自动化」区块：一个开关控制总开关，开启后才展开显示各任务的执行时段和上次执行结果（日期 · 成功数/失败数）。
+
+开关默认**关闭**——后台自动发请求这件事应该是你主动开启的。关闭状态下不会发起任何后台请求。
+
+### 配置
+
+配置项 `automation`，对应卡片上的开关：
+
+| 字段 | 默认 | 说明 |
+| --- | --- | --- |
+| `enabled` | `false` | 总开关 |
+| `checkinHours` | `[9]` | 签到时段 |
+| `reportHours` | `[10]` | 上报时段 |
+| `taskHours` | `[11]` | 任务时段 |
+| `streakHours` | `[12]` | 连登时段 |
+| `exhaustCooldownMs` | 30 分钟 | 账号额度用尽后休息多久 |
+
+### 实测结果
+
+在真实账号上验证了完整链路：4 个国内账号各领到 1 个任务，合计 **+600 积分 +23 能量**；紧接着再跑一次，四个账号全部领取 0、入账 0，确认幂等。上报后任务进度确实从 3/5 涨到 5/5，验证了「上报点亮任务」这一步是真的。
+
 ## 1.0.1 (2026-09-23)
 
 修复两个用号逻辑上的缺陷，并把账号卡片重新排了一遍。