[Idea] conversation.input.model.label 建议由 single 改为 list：多连接器插件共存时该槽位会导致功能静默丢失

[dingminhua]

背景

这是一个可复现的槽位设计问题，不是某个插件的 bug。三个社区连接器插件（WorkBuddy / Trae / Qoder）在同一 profile 下共存时，功能会静默丢失，并且三方已经被迫陷入优先级竞赛。

我这里是 WorkBuddy 的作者，但下面的结论对三方都成立——换个顺序，失效的是别的插件。

---

问题

conversation.input.model.label 被声明为 kind: 'single'，但它的真实使用场景是多个连接器插件各自装饰自己的模型行（WorkBuddy / Trae / Qoder 等，每个都注册 provider + 模型目录）。在 single 语义下只能有一个注册生效，其余静默失效，且没有任何报错。

结果是同一类功能在插件之间变成优先级竞赛，且每轮都要读别人的源码来确认自己排第几。

实测：三个插件的优先级演进

@deepseek-ai/dsh-client-ui-renderer 的 scoped-slots.tsx：

if (spec.kind === 'single') {
  const entry = host.entriesOfSlot(slotKey)[0]   // 只取优先级最低的一条
  if (!entry) return entries.length > 0 ? deadCell() : <>{opts?.fallback ?? null}</>
  return guarded(entry, entryKeyOf(entry))
}

这个组件被调用 N 次（每个模型行一次），而不是每行各有一个组件。所以胜者独自负责画所有插件的行。

本机实测（同一 profile，三个插件同时安装）：

插件	版本	期间	优先级	状态
dsh-connect-workbuddy	5.20.19	初始	-0.5	输给 qoder
dsh-connect-qoder	1.20.1	初始	-1	赢
dsh-connect-trae	4.14.2	初始	-0.25	输
dsh-connect-workbuddy	5.20.19	第一次调整	-100	赢
dsh-connect-qoder	1.20.1	跟进	-101	赢
dsh-connect-trae	4.14.2	跟进	-102	赢

三方代码里都把对方的名字和优先级写进了注释，说明这是被迫的军备竞赛，不是个别插件的选择。例如 qoder 的注释：

必须小于 -100，那是 workbuddy 的 MODEL_LABEL_PRIORITY。宿主的 single 槽只渲染一条注册，按 priority 升序取首条（小者先）。所以「排在哪」就是「能不能被看见」。

trae 的注释：

Re-measured from the three plugins' sources: dsh-connect-qoder-client priority -101 / dsh-connect-workbuddy-client priority -100 / dsh-connect-trae-client priority -0.25 ← never rendered.

用户可见的后果

优先级垫底的插件，其促销胶囊、负载图标、新模型标记在模型选择器里一次都不出现，而设置卡片里正常显示，因此用户报告的是「胶囊为什么没了」，且没有任何日志可查。

现有的两个「解法」都不可取

1. 胜者替所有人画（qoder / trae 的做法）

胜者用 slots.entries() 找到别人的组件并代渲染。问题：

• 这是在读取并驱动另一个插件的实现，两插件必须同时正确才不崩；
• 必须合成对方的 t 席位（slots.bindLocale(entry.locale)），一处不对就抛错；
• 对方组件如果带自己的 hooks / 上下文，还要小心不要混进自己的 hook 序列（qoder 的注释专门讨论了这一点，改用 jsx(Other, …) 让它在自己的 fiber 里跑）；
• 对方更新了 props 契约，代渲染方就静默错位。

2. 各自实现「超集」

即每个插件都画出所有其他插件的信息。这在信息上不可得：WorkBuddy 知道促销活动的数据结构，Trae 不知道 Trae 之外的字段，反之亦然；而且每方都要无限追赶别人的新功能。

二者都不是插件应该承担的责任。

建议

把这个槽位从 single 改成 list。

宿主已经实现了 list（每行一个 id 单元、各自 shadowing），机制是现成的。改成 list 后：

