第三方宿主（Obsidian 插件）嵌入 DSH Web UI 的若干集成障碍：输入框无可编程写入接口、iframe 嵌入缺少支持的认证方式、插件注入消息缺少身份会污染会话、会话格式容错不足

[hjxcloud-tech]

背景：我维护 Obsidian 插件 dsh-harness（把 dsh web 的 UI 无痕嵌入 Obsidian 面板，并做双向桥接：在笔记里框选文字 → 生成隐式信息行注入聊天框 / 或直发会话）。不改 DSH 源码，走官方扩展机制（cordis 插件 + agent/pre-step 钩子 + 本地 /api）。实测版本 0.1.5-rc.1。以下四条是我们在真机上反复踩到、且有明确证据的问题。

1）聊天输入框（Lexical）没有受支持的"程序化写入"方式

现象：宿主需要把一段文本放进输入框（用户在编辑器里框选笔记 → 注入一行信息）。任何"整体替换"写法在 Lexical 上都会失败：
模型选区不跟随 DOM 选区：getSelection()+Range.selectNodeContents 全选后 document.execCommand('insertText', …) 实际落在模型光标（末尾），等于把原内容又插一遍 → 真机症状"输入框文字被复制"。
插入文本里的 \n 被规范化：隐式行与用户已输入文字粘成一行（无段落分隔），只能靠派发合成 beforeinput(insertParagraph) 才能造出真换行。
加"多策略 + 失败重试"后变成多轮重复插入；最终我们只能退化为"只追加、绝不替换"，牺牲了"新行置顶/替换旧行"的体验。
期望：提供一个受支持的写入通道，例如宿主侧可用的 composer.set(text) / insertText() 接口，或暴露 postMessage 握手；或者让 Lexical 遵循标准 DOM 选区与纯文本插入语义。
证据：dsh-panel-diag.log 实测（首帧容器 0×0 时 SPA 有 1.1 万字 DOM 却不绘制、以及一次 ob=false 渲染等）我们已在宿主侧绕开，但输入框写入仍无可靠解。
2）iframe 嵌入缺少受支持的认证方式（SameSite=Strict cookie 在跨站 iframe 中不可用）

现象：dsh web 打印 http://127.0.0.1:/?token=…；浏览器路径 GET /?token= → 303 + Set-Cookie dsh-auth-*; HttpOnly; SameSite=Strict，之后 / 与 /api 由 cookie 把关。宿主的 iframe 位于 app://obsidian.md（跨站）→ Strict cookie 不会带上 → 面板永远 401（"dsh web authentication required; reopen the URL printed by dsh web"）。
我们的绕行（全部在本地、无源码改动）：DSH 插件里为 GET /?token=&ob=1 直接放行 index；仅覆盖 401 判定以接受 Authorization: Bearer （fence 的 403 原样保留）；页面注入脚本给 fetch/XHR/WebSocket/EventSource 补凭证。
期望：官方支持"嵌入模式"，例如 ?embed=1 + 免 cookie 的 token 认证（Bearer），或一次 postMessage 握手把会话凭证交给 iframe。
证据（0.1.5-rc.1 实测）：GET /?token=&ob=1 → 200；裸 / → 401；POST /api/session/list + Authorization: Bearer → 200。
3）插件通过 agent/pre-step 注入消息时，缺 id/role 会让整个会话读不出来

现象：注入的消息若只返回 { source, content }，落盘成 user/message 后缺 id/role → 读会话报 session event at seq N lacks an identified message（真机 seq 23762 被我们实测到）。迁移链只给旧事件补 legacy-message::，运行期新注入的消息没人补。
另一个坑（修数据时踩到）：真机会话里只有 user/message 天然带 data.id/data.role（实测 4/4）；assistant/message 的 data 是 turn/step/message/usage，tool-call-chunks.id 是 chunk id。给其它类型补这两个字段会让 v0→v1 迁移直接拒收整个会话（refuses this format v0 Session: assistant/message N）。
期望：①在注入边界自动兜底补 id（类似官方插件里的 ensureIdentifiedMessage()，让第三方插件不可能写坏会话）；②文档明确"注入消息必须自带 id/role"；③读侧对缺失身份给出指明来源插件的可修复错误。
证据：我们的会话修复器（fixMessageIdentity，只作用于 user/message）在真实样本上 repair 后 check ok；范围放宽到 assistant 时立刻被迁移链拒绝。
4）会话容错与可修复性：一个非法字段会让整会话不可读，且缺少官方修复入口

