[Bug] Message injected without producer-owned source.kind violates v4 format and drops sessions

[aavainer]

DSH version: 0.2.0 (Windows).

Symptom

Sessions fall into an orphaned turn (a turn/start is written, an inbox splice removes the message, but no step follows). The deeper, shared error behind it is:

format v4 message requires a producer-owned source kind

Root cause (found)

A third-party skill auto-injection plugin inserted <skill_content> into the conversation without a producer-owned source.kind. The v4 message format rejects such a message, and the session drops instead of continuing.

Facts

1. Three sessions fell while that plugin was active.
2. The same v4 violation also broke spawn teammate (identical "requires a producer-owned source kind" error).
3. Rolling the plugin back restored the sessions.

What this raises

1. Injection contract. Is there a documented requirement that any message injected by a plugin (skill bodies, etc.) must set a producer-owned source.kind? The plugin that triggered this was unaware of it.
2. Graceful handling. When a non-compliant message is injected, should DSH reject that one message (log + skip) rather than dropping the whole session into an orphaned turn that survives restarts?

The earlier framing ("message lost between inbox-splice and turn-processing") was wrong — that was a downstream symptom of the v4 violation, not the cause.

---

RU:

[Bug] Сообщение, инжектированное без producer-owned source.kind, нарушает формат v4 и роняет сессии

Версия DSH: 0.2.0 (Windows).

Симптом

Сессии падают в осиротевший ход (записан turn/start, inbox-splice вынимает сообщение, но шаг не начинается). Более глубокая общая ошибка за этим:

format v4 message requires a producer-owned source kind

Найденный корень

Сторонний плагин авто-инъекции скилов вставлял <skill_content> в диалог без producer-owned source.kind. Формат v4 такое сообщение отклоняет, и сессия падает вместо продолжения.

Факты

1. Упали три сессии, пока плагин был активен.
2. Та же v4-ошибка сломала и spawn teammate (идентичная ошибка «requires a producer-owned source kind»).
3. Откат плагина вернул сессии.

Что это поднимает

1. Контракт инъекции. Есть ли задокументированное требование, что любое сообщение, инжектируемое плагином (тела скилов и т.п.), обязано выставлять producer-owned source.kind? Плагин-триггер об этом не знал.
2. Мягкая обработка. При инъекции несоответствующего сообщения DSH должен отклонять одно это сообщение (лог + пропуск), а не ронять всю сессию в осиротевший ход, переживающий рестарты.

Прежняя формулировка («сообщение теряется между inbox-splice и обработкой хода») была неверной — это был вторичный симптом v4-нарушения, а не причина.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

你定位到的是有意设计的拒绝规则——所以修法在产出方，而在错误信息

1. 规则本身

packages/session/session-format-v3-to-v4/src/message-sources.ts：

function source(message) {
  const value = message['source']
  if (!isSessionFormatJsonObject(value) || typeof value['kind'] !== 'string'
      || value['kind'].length === 0 || value['kind'] === 'plugin') {
    throw new SessionFormatError('format v4 message requires a producer-owned source kind')   // :10
  }
}

同文件首行注释："Native source admission preserves unknown attribution and refuses retired plugin wrappers."

⇒ 也就是说：v4 明确拒绝 kind: 'plugin' 这种"已退役的插件来源形态"。你的第三方"技能自动注入"插件往会话里插了没有 producer-owned 来源的消息 ⇒ 命中这条规则 ⇒ 与你看到的落盘失败/孤儿回合一致。你的归因成立。

2. 因此"该改哪一边"是清楚的

• 产出方要改：那个注入插件必须给它插入的消息带上 producer-owned 的 source.kind（不能留空、也不能用 'plugin'）；
• 核侧能改的是诊断：现在错误丢掉了整批却不指名哪条事件。而 assertV4SourceRowAdmission(row) 已经拿到整行（:32-35 正按 row['type'] 分派：user/message / system/message / assistant/message / tool/result / agent/inbox/spliced / session/title-llm-request），真正抛错的 source() 只看到单条 message ⇒ "把 row type 带进错误"不需要新增数据流。

建议把诉求写成：

触发该 SessionFormatError 时，错误信息应包含该行的 type（必要时 seq）与来源插件标识，使产出方可被直接定位。

3. ⚠️ 一条你务必写进正文的坑（同族已证实）

已经落盘的那些坏行会一直失败——因为该检查发生在编码（encode）时，每次写事件都会重新校验到历史行。所以：

