存储与会话查询：结构化数据的两个后端

示例本次示例：模型查历史会话

# 模型：session_query({query:'上次那个目录整理的会话'})
# → tool-session-query（1444 行）→ SessionQueryEngine（session-query/src/index.ts:81）
# → SQLite 索引（session-query-sqlite）检索标题/内容
# → 返回匹配会话列表（id、标题、时间）
# 索引数据从哪来：消费 session/event 异步构建（20 页的查询侧）
# → 模型引用某会话 → 恢复/读取该会话日志（20 页恢复路径）
# 注意：索引最终一致（30 页易错点）——刚写的事件可能还没进索引

# storage（sqlite 后端）服务于随机读写：
# 某插件缓存「上次选择的模型」到 storage
# 重启后读回——与 20 页 JSONL 的追加日志互补：
# 日志是事实（可重放），storage 是派生（可重建）

§1挂载条目

• session-query-sqlite → dsh-session-query-sqlite——SQLite 查询索引（20 页的「查询侧」）
• session-projection → dsh-session-projection——会话投影（把日志投影成结构化的 UI 视图）
• storage / storage-json / storage-sqlite——通用存储 seam（部分在 profile 层追加挂载）

§2包文件地图

§3机制：存储 seam 与查询引擎

1. storage = 通用结构化存储：sqlite/json 两个 provider，同一 Storage 契约。它服务于需要「随机读写」的插件（设置缓存、索引），与 20 页的 JSONL 追加日志互补。
2. session-query = 会话检索：把会话日志同步进 SQLite 索引，支持列表/搜索（标题、时间、内容）。查询引擎的 Definition 依赖 sessions 服务（82 行）。
3. tool-session-query = 模型的检索工具：模型可以查历史会话——这是「跨会话记忆」的一种实现。

§4关键代码

81export abstract class SessionQueryEngine extends Service {
82  static inject = ['sessions']

47export class Storage extends Service {

§5易错点