插件生态诉求：官方侧边会话渲染面 / 快照字段稳定性承诺 / 只读权限 preset

[g-yixuan]

背景：生态里至少三套插件在自绘会话呈现层

我们是 dsh-sidenote 的作者（开源 MIT：侧边聊天 + 划选注释插件，g-yixuan/dsh-sidenote）。在开发「侧边面板与原生主对话对齐」的过程中做了一遍宿主侦察，发现插件生态有一个共同的结构性缺口：

• dsh-client-ui-conversation 的节点渲染器（工具卡 / 思考折叠 / 用户气泡等）只导出类型、不导出组件（包入口 value 导出仅 apply/inject/ConversationController）；
• slot 树是单 renderer、root-only，session-scope 槽位只服务主布局当前会话；侧栏是独立 React root，拿不到 renderSlot face——没有任何官方面能把原生会话视图渲染到任意 sessionId 的第二块屏幕上；
• 旁证：宿主自己的 subagent 会话也是 sessions.open 切主视图渲染 + composer 链拦只读，而不是并行渲染。

于是 better-sidebar 内置侧边对话、dsh-sidenote、dsh-sidebar-qa 等至少三套实现都在各自自绘消息呈现层——重复造轮子，且每家都会随宿主改版各自坏一遍。

三个诉求（按价值排序）

1. 官方「第二屏会话渲染面」

任选其一都能解锁整个生态：

• dsh-client-ui-conversation 导出 ChatView 系的节点渲染组件（或一个 <ConversationView sessionId> 级组件）；
• 或提供一个官方 mount 面：给定 sessionId + 容器元素，挂载一套原生会话视图（数据面 ctx.sessions.binding(id) 已公开，缺的只是呈现层）。

插件侧都在用宿主下发的 callView/resultView card union + ui-primitives 叶子块自绘——如果官方觉得「插件自绘呈现层」就是既定路线，也请明示，我们至少可以把稳定性寄托在 wire 契约上（见诉求 2）。

2. 快照数据面的稳定性承诺

插件的消息流渲染全押在这两组字段上：

• ConversationSnapshot.nodes / partial / runningCalls——类型里已标注 "Legacy top-level compatibility field"，看到新面 ChatSnapshot（locations/order）在建。求一个迁移节奏说明：legacy 字段计划保留到哪个版本？会不会静默移除？
• ToolResultNode.callView/resultView 的 card tagged union（generic/terminal/diff/search/read/web）——官方注释说 "a capable UI switches on card"，我们把这当公开契约在用；card 集合可扩展（"a new arm is a union edit"），插件会做好 default 降级，但求确认这条 wire 契约本身是稳定承诺。

3. 只读权限 preset（或旋钮级写面）

权限 preset 默认表只有 workspace-write / danger-full-access；read-only 是 sandbox 旋钮的合法值但没有默认 preset 包装，插件运行时也无法注册新 preset。侧边对话的典型产品语义是「问一下，不动手」（参考 Cursor side chats 默认只读、Claude Code /btw 禁工具）——插件想给 fork 出的侧边会话默认降权只读 + 用户一键放权，目前卡在无 preset 可切。求：默认表加只读 preset，或开放旋钮级（sandbox/mode）写面。

我们愿意贡献

如果方向得到认可，我们愿意按官方指的路形态贡献 PR（至少从诉求 3 这种小面开始）。三个诉求的证据链（包版本、文件行号、bundle 实证）都可以补齐。

Thanks for the great plugin architecture — the slot/service discipline makes third-party work genuinely doable. 以上只是想让它更进一步的生态反馈 🙏

[argszero]

Thanks for the reconnaissance — this is exactly the kind of structured ecosystem feedback that helps the harness mature. Three asks, and each lands on a different layer, so here's my read with the seams I've verified:

Ask 1 — official second-screen conversation render face (core gap, plugin-blocked today)

Your source facts check out: dsh-client-ui-conversation value-exports are only apply/inject/ConversationController (node renderers export types only), the slot tree is single-renderer/root-only, and a sidebar is a separate React root with no renderSlot face. The host is the renderer owner — no plugin can add this face, so this is a genuine core-side extension ask. The cleanest minimal shape is the mount face you named (ctx.sessions.binding(id) is already public; a <ConversationView sessionId> component or a mount API that attaches a native conversation view to an element). Worth filing as a proper upstream-fix candidate with your evidence chain; it would collapse three parallel self-drawn implementations (better-sidebar, sidenote, sidebar-qa) into one maintained surface.

Ask 2 — snapshot stability commitment (this one has a documented failure history behind it)

The honest contract picture: public APIs here are documented pre-stable (docs/architecture.md) — removal is legal, and the ecosystem has now been burned several times by removals that shipped with no signal at all: Session.events removed in the rc.1 refactor (broke an official hooks bridge — #5846), settingsNamespace removed from dsh-settings (#5363/#5599), assertNever dropped from dsh-llm's exports between published versions (#5854). Every one of those was only discovered by out-of-repo consumers at runtime.

So your ask for a commitment is well-founded, and I'd split it:

• "Legacy top-level compatibility field" + a visible ChatSnapshot successor: the type annotations are doing deprecation signaling already — what's missing is the removal policy. A reasonable pre-stable commitment: legacy fields stay at least N minor releases after being marked, and removals are announced (changelog + the removal-ledger the drift family keeps asking for). That converts "silent removal" (the actual pain) into "announced removal".
• The callView/resultView card union: this one is already an extensibility contract — "a capable UI switches on card" + "a new arm is a union edit". Additive arms are safe; your default-degrade posture is exactly right. I'd treat this wire shape as the more stable of the two and say so to your users.

This is a docs/policy-level ask — core-side, and the reply from maintainers ("pre-stable, no guarantees") vs a concrete deprecation window is worth getting on the record.

Ask 3 — read-only preset (plugin-shaped interim exists today; the registry gap is core)

Two axes are getting conflated here, and they matter for the fix:

• Tool-level restriction (what a "问一下，不动手" side chat really needs: no write/edit/bash-mutating/tool-calling tools visible). This is plugin-buildable today — @argszero/cordis-plugin-preset-tool-filter (npm, from #5786) restricts an agent's visible tool set at agent/created; a read-only profile = allowlist of read-only tools. Forking a sidechat with that filter gives the Cursor-side-chat semantics without any core change.
• Sandbox permission-preset registration (adding a read-only entry to the permission-preset default table, or runtime registration of new presets). That registry is closed — the escalation table only carries workspace-write/danger-full-access, and plugins can't register presets at runtime. That part is a core gap, and your instinct to start with ask 3 as a small PR is right — the read-only knob value already exists as a valid sandbox setting, so the delta is a preset wrapper + default-table row, not new enforcement machinery.

If you want to move on ask 3's plugin half today, I'm happy to help shape the tool-allowlist profile (and the read-only preset question is a good candidate to feed back as an upstream request with the preset-tool-filter pattern as the interim reference). For asks 1–2, the productive next step is a consolidated upstream-fix note with your evidence chains — plugin authors converging on one documented render face and one stability policy is worth more than three more parallel implementations.