现象一：第三方插件写了非法的 source.form（我们用过 'bridge-edit'）→ 迁移链拒收整个会话。合法值只有 instructions/catalog/snapshot/notice/relay/recall。
现象二：SESSION_FORMAT_VERSION 恒为 0 + 显式 v0→v1→v2→v3 链，实际漂移形态至少有：sourceEventSeqs 嵌套 [[a,b]] vs 稠密 [a,b,…]、subagent/descriptor.data.version 2→3。
现象三：会话文件是 多帧 zstd（首帧恰为一行 header + \n），而 Node 的 zstdDecompressSync 只解首帧 → 朴素工具会静默截断会话，第三方很难自己写对。
期望：①未知 source.form 等值保留并告警而非拒收整会话；②提供官方修复/迁移入口（如 dsh session repair）；③文档公开会话容器格式（多帧规则）或给出受支持的读写 API。

[Mide69]

这四条里，第 3 条（缺 id/role 导致整会话读不出来）我对着当前源码核实过，机制和你说的完全一致，而且比你猜测的更清楚一点。

packages/core/session/src/index.ts 的 append()，运行期插件调用 session.append() 写事件走的正是这条路径，只调用 validateSessionEventData() 和 surfaceManager.validateNext()，两者都不检查 user/message 的 id/role。真正做这项检查的是 assertMessageEventShape()，但它只在 adoptSessionEvent() 里被调用，而 adoptSessionEvent() 只在 packages/session/session-persistence/src/storage-contract.ts 第 95 行（从存储读回事件时）被用到。

也就是说，写入时完全不挡，读回时才用 lacks an identified message 拒收整个会话。这不是迁移链没补运行期新注入的消息，而是校验函数本身只挂在读路径上，append() 从未调用它。这个不对称应该可以在不碰迁移链的情况下修，给 append() 也接上同一个 assertMessageEventShape() 检查，或者一个专门给运行期注入用、能自动补 id 的辅助函数，这样第三方插件在注入时就会立刻收到明确错误，而不是等到下次打开会话才发现整段历史读不出来。你说的官方插件里的 ensureIdentifiedMessage()，目前源码里没有这个具体名字的函数，但你要的语义，注入边界自动兜底或立即报错，确实是目前缺失的一块。

其余三条，Lexical 程序化写入、iframe 认证、多帧 zstd 与格式容错，我没有逐条去核实，但整体看是一份少见的、把第三方宿主视角的真实摩擦点讲得很具体的报告，值得维护者认真看一遍。

[PerryLink]

四条逐条核实（master c291e79）。先给结论：第 3 条是确凿的写入侧缺陷且 master 未修；第 4 条机制属实；第 1、2 条是真实的宿主集成缺口，但属于需要官方支持的产品决策，下面给现状与可行绕行。

3）缺 id/role 写坏会话——属实，且根因可以更精确：packages/core/session/src/index.ts:710-740 的 append() 只调用 validateSessionEventData（surface.ts:140-167，仅检查 request/header 与 tool/result）和 surfaceManager.validateNext；消息身份检查 assertMessageEventShape（index.ts:328-359）只挂在 adoptSessionEvent（index.ts:166-172）上，而它仅在从存储读回时被调用（packages/session/session-persistence/src/storage-contract.ts:94-102）。因此运行期注入的 user/message 缺 id/role 时写入完全放行，下次打开才整会话拒读。插件作者现在就能做：注入消息必须自带 id、role: 'user'、source: { kind: <合法值> }。修法建议：让 append() 也走同一 assertMessageEventShape，在注入点即时报错——不需要动迁移链。

4）source.form 封闭集合属实：v0→v1 校验器只放行 ['instructions','catalog','snapshot','notice','relay','recall']（packages/session/session-format-v0-to-v1/src/payload-validation.ts:643）。多帧 zstd 属实：持久层是“拼接帧容器”（packages/session/session-persistence-jsonl/src/zstd.ts:2-5），首帧恰为一行 header（index.ts:74-77）；Node 的 zstdDecompressSync 只解首帧，自研工具必须像官方解码器那样按帧遍历（zstd-public-decoder.ts:9-30）。官方修复 CLI 目前不存在。

2）iframe 认证：cookie 确为 HttpOnly; SameSite=Strict（packages/client/connection/src/browser-auth.ts:122，README 有明文说明），跨站 iframe 必然 401；master 上没有 embed/token 认证模式，你们的本地绕行（放行 + Bearer + 注入凭证）目前是仅有的办法。是否提供官方嵌入模式需维护者决策。

1）输入框程序化写入：客户端契约面（packages/client/ui-conversation/src/client/contract/input.ts）没有 set/replace 文本的公开 API；现有机制只有内部仲裁与粘贴处理器，没有“整体替换”语义。作为特性请求留给维护者（注意：此处的“不存在”是契约面检索结论，若官方另有意向接口请以维护者答复为准）。

EN summary: Item 3 verified and still live — append() never runs the message-identity check (core/session/src/index.ts:739-740 vs 328-359), so plugin-injected messages without id/role silently corrupt the session until the next read; always stamp id/role/source. Item 4's closed form set and multi-frame zstd container are real (payload-validation.ts:643; zstd.ts:2-5). Items 1-2 are genuine integration gaps that need official support.