• 禁用那个插件不能救回既有会话；
• 只有清理那些行或给读取侧加容忍才能恢复；升级产出方只能防止新行出现。

这一条对用户最有价值，建议单独成段。

4. 版本提醒（本轮基线）

HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1
npm: alpha = 0.2.1-alpha.1    next = 0.2.0-rc.2    latest = 0.2.0-rc.2

你在 0.2.0 上复现 ⇒ 属当前发布线。⚠️ 注意 npm 的 latest 不再是旧的 0.1.5-rc.3（那是几周前的情况）。

一条边界

我确认的是该拒绝规则与其意图、"已落盘行持续失败"的成因、以及错误信息可增强的确切位置。那个注入插件的具体实现以你的排查为准——我没有核对该插件。

[xiaoshenming]

补两条和「产出方修」并列的事实，给以后遇到同样报错的人省一步。

1. 槽位对 kind 的要求不一样，量出来是这样（桌面端 0.2.0-rc.2 自带 reader，逐 kind 试，基线先验证通过）：

槽位	接受的 source.kind
user/message、developer/message	任意非空字符串，只要 ≠ 字面量 "plugin"
system/message	只有 system-prompt（别的报 message must have system-prompt source）
assistant/message	只有 model（别的报 message must have model source）
tool/result	只有 tool，且 message.toolCallId === source.callId

所以「注入的消息没带 producer-owned 来源」不一定只是少个 kind：带错 kind 同样整份拒读，而且报错串各不相同，搜错误串时容易以为是两个 bug。

2. 读盘有两道闸门，别只对一道：关系折叠的 assertV4MessageSources（对 KNOWN_SESSION_EVENT_TYPES 里每条都跑，source 非对象 / kind 缺失 / 空 / 非字符串 / 等于 "plugin" 都拒），以及 seed 构造 Session.fromRestore（上面那张槽位表就是它管的）。另外用 v3 的类型表去量会漏掉 developer/message —— 它不在 v3 清单里，整行被 continue 跳过，必须用 reader 自己那份 59 条表，否则会得出「developer/message 不校验来源」的错误结论（我先踩了）。

3. 已经存在盘上的这种行，现在能被报出来了：我们这边加了 producer-source-invalid（source 缺失/非对象、kind 缺失/空/非字符串/与槽位不符），报 seq + 具体哪个成员不对。只报告不写：kind 缺失时工件里没有唯一答案，写什么都是编。{kind:"plugin"} 那个退役字面量是另一条（v4-literal-plugin-source，可修，因为官方 producerKind() 是全函数）。

判定不是抄讨论：测试直接对发布包的两道闸门跑十组槽位×变体，断言「我们报 ⟺ 它们拒」，另外本机真实库里 4 条会话读数不变（没有误报）。

[aavainer]

Confirmed and acted on — thank you for pinning the exact rule (message-sources.ts rejects empty / non-string / 'plugin' kind).

One update on the gotcha: we scanned the three affected sessions for persisted bad rows and found zero — every source.kind is a valid producer-owned kind. So the injection was rejected at encode before persisting, the rollback fully recovered them, and no row cleanup is needed. We'll fix the producer to set a producer-owned source.kind going forward.

Your suggested diagnostic improvement (include row type + seq + the plugin identifier in the SessionFormatError) would have saved us a step — we'd support that upstream.

---

RU:

Подтверждаем и уже отработали — спасибо, что указали точное правило (message-sources.ts отклоняет пустой / не-строку / 'plugin' kind).

По gotcha: просканировали три затронутые сессии на persisted-плохие строки — их ноль, все source.kind валидные producer-owned. То есть инжект отклонён на encode до записи, откат полностью вылечил, чистка не нужна. Продюсер починим — будет ставить producer-owned source.kind.

Ваше предложение по диагностике (включить row type + seq + идентификатор плагина в SessionFormatError) сэкономило бы нам шаг — поддерживаем такой апстрим.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[aavainer]

Thanks for the measurement — the per-slot kind table (user/developer → any ≠ 'plugin'; system → system-prompt; assistant → model; tool → tool + callId match) and the note that the v3 type table misses developer/message are both very useful. Agreed that a wrong kind is a different failure from a missing kind, and the two error strings shouldn't be conflated. Appreciate the producer-source-invalid reporter work too.

---

RU:

Спасибо за замер — по-слотовая таблица kind (user/developer → любое ≠ 'plugin'; system → system-prompt; assistant → model; tool → tool + совпадение callId) и замечание, что v3-список типов пропускает developer/message, — очень ценно. Согласны: неверный kind — это не то же, что отсутствующий kind, и путать два сообщения об ошибке нельзя. Отдельное спасибо за reporter producer-source-invalid.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

先说一条：我上一轮给的规则引用是不完整的——'plugin' 并不是"一律拒绝"

1. 更正：存在一张改写表，未知插件会落到 plugin:<name>

packages/session/session-format-v3-to-v4/src/sources.ts：

/** Released V3 plugin names whose current producer kind is not the plugin string. */
const RENAMED_PRODUCERS = Object.freeze({
  'compact': 'compact-checkpoint',
  'tools-code-mode': 'ptc-mode',
  'tools-ptc': 'ptc-mode',
  'dsh-compaction-basic': 'compact-basic',
  '@deepseek-ai/dsh-system-prompt': 'runtime-context',
})                                                                     // :39-45

/** First-party V3 plugin identities that intentionally keep their current kind. */
const RELEASED_SAME_NAME_PRODUCERS = new Set([ … 26 个名字 … ])        // :48-56

function producerKind(plugin, role) {                                   // :59
  if (plugin === '@deepseek-ai/dsh-system-prompt' && role === 'system') return 'system-prompt'   // :60  ← **按 role 分支**
  const renamed = … RENAMED_PRODUCERS[plugin] …
  if (renamed !== undefined) return renamed                             // :62
  if (RELEASED_SAME_NAME_PRODUCERS.has(plugin)) return plugin           // :63
  return `plugin:${plugin}`                                             // :64  ← **兜底仍是 producer-owned**
}

并且 rewritePluginSource(source, seq, role)（:74，已导出）负责把这个改写落到 source 上（文档注释："Lift one released V3 plugin source into the current producer-owned shape"，并丢掉 plugin 字段）。

⇒ 所以我上一轮引的"kind 为空或等于 'plugin' 就抛"只是准入校验的那一半；完整规则是"先改写、后校验"，而且未知插件的兜底结果 plugin:<name> 是通过校验的。

2. 你（和 xiaoshenming）那张按槽位/角色不同的表，正对应 producerKind(plugin, role)

代码里槽位清单与你们的测量一致——mapEventMessages（sources.ts:12-36）逐槽映射：

user/message                                   → data                         // :18
developer/message · system/message · assistant/message · tool/result
                                               → data.message                 // :22  ← 含 developer
agent/inbox/spliced                            → data.inserted                // :27
session/title-llm-request                      → data.messages                // :27

⇒ developer/message 确实在清单里，而 :60 的 role 分支解释了"为什么各槽接受的 kind 不一样"。你们那张表是有代码依据的，建议把它与 producerKind 的三种结果对齐写进报告（这样就不是"实测经验"，而是"实测与实现互证"）。

3. 因此真正该问维护者的问题变了

既然存在改写表（且未知插件也会被兜底成 plugin:<name>），那么你们遇到的拒绝说明：

改写步骤在那条路径上没有发生——要么该行是在迁移之后才被写入的（新写入的 kind:'plugin' 不再经过 v3→v4 迁移），要么改写只覆盖"已发布 V3 包装"而你们的产出方形状不在其中。

建议把诉求改成这一句（比"请让插件改"更接近根因）：新写入的事件是否也应经过同一张改写表？若否，请在错误里说明"该来源未经过迁移"，以便区分"插件写错了"与"插件写法已过期"。

4. 附带一条对"错误信息"诉求的更新

sources.ts:103 的报错已经带 seq：

throw new SessionFormatError(`message source at seq ${seq} requires a nonempty kind`)

⇒ 也就是说"指名冒犯事件"这件事在改写/迁移那条路径上已经实现了。所以诉求应当收窄为：把同样的 seq 指认带到准入拒绝那条路径上（message-sources.ts 的 source() 目前只看单条 message）。这比"请加诊断信息"精确得多，而且是"照隔壁的写法补齐"这种低成本改动。

5. 版本

我核的是当前 HEAD（5badb15009 = dsh-v0.2.1-alpha.1）。⚠️ 注意 npm 的 latest 现为 0.2.0-rc.2、alpha 才是 0.2.1-alpha.1——不再是我早前说的"latest 停在 0.1.5-rc.3"。

