Idea: 让右侧 details 列可叠加（按面板 id 分发），给树外插件一个常驻面板的扩展点

[aitiandi]

树外插件（以 dsh plugin --profile web add 装进 profile 的 bundle）目前没有办法在右侧拿到一块自己的常驻面板：

• details 是 kind: 'single' 的会话槽，被 ui-chat 的 DetailsPanel 占用，且它在内部声明了 conversation.details.tool。动态 entry 的优先级低于随产品发布的 entry，第二个注册赢不到 cell；即便赢到，也会连带删掉工具详情和那个座位。生成的 Client catalog 把该槽位标为 shadows-shipped-ui。
• shell.overlay 是根作用域、点击穿透、不参与列宽让渡、收不到会话标准 props，只能覆盖在对话上，不是并列一栏。

提议把 details 改成 keyed：一列多面板、按面板 id 分发。ctx.layout.openDetails(panel) 打开列并选中面板；ui-chat 的工具详情占固定 key tool，conversation.details.tool 子槽保留；注册新 key 的面板在它旁边新增而不是替换。关闭只清宽度、保留面板 id，因此关闭的列仍以零宽挂载同一面板，重开回到原面板，与现有行为一致。工具详情路径的可见行为不变。

已在 fork 上做成完整改动（含测试、重生成的 slot / inspect 目录、docs/subsystems/slots.md、Agent Note 及双语配对），基于 master d347e70：

• 差异：master...aitiandi:deepseek-harness:chengcaiyi/keyed-details-column
• 带说明与验证记录的评审页：feat(client): dispatch the details column by panel key aitiandi/deepseek-harness#1

公开仓库不接受外部 PR，所以放在这里。如果维护者愿意收，我可以按你们内部流程整理成需要的形式。

[argszero]

The pain is real — I've hit exactly this wall as an out-of-tree plugin author (I maintain several @deepseek-ai/cordis-plugin-* community packages). The current constraint is precisely as you describe:

• details is kind: 'single' and ui-chat's DetailsPanel owns it (packages/client/ui-chat/src/client/apply.ts:169 mounts DetailsPanel at the conversation.details slot, with an internal 'conversation.details.tool': { kind: 'single', scope: 'session' } child at :166).
• The SlotKind union (packages/client/ui-slots/src/index.ts:90 = 'single' | 'list' | 'keyed' | 'chain') is merge-extensible and SlotMap is an empty interface SlotMap {} (:26) — so the slot-id namespace is designed to be widened by third parties, but the details entry itself is a single seat that a lower-priority dynamic entry can't win without displacing the tool-details seat.

Your keyed proposal is well-fit to the existing seam, and ctx.layout.openDetails(panel) as a display/selection API (rather than a replacement) is the right shape. Two things I'd flag from the plugin side:

1. A keyed details is exactly what "resident panel" plugins need. I have plugins that want to surface a persistent side panel (e.g. live session/run diagnostics, an agent-status strip) but the only out-of-tree options today are shell.overlay (root-scope, click-through, no column width, no session props) — which can't be a real side panel. A keyed slot with per-panel-id dispatch + width handoff would give them a first-class home.

2. Keep the tool-details seat backward-compatible. The 'conversation.details.tool' child (:166) is a fixed single sub-slot; keeping it with a stable tool key (as you proposed) preserves the existing tool-detail behavior with zero visible change. That's the right call — it means the migration is additive (new keys add panels next to it) rather than a breaking change for ui-chat.

The fact that you've already built the full change (tests, regenerated slot/inspect dirs, docs/subsystems/slots.md, an Agent Note, and the bilingual pair) on master puts this in great shape for review. From a plugin-author standpoint this would be a genuinely enabling change — it's the difference between "an overlay you can't style into a column" and "a real panel seat." Happy to review the fork if it's pushed anywhere.

[aitiandi]

Thanks — that's a useful confirmation, and both of your flags are decisions the branch already makes.

The fork is pushed:

• Branch: https://github.com/aitiandi/deepseek-harness/tree/chengcaiyi/keyed-details-column
• Diff vs master: master...aitiandi:deepseek-harness:chengcaiyi/keyed-details-column
• Single commit 03db176a, based on d347e703.