• 每个插件只画自己的行，不需要知道任何别的插件；
• 不需要读别人的注册、不需要合成别人的 props；
• 优先级只决定同一 id 内的遮蔽，不再是「谁独占整个格子」；
• 垫底不再意味着「功能消失」，而是「这条装饰不显示」——两者语义不同。

如果 list 的多个贡献者在同一行（同一个 provider/model）上都想画东西，那才是真正需要叠加语义的场合；可以用 chain，或由 list 的 order 决定顺序并全部渲染。

环境

• DSH: 0.2.2-rc.1
• 槽位声明：packages/client/ui-model-selection/src/client/index.ts:176
• 渲染实现：packages/client/ui-renderer/src/client/scoped-slots.tsx（if (spec.kind === 'single')）

补充

同类问题还有一处：conversation.input.model（父槽位）也是 single，dsh-codex-subscription 以 priority: -10 接管它后，若注册时不声明 children，宿主就不会注入 renderSlot，导致它下面的整个子槽位树永远不被渲染。该插件的 bug 已单独报给作者（它是可以修的），但这里同样说明：一个连接器插件接管父槽位，会让所有下游装饰插件一起消失——根因仍是槽位类型不合适。

[argszero]

Thanks — the mechanism you measured is right, and I can confirm it on both faces: the source tree at fcc0ad4621 (the merge that carries dsh-v0.2.2-rc.1 = 2f97f60455, so unchanged since you filed this) and the shipped 0.2.2-rc.1 tarballs. Your reading of scoped-slots.tsx matches the artifact line for line.

What is legal here, and why none of the three plugins gets an error

register() treats cell occupancy as a clash only at the exact priority — packages/client/ui-slots/src/index.ts:1254 with its comment at :1318 ("a cell's winner is its first occurrence"), and the hint it appends says "register at a different priority to shadow it (lowest renders)". The ledger is sorted priority-ascending for every kind, ties keeping registration sequence (:1322). So a -100 / -101 / -102 ladder is a legal outcome, not a bug in any of the three plugins.

The drop is in the projection, not the registry: for single every entry shares one cell (undefined), at ui-slots/src/index.ts:1403, so the first in priority order is the only head and every other registration is discarded. Silently — there is no log, at any verbosity. That absence is why three authors are reading each other's priorities out of source and writing each other's constants into comments.

One thing worth adding to your report, because it raises the severity: the winner paints for every provider, not only its own. The slot is rendered once per label instance — ModelSelect.tsx:468 (trigger), :494 (menu current value), and :599 inside group.models.map, i.e. once per model row — and renderSlot consults the owner's fallback only when the cell is empty, not when a component declines (scoped-slots.tsx:1341-1342; shipped @deepseek-ai/dsh-client-ui-renderer@0.2.2-rc.1 lib/client.js:1174). So a winner that suppresses itself for foreign providers does not get the catalog name back — it gets a blank label. Every row of every other provider becomes the winner's responsibility to draw. That is the "super-set" burden you describe, imposed by the contract rather than chosen.

single → list is not sufficient

This is my reading of the renderer, not a maintainer decision:

list renders every surviving row in one fragment per render call (scoped-slots.tsx:1384-1418), and the fallback is per call, not per row — it is consulted only when the row set is empty (:1403; shipped lib/client.js:1220). Since the label slot is one call per model row, changing the kind alone gives you: every model row paints all three decorations, including rows belonging to a provider that none of the three owns; and a plugin that returns null for foreign providers leaves those rows blank for the reason above. It also pushes a new obligation onto all three plugins — list requires options.id (ui-slots/src/index.ts:1267), and a same-id collision becomes a mount-time throw instead of a shadow. That trades one visible bug for another; it does not end the race.

The kind that matches the intent is keyed

keyed dispatches per instance by the owner's entryKey, and falls back per cell: scoped-slots.tsx:1346-1347 (shipped lib/client.js:1178). With key = provider.id, each row paints exactly its own provider's decoration, no competition (each key is its own cell, so priority stops deciding visibility entirely), and a provider with no contribution gets the owner's fallback — the catalog name and badge, exactly as today.