一条边界

我确认的是改写表、role 分支、槽位清单、以及 :103 已带 seq（这些都直接读自当前源码）。**"为什么你们那条没被改写"**要看产出方写入时机——那属于你们的现场，我只能指出该问什么。

[xiaoshenming]

@PerryLink 三条核对：一条收窄你的第 2 点，一条改正我自己的数字，一条回答你的第 3 点。

1. 改写表只活在 v3→v4 迁移里；读盘路径没有改写这一步

所以「先改写、后校验」和「plugin 一律拒」不冲突 —— 它们说的是两条路。

• rewriteV3MessageSource( 在包里只有一个调用点，在 v3→v4 stage 的 transformRun 里（桌面 0.2.0-rc.2 的 lib/index.js:1492）。
• 读一份已经是 v4 的日志走 assertReleasedV4Relationships(artifact, knownEventTypes)（导出，桌面 :1027）→ 逐事件 assertV4MessageSources → source(message)。这条路上没有 rewriteV3MessageSource。

直接驱动那个导出函数实测（用 rc.2 的包；它与桌面 0.2.0-rc.2 的四段 md5 相同，见第 3 点）：

REFUSED    {kind:"plugin", plugin:"dsh-mnemon"}  => format v4 message requires a producer-owned source kind
ACCEPTED   {kind:"plugin:dsh-mnemon"}
ACCEPTED   {kind:"goal"}
REFUSED    没有 source
REFUSED    {kind:""}

⇒ 兜底 plugin:<name> 确实能过（你这条对），但字面量 plugin 在读盘路径上没有任何改写可依赖，是硬拒。

2. 你第 2 点建议收窄：槽位差异不是 producerKind 的 role 分支解释的

role 分支只覆盖一个特例（@deepseek-ai/dsh-system-prompt + role system → system-prompt）。而「system/message 只认 system-prompt、assistant/message 只认 model、tool/result 只认 tool」这三条是另一处按事件类型分派的守卫：@deepseek-ai/dsh-session 的 assertMessageEventShape（0.1.7-rc.2 的 lib/index.js:1166/1170/1174；桌面 0.2.0-rc.2 同一函数在 :1206/1210/1214，所以引用时别按行号跨版本套）。报错串就是 message must have model source 那一族。

两处都是真的，但不是同一条规则：producerKind 决定改写后写什么 kind，assertMessageEventShape 决定什么样的 kind 才算合法。「实测与实现互证」我同意一半 —— 那张表有代码依据，但不是 producerKind 的依据。

3. 改正我自己的数字（不是你的）

RELEASED_SAME_NAME_PRODUCERS 是 25 个。我 10-06 在 #6559 上写成「24 个」，是我数错；你写的 26 也不是。取块 md5 是 26ce3b5033bcdc83f291092680d72e88，0.1.7-rc.1 / 0.1.7-rc.2 / 桌面 0.2.0-rc.2（从 app.asar 按 header offset 抠出来再算）三份相同。我们那份修复表就是照抄它，测试直接驱动发布 stage 逐 name/role 比对，漂移会被测出来。

4. 你第 3 点那个问题，代码已经回答了：不经过

rewriteV3MessageSource 是 v3→v4 stage 的私有步骤，唯一调用点就在 transformRun 里。产出方在 v4 会话里写 {kind:"plugin"}、或干脆不写 kind，都不会被改写 —— 读的时候就是硬拒。

这正好对上 aavainer 的现场：拒载发生在 encode（行从未落盘），所以他们盘上实测零坏行、回滚插件后会话立刻恢复 —— 两件事互为印证。所以诉求可以比「请让插件改」更收窄：「v4 写入路径是否应复用同一张改写表；若否，请在错误里区分『来源未经迁移』」。你这个改法我同意。

5. 我们这边的定位

producer-source-invalid：source 缺失/非对象、kind 缺失/空/非字符串/与槽位不符 → 报 seq + 哪个成员不对，只报告不写（kind 缺失时工件里没有唯一答案）。字面量 {kind:"plugin"} 是另一条、可修（v4-literal-plugin-source），因为 producerKind 是全函数；修出来的形态就是第 1 节里 ACCEPTED 的那个 plugin:<name>。

---

EN TL;DR — the rewrite table runs only inside the v3→v4 migration (rewriteV3MessageSource has exactly one call site, :1492). The read path (assertReleasedV4Relationships → assertV4MessageSources → source()) never rewrites, so in an already-v4 file the literal plugin kind is a hard refusal while the fallback plugin:<name> is admitted (verified by driving the exported function). The per-slot kind rules live in dsh-session's assertMessageEventShape, not in producerKind's role branch. And the released same-name table has 25 entries — the "24" was my own miscount on #6559, corrected here.

[aavainer]

Thanks for the correction, both of you — that closes the loop precisely.

The RENAMED_PRODUCERS table (migration-only, single call site) + read-path hard-refusal of literal {kind:"plugin"} vs. admitted plugin:<name> is exactly consistent with what we saw on the ground: rejection at encode → zero bad rows persisted → rollback recovered. Our producer fix is now concrete: set source.kind = "plugin:<name>" (not the literal 'plugin', not empty).

Appreciate the depth — this is a better-asked question than we started with.

---

RU:

Спасибо за коррекцию обоим — это закрывает картину точно.

Таблица RENAMED_PRODUCERS (только в миграции, единственный call site) + жёсткий отказ read-пути от литерала {kind:"plugin"} против допускаемого plugin:<name> ровно согласуется с тем, что мы видели на месте: отказ на encode → ноль плохих строк на диске → откат вылечил. Фикс продюсера теперь конкретный: ставить source.kind = "plugin:<name>" (не литерал 'plugin', не пусто).

Спасибо за глубину — вопрос в итоге сформулирован лучше, чем был в начале.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

@xiaoshenming 的三条我核过了，其中两条是对我的更正 —— 先说清我错在哪，再补两个稳定锚点。

1. 我的第 2 点是错的

我上一条说"那张按槽位/角色的表正对应 producerKind(plugin, role)"，并把各槽接受 kind 的差异归给 :60 的 role 分支。这条不成立。 role 分支只覆盖一个特例（plugin === '@deepseek-ai/dsh-system-prompt' && role === 'system'）—— 一个 if 解释不了「system/message 只认 system-prompt、assistant/message 只认 model、tool/result 只认 tool」。按事件类型分派的地方确实在 dsh-session，不在这个函数里。你收窄得对。

2. 补上源码锚点（你给的是构建产物行号，且你自己提醒了不要跨版本套）

在 origin/master（d743267388 = dsh-v0.2.1-alpha.2）上，那处守卫的源码位置是：

• packages/core/session/src/index.ts:332 —— function assertMessageEventShape(event: Record<string, unknown>, subject: string): void
• :362 —— throw new Error(`${subject} message must have system-prompt source`)
• :368 —— throw new Error(`${subject} message must have model source`)
• :376 —— throw new Error(`${subject} message must have tool source`)

配套测试同文：packages/core/session/tests/session.spec.ts:351 / :363 / :387。调用点在本文件 :170 与 :275（seed 路径）。

这样引用就不必依赖任何一版的 bundle 行号了 —— 也正好呼应你那条提醒。

3. 表的大小我数错了

我写「26 个名字」，不对。packages/session/session-format-v3-to-v4/src/sources.ts:48-56 的 RELEASED_SAME_NAME_PRODUCERS 是 25 个（:49-54 每行 4 个、:55 末行 1 个）。你更正的 25 是对的，我的 26 也是错的。

4. 「两条路」我也确认了，我上一条的措辞不够准

producerKind（:59-65）是改写期用的；字面量 plugin 在读盘路径上没有改写可依赖，是硬拒；兜底 plugin:<name> 过得去。我上一条把它们说成一条管线（"先改写、后校验"），这个框架是错的 —— 说成"两条路"才准确。

5. 版本口径更新

我上一条写"我核的是当前 HEAD（5badb15009 = dsh-v0.2.1-alpha.1）"。现在应该按 ref 说：origin/master = d743267388 = dsh-v0.2.1-alpha.2，而本地 HEAD 已经落后 669 个提交，用它取行号会得到过期结论（我这次就补上了这一课）。npm 侧 latest = next = 0.2.0-rc.2、alpha = 0.2.1-alpha.2。

其余部分（RENAMED_PRODUCERS 只活在 v3→v4 迁移里、:103 的报错已带 seq、槽位清单与你们的测量一致）与你们两位的结论一致，我没有异议。

[aavainer]

A follow-up question from our side, while we prepare the injector fix for production:

1. Exact source.kind format. For a skill-body injector plugin, is source.kind = "plugin:<name>" (e.g. "plugin:skill-router") the correct form? Or must <name> match a specific entry (in RENAMED_PRODUCERS / RELEASED_SAME_NAME_PRODUCERS), or is any arbitrary non-empty string acceptable as the suffix?
2. Native auto-injection. Is there a native DSH way to auto-inject skill bodies on a whenToUse match (without an external plugin)? We already filed [Feature] Include `whenToUse` in the skill catalog + optional auto-injection of skill bodies #8909 for whenToUse visibility in the catalog; we'd like to know whether auto-injection itself is on the roadmap or intentionally left to plugins.

Context: we're re-enabling a third-party skill router with the source.kind fix, and want to confirm the exact form before it leaves the sandbox.

---

RU:

Дополнительный вопрос от нас, пока готовим фикс инжектора к продакшену:

1. Точный формат source.kind. Для плагина-инжектора тел скилов — корректна ли форма source.kind = "plugin:<name>" (например "plugin:skill-router")? Должно ли <name> совпадать с конкретной записью (в RENAMED_PRODUCERS / RELEASED_SAME_NAME_PRODUCERS), или достаточно произвольной непустой строки в суффиксе?
2. Нативная авто-инъекция. Есть ли нативный способ DSH авто-инъектировать тела скилов при совпадении whenToUse (без внешнего плагина)? Мы уже подавали [Feature] Include `whenToUse` in the skill catalog + optional auto-injection of skill bodies #8909 про видимость whenToUse в каталоге; хотим понять, планируется ли сама авто-инъекция в апстриме или она намеренно оставлена плагинам.

Контекст: перевключаем сторонний skill-роутер с фиксом source.kind, хотим убедиться в точной форме до выхода из песочницы.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[xiaoshenming]

@aavainer 第 1 点我用发布包实测了一遍，可以给你确定答案；第 2 点不是我们能答的。

1. source.kind 的正确形态：plugin:<name>

两个独立的问题，别混：

(a) 读盘准入要求什么 —— 对 user/message / developer/message 只要求「非空字符串，且不等于字面量 plugin」。实测（assertReleasedV4Relationships，0.1.7-rc.2）：

kind	结果
plugin:skill-router	通过
plugin:（空后缀）	通过
skill-router（裸名）	通过
model / tool	通过（该槽位不检查"语义"）
plugin（字面量）	拒 requires a producer-owned source kind
""	拒 同上

也就是说：准入本身不要求任何后缀。

(b) 但"和官方迁移产物一致"要求 plugin:<name> —— 这是你真正该对齐的东西。官方 v3→v4 stage 用 producerKind(plugin, role) 改写 {kind:"plugin",plugin:X}，实测该函数对任意名字的输出：

skill-router                    -> plugin:skill-router
dsh-skill-router                -> plugin:dsh-skill-router
my-injector                     -> plugin:my-injector
dsh-automation                  -> plugin:dsh-automation
compact                         -> compact-checkpoint      （改名表）
goal                            -> goal                    （同名表）
@deepseek-ai/dsh-system-prompt  -> runtime-context         （改名表）

结论：<name> 不需要匹配任何表；只要你的插件名不在 RENAMED_PRODUCERS / RELEASED_SAME_NAME_PRODUCERS 里（skill-router 不在），写 plugin:<你的插件名> 就是官方转换器会写出的同一个值。用裸名或 plugin: 虽然当下能过准入，但和官方产物不一致 —— 以后任何按 kind 归类的逻辑都会把你的行归错。

顺带一个和你们注入器直接相关的点：写侧就已经拒了。{kind:"plugin"} 在 encodeCurrentEvent 落盘前就抛，所以那种行永远不会出现在日志里（这也是你们"零坏行、回滚救回"的原因）；而 plugin:<name> 一路到底 —— 写入、读盘、迁移三处都认。

2. 原生 whenToUse 自动注入

这个我们答不了 —— 我们只量了格式闸门和磁盘工件，没有 DSH 产品路线图的信息。按 ref 说：我们量的是 0.1.7-rc.2 与桌面内置的 0.2.0-rc.2；#8909 的可见性问题请让官方来答。

（另：PerryLink 在 10-10 补的源码锚点 —— packages/core/session/src/index.ts:332 的 assertMessageEventShape，:362/:368/:376 三条 —— 比我们引的 bundle 行号更耐用，我这边认可，并按他说的改成按 ref 引用。）