v0.2.0 — SQL 直查 / 自动接入 / 决策置顶 / 记忆质量修复

v0.2.0 — 这一天半的工作都在这里

把只存在于一台机器上的成果同步进仓库。全部结论来自真实记忆库实测，不是推断。

简报取数：SQL 直查优先，CLI 兜底

不再起 srelay 子进程，改用 node:sqlite 只读打开 relay.sqlite。冷路径约 5ms、热路径约 1ms，子进程要 310–360ms。查询条件、排序、JSON 展开、origin != 'workflow' 排除、project_id 解析、两种 limit 语义逐条复刻自核心库；selftest 第 8 节断言两条路在真实库上逐字段一致、渲染出的简报正文逐字节相同。

node:sqlite 走 createRequire 懒加载——它只在 Node ≥ 22.5 上有，22.x 还要 --experimental-sqlite 标志，而 engines 允许 ^22.19.0。顶部静态 import 会让整个插件在 Node 22 上加载失败，而不只是关掉快速通道。

SRELAY_BRIEF_FORCE_CLI=1 可强制走旧路做对照。

新文件夹开箱即用

以前只有含 .git 的目录才自动建库，所以一个不带 git 的文件夹会被告知"说一声接入"——与"新建工作区就能用"的预期相反。规则改为黑名单制：临时目录、DSH 自身安装目录、npm 全局根、盘符根排除，其余全接。ZCode 侧 hook 用同一套黑名单，改规则要两边一起改。

init 实测 190ms / 166KB，且可逆（删 .sessionrelay/ 即彻底消失）——这正是能自动化的前提。绑定到已有库不可逆，所以那件事仍然是两段式。

srelay_init 工具

"说一声我就执行 srelay init"这句话以前是空头承诺——插件根本没有能建库的工具。现在有了。单步执行而非两段式，因为建库可逆。它还会给已存在的库补上缺失的 dsh 采集源，所以存量坏配置能被修好，而不是被报成"已经建过了"。

决策置顶

简报只有 2 个名额且按时间倒序，三个月前拍板的架构选择永远排不上。decisions JSON 加了 pinned 字段（不改表结构）；置顶条目豁免 48h 新鲜度窗并排最前，DSH 插件侧与 ZCode hook 侧同样生效。新增 srelay pin / srelay unpin。置顶在版本重算后依然存活。

记忆质量

简报此前在放技能目录垃圾：<system-reminder> 块和 - \skill-name`: 描述行被当成决策——因为它们出现在 user 消息正文里，按角色过滤拦不住。提取现在会剥掉注入块，决策带[MM-DD]` 日期。142 会话真实库实测：注入污染 19 → 0，重复率 17% → 0，简报最近 10 条从"全是目录垃圾"变成"带日期的真决策"。

项目判定

agent.session.header.cwd 成为主信号——DSH 直接把会话创建时的绝对工作目录交出来，按 agent 隔离。env 变量降一级，slug 反解变成兜底。三个真实工作区验证过。

测试

selftest 从 40 条长到 90 条。第 0 节是测试文件的自检：断言每个路径字面量仍是 X:\ 形态且真实存在，且判定行只出现在文件末尾。这两条都曾是真缺陷——六处路径字面量的反斜杠被 JS 转义吃掉，退化成盘符相对串按进程 cwd 解析，导致同一条断言在作者副本通过、在集成副本失败，区别只在于测试从哪个目录跑；而中间的判定行意味着后半段全崩也照样打印 PASS。

realboot.mjs 启动真实的 dsh-system-prompt 服务而非 stub——text provider 返回 Promise 会崩 renderPrompt 这件事，就是这样观测到的，不是推断的。

包

name 统一为 dsh-srelay-brief，与 cordis.patch.yml 和安装说明一致（此前声明的是 @crx1146/dsh-sessionrelay，与自己的 patch 文件互相矛盾）。files 白名单补上了漏掉的 src/brief-sql.mjs——照旧清单打出来的包会加载 index.js 然后解析不到 SQL 通道。

附件说明

vendor.tar.gz（19MB）是本插件自带的 srelay 运行时：dist/ + 全部依赖 + 8 个平台的 better-sqlite3 原生 binding + 中文分词词库。仓库里不放它（62MB 二进制进 git 就永久留在历史里），需要的人下这个附件解压到仓库根目录即可。

没有 vendor 时插件不报错，只会静默回落到全局 npm 的 srelay。如果那份是上游原版，你会遇到"一切正常但简报永远空"的半失效状态——这正是本项目花最多力气修的那类故障。