This is already the shipped pattern for per-item decoration, not a mechanism anyone has to invent: contextMenu.icon is { kind: 'keyed' } (packages/client/ui-context-menu/src/client/index.ts:40) and its owner calls renderSlot('contextMenu.icon', {…}, { entryKey: action.icon.key }) (packages/client/ui-context-menu/src/client/View.tsx:27). conversation.chat.node, conversation.chat.text-interaction, conversation.user.text.node and main are the same shape.

Minimum core change

Two edits and one log line:

1. packages/client/ui-model-selection/src/client/index.ts:176 — declare the label { kind: 'keyed', scope: 'session', inline: true }.
2. packages/client/ui-model-selection/src/client/ModelSelect.tsx:413-415 — pass { entryKey: provider.id } as the third argument, so each instance states which cell it wants.
3. ui-slots/src/index.ts register() — for single cells only, one warning naming both registrants and both priorities when a second registration lands in the occupied cell. single is the one kind where a second entry in a cell is always a drop: keyed and list differ by key/id, so a second entry there is a different cell, not a loss. That keeps the warning precise and quiet, and it fires exactly where a plugin's work is being thrown away — the difference between a one-command diagnosis and three plugins reading each other's source.

For the stacking case you raise: if several contributions really want to draw on the same row, that is a second seat, not this one — list with order, or chain with select, on a child of the label. Keying the label by provider keeps the two intents from sharing a cell.

Why no plugin can carry this: the declaration is in ui-model-selection and the dispatch is the owner's own renderSlot call, so shadowing ctx.slots.entries from a plugin would change behaviour only under the plugin that installed it — every other plugin on the machine would still be dropped. Both halves are core.

On your parent-seat note

You are right, and the reason is worse than "the plugin forgot". A seat's children table is declared by whichever registration carries it (ui-slots/src/index.ts:1280), and a second registration carrying the same table throws — "already declared" (:1284). So once ui-model-selection has declared the label and options children, a takeover can only register without children — and since the child renderSlot calls live inside ModelSelect, which no longer renders, the children stay declared and are never painted. The only takeover path the registry leaves open is the broken one. conversation.input.model is single too (ui-conversation/src/client/contract/slots.ts:362, apply.ts:473), so this is the same root shape one level up; it needs its own fix — children must not be tied to whichever entry wins — and the kind change above does not cover it.

Scope of what I measured

Measured: the tree at fcc0ad4621, and both shipped tarballs — @deepseek-ai/dsh-client-ui-model-selection@0.2.2-rc.1 with the declaration at lib/client.js:2067-2069 (kind: "single" at :2068) and the paint call at :1445; @deepseek-ai/dsh-client-ui-renderer@0.2.2-rc.1 with the single branch at lib/client.js:1174 and keyed at :1178. Not measured: I did not run a client with the three connectors installed, and I have not read their sources, so my claims about them are limited to what the host contract permits.

[dingminhua]

I'm one of the three plugin authors in the original report (dsh-connect-workbuddy). Adding one thing that the analysis above does not cover, because it changes what "minimum core change" has to include.

The keyed direction is right — I verified it from the plugin side

We independently reached the same conclusion and have already shipped it: all three connectors now read ctx.slots.spec(key)?.kind at mount and register per-provider-id seats when the declaration is keyed, falling back to the historical single seat otherwise. One build serves both host lines, so the host can flip the declaration without a coordinated plugin release.

keyed genuinely removes the competition: with key = provider.id each provider's row finds its own cell, and priority stops deciding visibility entirely. list cannot express this (it renders every surviving row per call, and the label slot is one call per row), and chain cannot either — it elects one winner via select(), which is single with a different tie-breaker.

What the change list is missing: a third edit, on the plugin side

keyed requires options.key. From the installed ui-slots:

case "keyed": {
  if (options.key === void 0) throw new Error(`keyed slot "${options.name}" requires options.key`)

Every shipped third-party contributor registers a keyless entry, and that is the natural thing to write under single, where key is meaningless because the cell is always undefined. All three of ours do:

ctx.slots.register({ name: 'conversation.input.model.label', priority: -105 }, WorkBuddyModelLabel)

And all three wrap that call in a swallowing try/catch, because inject() may defer the callback and a deferred throw is re-raised from a queueMicrotask, out of reach of any call-site catch (this is the bug dsh-connect-trae shipped as issue #74).

So a declaration-only flip — edits 1 and 2 without a plugin-side change — makes every existing contributor throw keyed slot … requires options.key, and the user sees the label simply vanish with one console.error line that they will never look at. That is quieter than the current failure mode, not louder: today a loser at least renders nothing predictably; after the flip there is an exception nobody surfaces.

I confirmed both directions against the real SlotCore, so this is not a reading of the code:

• keyless seat on a keyed host → keyed slot "…" requires options.key
• second keyed seat on a single host → single slot "…" already has a registration at priority … (i.e. the reverse mistake also bites, which is why one build cannot hardcode either shape)

Suggestion: ship a migration path with the kind change

Options, roughly in order of how much they protect existing installs:

1. Reserve the undefined cell for keyless entries. A keyless registration lands in its own cell rather than throwing, and logs a one-time deprecation naming the registrant. Old plugins keep working, new ones get keyed cells, and nothing is lost in the transition.
2. Warn instead of throw for one release. keyed accepts a keyless entry, renders it in a reserved cell, and logs. Same effect, less machinery, but leaves a permanently awkward cell in the model.
3. Document the break loudly and accept a window where third-party labels disappear.

I'd argue for 1 or 2. The whole value of keyed is that several contributors coexist; a migration that silently kills every existing contributor for one release works against exactly that.

If you'd rather ship it as a hard break, the CHANGELOG entry needs to say so explicitly and name the symptom ("labels disappear with no visible error"), because otherwise the first reports will be "the capsule is gone" with nothing to search for — which is the same class of report that started this thread.

Offer

Happy to run a preview build against the four checks we care about: three connectors plus the host's own deepseek-model-label-1017 in one profile, verifying (a) each row is painted only by its own plugin, (b) a provider with no contribution falls back to the catalog name + badge, (c) all three decorations appear simultaneously, (d) no clash warnings at --verbose.

Our diagnostic surface is window.__dshWorkBuddyModelLabel__ (slotKind / seats / verdict), which reports which declaration was read, how many seats were claimed, and whether they landed — useful for confirming (d) rather than inferring it.

---

中文摘要：keyed 方向成立，我们三家插件已按宿主声明在运行时自适应并发布。但改动清单漏了一条：keyed 强制要求 options.key，而所有已发布的第三方贡献者都注册无 key 条目（single 语义下 key 无意义），且都把注册包在吞错 catch 里。因此只改宿主声明会让存量插件全部抛 keyed slot … requires options.key，用户只看到标签消失、一行没人会看的 console.error。建议随 kind 改动一起给出迁移路径（保留 undefined 格 / 过渡期 warn / 明确写进 CHANGELOG）。

[argszero]

Thanks — you found the half my change list was missing, and you found it by driving the real SlotCore rather than reading it, which is the stronger evidence. I'll take your correction as the starting point instead of re-stating mine.

The break reaches further than third-party: the host's own documentation teaches the keyless shape.

Your argument runs from installed contributors ("every shipped third-party contributor registers a keyless entry", "all three of ours do"). I measured the host side, and it says the same thing about the slot's published contract. packages/client/ui-model-selection/README.md, under "Model label extensions", ends its integration instructions with the literal call it tells an author to write:

ctx.slots.register({ name: 'conversation.input.model.label' }, ModelLabel)

No priority, no key — the documented shape is a keyless single seat at priority 0. So a declaration-only flip does not only break your prior builds; it makes the package's own README wrong at the instant of the change, for every author who copies it afterwards, and their first symptom is a vanished label with one console.error. Whatever migration ships, the same commit has to edit that README section, because it is what people write from.

Two smaller confirmations from the same read:

• The blast radius is contribution-only — no host contributor is at risk. The only in-tree registration into the label slot is a doc-comment example (src/client/slots.ts:43); the host's real registration is one level up, into the parent conversation.input.model (src/client/index.ts:172).
• provider.id needs no declaration. keyProps (ui-slots/src/index.ts:123) is an optional per-key prop table, and register()'s keyed branch (:1259-1263) never consults it: it checks only that key is present and that the same key is not already taken at the same priority. So any key is admitted at runtime, which is what this slot needs — a keyProps table would have to enumerate provider ids in a type, and the host cannot enumerate third-party providers. Leaving it undeclared costs nothing either, because the label's props come from owner props (provider, model, placement, selected), not from a per-key share. And kind is a separate field of the spec, so scope: 'session' and inline: true are untouched by the change.

Your options 1 and 2 need one more edit than they state, and it is in the renderer, not the registry.

Reserving undefined for keyless entries stops register() from throwing, but a keyed slot dispatches by exact key match (scoped-slots.tsx:1346-1353):

const entry = host.entriesOfSlot(slotKey).find(e => e.options.key === opts?.entryKey)
if (!entry) {
  const occupied = entries.some(e => e.options.key === opts?.entryKey)
  return occupied ? deadCell() : <>{opts?.fallback ?? null}</>
}

A keyless entry's cell is undefined — entriesOfSlot computes it as plain entry.options.key (:1403) — and after edit 2 the owner always passes provider.id (ModelSelect.tsx:413-415), never undefined. So the reserved cell is unreachable for this slot: no dispatch site asks for it. Old plugins would stop throwing and start painting nothing, which is the same quiet outcome you object to, one layer down. The registry half alone converts "label wrong" into "label blank".

The missing piece is a miss path: when no entry matches entryKey, consult the reserved cell before the owner's fallback — one lookup in the if (!entry) arm above, gated on the kind so single/list are unaffected. With that, option 1 stops being a compromise and becomes behaviour-preserving, and the reason is stronger than "old plugins keep working":

• the reserved cell is deduped by entriesOfSlot to its first entry in priority order (:1397-1404, via seenCells), which is exactly the head single elects today;
• so an installed keyless contributor at -100/-101/-102 paints with its -100 build, on every row, identically to now;
• and a provider with no contribution at all still takes the owner's fallback — that path renders the full badge + name composition per row (ModelSelect.tsx:413-421 passes fallback at every call: trigger, menu current value, and once per group.models.map row), so check (b) of your four holds by construction once the miss path exists.

Without that line, your option 3 is the honest one: a hard break needs the CHANGELOG entry naming the symptom in the words you used, plus the README fix above. Your adaptive build does not close this on its own — it fixes new installs, and the break window is precisely installed old build × new host, which is the pair a reserved cell covers.

On the parent seat: you are right, and I understated it.

I re-read register() and reach your conclusion independently: children is walked per registration, and a second registration carrying an already-declared child table throws slot "…" is already declared (by …) (:1280, :1284). Because the child renderSlot calls live inside ModelSelect, a takeover that cannot carry children leaves them declared and unpainted — so the registry's only open takeover path for conversation.input.model is the broken one. That is a separate defect from the kind question, the kind change does not touch it, and I've recorded it as its own item rather than folding it into this thread's fix.

On your offer: yes, please run it — and add one check.

Your four are the right set, and window.__dshWorkBuddyModelLabel__ reporting slotKind / seats / verdict is a better instrument for (d) than anything I could read off the source. The check I'd add is the one that decides between options 1–2 and option 3, and it is not covered above: with the migration path in place, mount a keyless seat — an installed pre-adaptive build, or the literal call the README documents — against a keyed host, and read whether the label paints or merely fails to throw. Painting for every row is the intended compatibility (that is what single did). Painting nothing means the miss path is missing and the option has not done its job. Your existing (a)–(d) cannot distinguish those two, because all three connectors would be on the adaptive path.

One boundary, stated plainly so nobody waits on us: the whole fix is core — the declaration, the owner's dispatch, the registry warning and the renderer miss path all live in the host tree, and this repository's pull requests are closed, so it reaches the code through your maintainers rather than through a contribution from this account. What I can add is measurement and specification, which is what the above is.