dsh-workbuddy-checkin
WorkBuddy 每日积分签到 — DeepSeek Harness 插件：读取本机 WorkBuddy 登录态（仅在内存中解密），查询并领取每日签到积分。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:leoc114119/dsh-workbuddy-checkin#cffc5a73b04555364520614589d9fd8f7bb1194eWorkbuddy Checkin 以 dsh-workbuddy-checkin 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
DeepSeek Harness 插件：给 DSH 注册一个 workbuddy_checkin 工具，读取本机 WorkBuddy 桌面端的加密登录态（只在内存中解密），查询并领取每日签到积分。
不是 WorkBuddy 插件，是 DSH 插件 —— 一个 npm 包，通过 Cordis 挂进 DSH 的插件树。
仓库：https://github.com/leoc114119/dsh-workbuddy-checkin
一行装：
dsh plugin --profile desktop add github:leoc114119/dsh-workbuddy-checkin
WorkBuddy 桌面端每天签到 +100 积分，但：
WorkBuddy / WorkBuddy AI）要分别点；$wbEncrypted 信封 + 两层密钥），直接读文件拿不到令牌。这个插件把这三件事包成一个工具，于是 DSH 里既能手动问一句，也能挂排程每天自动跑。
dsh plugin --profile desktop add file:/绝对路径/dsh-workbuddy-checkin
⚠️ 路径前必须带
file:。 裸路径会被 pnpm 装成link:符号链接，而 Node 解析依赖走 realpath —— 符号链接会让插件的@deepseek-ai/*依赖从你的源码目录往上找（那里没有），于是 DSH 只打一行workbuddy-checkin (dsh-workbuddy-checkin): failed to import，插件静默不生效。file:会让 pnpm 在 profile 的node_modules/里落地成真实目录，依赖查找才能沿 profile 往上 命中 App 运行时自带的@deepseek-ai/*。代价：file:是拷贝不是链接，改完源码要重装一次。
dsh plugin --profile desktop add dsh-workbuddy-checkin
dsh plugin --profile desktop add github:leoc114119/dsh-workbuddy-checkin
DSH 桌面端也可以在 设置 → 插件 里装，等价于上面命令。 装完在
~/.dsh/profiles/<profile>/package.json的dsh.profile.bundles里会多出dsh-workbuddy-checkin。
装好后模型就有 workbuddy_checkin 工具：
action | 作用 | 会不会改状态 |
|---|---|---|
status | 只读查询每个账号的签到状态 | 否 |
claim | 先查，未签到且有活动则领取 | 是 |
accounts | 列出本机发现的账号与各自 host（不联网） | 否 |
selftest | 只验解密链路（keyblob → 令牌 → host），不联网 | 否 |
account 参数可选，传账号名数组则只处理这几个。
包里带 bin，可以不经过模型直接用：
dsh-workbuddy-checkin status # 只读
dsh-workbuddy-checkin claim # 查并领取
dsh-workbuddy-checkin accounts # 列账号
dsh-workbuddy-checkin selftest # 只验解密链路
dsh-workbuddy-checkin status --json
dsh-workbuddy-checkin status --account workbuddy-desktop
环境变量：
| 变量 | 作用 |
|---|---|
WB_AUTH_DIR | 覆盖登录态目录（自动探测失败时用） |
WB_KEYBLOB | 覆盖 keyblob 路径 |
在 DSH 里建一条每天 08:00 的排程，提示词写：
调用 workbuddy_checkin 工具，action=claim，把每个账号的结果报给我。
排程到期会把提醒投进原会话，模型就会调这个工具 —— 不需要系统级定时器。
按优先级找第一个含 .info 的目录：
| 平台 | 路径 |
|---|---|
| macOS | ~/Library/Application Support/CodeBuddyExtension/Data/Public/auth |
| Windows | %APPDATA%\CodeBuddyExtension\Data\Public\auth |
| Linux | $XDG_CONFIG_HOME/CodeBuddyExtension/Data/Public/auth |
| 兜底 | ~/.workbuddy/auth |
敏感字段用 $wbEncrypted 信封加密，不是「一个全局密钥直接加密」：
~/.workbuddy/keyblob ← 每台机器一份，首次运行随机生成，mode 600
keyId: <本机数据密钥 ID>
slots[]: { type: "static-v1", protectorKeyId: <保护密钥 ID>, wrapped: <信封> }
← wrapped 是用「保护密钥」加密的本机数据密钥
所以流程是：用保护密钥按 framing="file" 拆开 keyblob.slots[].wrapped 得到本机数据密钥 → 再拿与信封 keyId 匹配的那把钥匙去解字段。
⚠️ 信封带
keyId，必须按 keyId 选钥匙。不能因为「开发机上恰好是保护密钥的 ID」就写死。
| scheme | 结构 |
|---|---|
| 对称（默认） | 载荷直接用数据密钥 AES-256-GCM 加密 |
asym-v1 | 随机 32 字节文件密钥加密载荷；文件密钥被包两次 —— userWrap（用使用者密钥，我们能解）与 developerWrap（RSA-OAEP，托管恢复用，读取时用不到） |
authorWrap / developerWrap 的存在意味着不需要任何私钥就能读自己的数据。
「该打哪个域名」从令牌自己的 JWT iss 推导，其次 auth.domain，最后才退回已知映射。账号文件名各版本/各渠道可能不同，写死必然漏。
POST /v2/billing/meter/checkin-activity-status。同目录的 checkin-status 是桩接口，对所有账号恒定返回 active:false / streak:0 / total_credits:0，会把「今天已签到」误报成「未签到」。active / activity_name / theme_name / season / start_time / today_checked_in / streak_days / total_credits / checkin_dates。不要用 daily_credit：真端点对所有账号恒 100、桩端点恒 0，没有区分力。eyJhbG…(1395 字符，已脱敏)）。claim 外所有动作都不发写请求。iss 推导出的官方域名。诚实分级：
| 结论 | 级别 |
|---|---|
| 解密链路（keyblob 两层密钥 → 令牌 → host） | 确定 —— 本机两个账号（workbuddy-desktop / workbuddy-desktop-ai）实测解密成功，与独立 Python 实现逐字段一致 |
| 状态查询 | 确定 —— 对两个真实账号真实请求，结果与 Python 版一致（一个 no_activity、一个 already_checked_in，连续 17 天 / 1700 积分） |
| DSH 挂载 + 工具调用 | 确定 —— 装进 profile 后 Cordis 成功挂载；headless 会话里模型确实调用了 workbuddy_checkin，返回上面两段真实结果（即本 README 的表格数据来源） |
asym-v1 信封 | 按源码实现 + 往返验证 —— 本机没有真实 asym-v1 样本，构造样例验证通过 |
| 真正领到一次积分 | 尚未 —— 本机账号当天都已签到 / 无活动，没有可领的机会 |
| 跨机器可用 | 未验证 —— 密钥层级按通用逻辑实现（按 keyId 选钥匙），但只在开发机上跑过 |
MIT © 2026 leochen