Fold the persistence interface into dsh-session
将持久化接口合并进 dsh-session
`dsh-session-persistence` is a Service Definition package whose main concepts are already owned by `dsh-session`: `SessionHeader`, `SessionEvent`, `SessionId`, `session/event`, and `session/flush`. The package adds the abstract `SessionPersistence` service, the shared write coordinator, and contract helpers. Provider packages depend on it, and `agent-loop` has to optionally find a sibling service for resume. The capa
English
Problem
dsh-session-persistence is a Service Definition package whose main concepts are already owned by dsh-session: SessionHeader, SessionEvent, SessionId, session/event, and session/flush. The package adds the abstract SessionPersistence service, the shared write coordinator, and contract helpers. Provider packages depend on it, and agent-loop has to optionally find a sibling service for resume.
The capability-seam split made sense when persistence was a new swappable backend design. After the mutable summary was removed, the Service Definition package mostly wraps the session log's own storage concern. Keeping it separate may be more ceremony than clarity.
Proposal
Move the abstract SessionPersistence service, the coordinator, and persistence contract helpers into dsh-session. Keep JSONL and SQLite as separate backend packages that register the session-owned service. This preserves backend swappability while deleting one support package and one cross-package boundary.
The implementing PR should update the capability seams guidance with the exception: persistence is not like bash or LLM because its vocabulary and lifecycle events are already the session package's core domain.
Acceptance criteria
@deepseek-ai/dsh-session-persistenceis removed as a package.dsh-sessionexports the persistence service type, coordinator, and contract helpers.- JSONL and SQLite backend packages depend on
dsh-sessiondirectly. agent-loopresume uses the session-owned service key.- Session persistence, shared persistence write coordinator, and package docs explain why backend implementations remain separate.
What we give up
dsh-session becomes heavier: it owns both the in-memory log and the persistence Service Definition. That is the trade. If third-party persistence backends were already a public ecosystem, the separate Service Definition package would be a cleaner SDK boundary; pre-release, the extra package looks like abstraction before there is an external Consumer.
中文
问题
dsh-session-persistence 是一个 Service Definition 包，其核心概念已经由 dsh-session 拥有：SessionHeader、SessionEvent、SessionId、session/event 与 session/flush。该包额外添加了抽象的 SessionPersistence 服务、共享写入协调器和约定辅助工具。提供方包依赖它，为实现恢复，agent-loop（智能体循环）还需要按需查找这个同级服务。
当持久化还是一个全新的可替换后端设计时，能力 seam 的拆分是合理的。但在可变摘要被移除之后，这个 Service Definition 包基本上只是包装了会话日志自身的存储职责。继续保持独立可能带来的仪式感多于清晰度。
提案
将抽象的 SessionPersistence 服务、协调器和持久化约定辅助工具移入 dsh-session。JSONL 和 SQLite 仍作为独立的后端包，注册由会话包拥有的服务。这样既保留了后端可替换性，又删除了一个支撑包和一条跨包边界。
实施 PR（Pull Request）应更新能力 seam 指南，补充此例外：持久化不同于 bash 或 LLM（大语言模型），因为它的词汇和生命周期事件本就属于会话包的核心领域。
验收标准
@deepseek-ai/dsh-session-persistence作为包被移除。dsh-session导出持久化服务类型、协调器和约定辅助工具。- JSONL 和 SQLite 后端包直接依赖
dsh-session。 agent-loop的恢复功能使用会话包拥有的服务键。- 会话持久化、共享持久化写入协调器与包文档说明后端实现为何仍保持独立。
放弃了什么
dsh-session 变得更重：它同时拥有内存日志和持久化 Service Definition。这就是代价。如果第三方持久化后端已经形成公开生态，独立的 Service Definition 包会是更清晰的 SDK 边界；但在预发布阶段尚无外部消费方时，这个额外的包更像是过早引入的抽象。