提议:把注入上下文文档升格为壳级投影(与轨迹视图同构),并稳定 event-id 供跨视图联动

[Happy2Git]

来源:dsh-compass 的实现经验 + 上游 master 代码对照。

一个观察

轨迹板块(ui-trajectory)是 dsh 投影哲学的完整体现:数据来自会话投影系统(session.getSnapshot().views + 壳的 loadOlder()),插件只注册五类渲染定义和一个 snapshot builder,自己不持有任何数据。

注入上下文文档(non-user 的 user/message,runtime 折成 context 节点)没有对等的投影出口。今天每个想要这块数据的插件都在自己过滤 durable log:compass 用插件自有的 /dir/injected-docs 路由做服务端过滤 + 客户端签名门控,实测在 18 万事件的会话上把每次激活约 120 MB 的历史页 JSON 降到 KB 级——能做,但这是每个插件各带一份投影代码的重复劳动。

提议

1. 把 injected-context documents 升格为壳级投影。 两种形态任选:
   • 按 conversationViews 的 definition 注册制开放一类 context view(插件注册渲染,壳计算投影);或
   • 提供一个官方过滤投影 API(等价于 compass 那条路由的能力:按 source kind 过滤、只发文本块、带 compaction 边界)。
2. 稳定 event-id 契约,供跨视图联动。 轨迹是"行为投影"(agent 做了什么),上下文是"状态投影"(模型此刻知道什么),两者读的是同一份 durable log。如果 seq/event-id 在视图间可互引,就能做"点轨迹某一步 → 该时刻的上下文快照"这类时间旅行式调试——这对长会话排障(为什么它忘了 X)是最直接的答案。

为什么值得收进壳

• 单一事实源已经是事实,差的是出口:投影逻辑留在插件侧意味着 fork/插件/未来第三方各算一遍,口径可能漂移;
• compass 的实测数据证明了过滤投影的量级收益(120 MB → KB 级/激活),值得上游一次性做对;
• 压缩边界(compaction checkpoint 的 seq)是两个视图共同关心的时间轴刻度,壳级出口是它成为公共契约的自然位置。

现成参考

• compass 的服务端过滤路由:dsh-compass/src/directory-routes.ts(/dir/injected-docs,有界、只读、失败即关闭);
• 客户端投影与签名门控:dsh-compass/src/client/read-context.ts + docs-stream.ts(仅在文档集合真正变化时重投影);
• runtime 已有的 provenance/form 读取器(contextProvenance/contextForm)就是投影口径的现成基础。

如果方向认可,可以先从最小的出口做起:把 compaction boundary + injected-docs 过滤读做成 runtime 客户端的一等 API,视图注册制作为第二步。