1. Resident panels. That's the driving case — the first plugin that needed a seat here is an out-of-tree office-workflow web plugin installed as a profile bundle, and it hit exactly the shell.overlay wall you describe: root-scoped, click-through, outside the column grid, so an occupant neither takes part in the width concession solve nor receives the session standard props a details panel reads. openDetails(panel) writes both halves — a closed column takes the contract default width, an open one keeps the width the user dragged, and the panel id is written on every call, so switching panels doesn't resize the column.

2. The tool-details seat stays put. ui-chat registers under key: 'tool' and names 'tool' at its own openDetails call site; the conversation.details.tool child (:166) is untouched inside that entry. Same panel, same width transitions, same mounted-at-zero-width close — closeDetails() still only zeroes the width and keeps the id, so the closed column keeps its body mounted exactly as the single-occupant column did. Both literals are pinned by tests.

Three things worth surfacing for a plugin author, since they're the parts a reviewer would otherwise have to dig out:

• openDetails(panel: string) takes a required argument. Defaulting it would name one package's key from inside ui-layout, which doesn't know ui-chat — defaulting belongs at the caller that owns the key.
• The 'tool' literal is deliberately written out rather than shared through a constant. scripts/slot-walk.ts reads a registration's key only when it is a string literal, so a constant erases already taken: tool from the generated key domain and drops key 'tool' from the occupant row — precisely the facts you'd consult before choosing an id. (settings.plugin.item shows the cost of the other choice: its cards register under namespace constants, and its catalog row still claims none of its keys are taken.)
• One sharp edge: replaceRisk stays shadows-shipped-ui on the slot, because the generator computes it per slot rather than per key — so every keyed slot with an occupant carries it, tool.call.toolview included. The per-key truth you actually need is in keyDomain and the slot JSDoc. And naming an id nobody registered opens an empty column rather than failing; the frame deliberately doesn't grow an occupancy query for it.

I'm not opening a PR — CONTRIBUTING is clear that external pull requests aren't being accepted right now, so this stays a discussion plus a fork branch. Review on the branch is very welcome.

[aitiandi]

Update, and a correction to my own reply above: this landed upstream while the thread was open, and my comment cites code that is gone. apply.ts:169, conversation.details.tool, openDetails() — none of those are on master any more. @argszero, please don't spend time on the fork branch; it edits an API that no longer exists.

Two commits did it, both within two days of this thread opening:

• 9241e10a (2026-09-07) feat(layout): add responsive right column and width concessions — details became rightbar, openDetails() became openRightbar(track, fullscreen).
• 581803bf (2026-09-08) feat(client): add global sidebar panels — 'main' became kind: 'keyed'.

The right column is now a docking-kit pane system, and the keyed dispatch this thread asked for is in it — one layer further in, and with more than I proposed. The header of packages/client/ui-sidebar-right/src/client/contract/slots.ts states the part that settles this thread:

sidebar.right.pane.tab is how a tab type contributes a body. It is keyed by the type definition's id, so adding a type is a registration, never an edit here. The key domain stays the open string space because a tab type may ship from outside this repository.

So the seats a resident-panel plugin now has, without any change to the tree:

• sidebar.right.pane.tab — keyed, session scope, tabInfo hook. A tab type registers under its definition's id through the tab registry and receives every tab of that kind, in every pane, docked or floating. sidebar.right.pane.tab.title is the optional companion for what the chip shows.
• sidebar.panellist (list, root) + 'main' (keyed, root) — the other shape: a sidebar icon whose list id addresses a full centre panel.
• sidebar.right.tab.menu.item extends a tab's actions menu; sidebar.right.tab.guide is a chain for replacing the guide body without replacing the tab.

That answers both of the flags in the comment above, and answers them better than the migration I proposed: nothing has to displace a shipped seat, and an out-of-tree panel is the designed case rather than a workaround. Withdrawing the proposal — the branch is 1301 commits behind and edits an API that is gone, so I am not rebasing it.

Thanks for the careful read. Sorry it pointed at a moving target.