[Bug][gateway/internal] DSH 历史加载失败：cannot safely transform unclassified message source

[ErickYu-code]

历史加载失败：failed to observe session "session-f37432fc-3819-4229-8674-cfa4477018fb": cannot safely transform unclassified message source; source v0 artifact remains unchanged (raw log: /Users/yuzhimin/.dsh/sessions/--Users-yuzhimin-Desktop-iOS-maopao--/session-f37432fc-3819-4229-8674-cfa4477018fb/session.jsonl.zstd)（gateway/internal）

dsh --version 0.1.5-rc.1

[argszero]

补充三个定位细节，帮你在报 issue 之前先自证。

1. 抛错的不是「历史加载」这一层，所以它比看起来严重。

完整链条是三段拼接：

packages/session/session-format-v2-to-v3/src/payload.ts:113
  throw new SessionFormatUnsupportedMigrationError('cannot safely transform unclassified message source')
packages/session/session-persistence-jsonl/src/index.ts:675
  `${error.message}; source v${error.fromVersion} artifact remains unchanged (raw log: ...)`
gateway/internal
  failed to observe session "..." : <上面两段拼起来>

关键在第三段：这是观察（observe）阶段，不是「打开某个会话」的操作失败。也就是说这条会话在任何读取路径上都会失败——列表、投影、恢复都一样。按迁移契约（.agents/notes/implemented/architecture/2026-08-31-released-session-format-migrations.md：predecessors imply neither fallback nor downgrade support），v0 工件会被原地保留不动——这是设计上的「拒绝服务」而不是「降级」，所以它不是一次性的加载错误，是这条 log 的持久不可读。

2. 拒的边界正好是「消息来源 kind」三处，这也是最可能的根因。

检查只在三处触发（payload.ts:81-82、:92）：

• user/message → data 本身带 source
• assistant/message / tool/result → data.message 带 source
• agent/inbox/spliced（取 inserted）与 session/title-llm-request（取 messages）→ 数组里每条消息

守卫本身是：

const SOURCE_KINDS = new Set(['user', 'plugin', 'model', 'tool', 'agent-instructions', 'session-reference',
  'team-message', 'goal', 'skill-invocation', 'skill-catalog', 'coordinator', 'subagent-report',
  'subagent-settled', 'webhook', 'agent-message'])          // payload.ts:10

if (typeof source['kind'] !== 'string' || !SOURCE_KINDS.has(source['kind'])) {
  throw new SessionFormatUnsupportedMigrationError('cannot safely transform unclassified message source')
}                                                            // payload.ts:112-113

所以「unclassified」= 这 15 个之外的一个 kind 字符串，或者 source 里根本没有 kind。常见来源是第三方插件注入的消息（source: { kind: '<自定义>' }）——插件作者写自定义 source kind 时，不会知道这里有一张白名单，也不会被任何类型检查拦住（source 在事件类型里往往是宽松的）。你本机装了哪些会往会话里注入消息的插件（agent-team / 自定义 hook / 规则引擎之类），是第一个该排查的方向。

3. 好消息是：修复所需的取证，你自己就能做完，不需要新版本的 dsh 去「看见」那条日志。

这一点很重要，因为现在你可能以为「打不开就查不出来」。其实这个错误故意把 offender 省掉了，而它的兄弟错误不会——

// payload.ts:50 —— 事件类型层面（event.type 不在 released 处置表里时）
throw new SessionFormatUnsupportedMigrationError(
  'format v2 to v3 cannot safely transform unclassified event ' + event.type)   // ← 带名字

而 payload.ts:113 这条只报事实、不报 name/seq。我认为这本身就是一个小 bug：同族错误一个带定位、一个不带，导致你的工单只能贴日志路径，维护者还得自己去解压那 800KB 的 zstd 逐行找。

取证方法（只读，不解压到磁盘）：

cd ~/.dsh/sessions/--Users-yuzhimin-Desktop-iOS-maopao--/session-f37432fc-3819-4229-8674-cfa4477018fb/
zstd -dc session.jsonl.zstd | python3 -c '
import sys, json, collections
kinds, missing, lines = collections.Counter(), 0, 0
for n, line in enumerate(sys.stdin, 1):
    lines += 1
    try: ev = json.loads(line)
    except Exception: continue
    d = ev.get("data") or {}
    msgs = []
    if ev.get("type") == "user/message": msgs = [d]
    elif ev.get("type") in ("assistant/message", "tool/result"): msgs = [d.get("message") or {}]
    else: continue
    for m in msgs:
        s = m.get("source")
        if not isinstance(s, dict): missing += 1; continue
        k = s.get("kind")
        kinds[repr(k) if not isinstance(k, str) else k] += 1
        if k not in {"user","plugin","model","tool","agent-instructions","session-reference","team-message",
                     "goal","skill-invocation","skill-catalog","coordinator","subagent-report",
                     "subagent-settled","webhook","agent-message"}:
            print("OFFENDER line", n, "event", ev.get("type"), "kind", repr(k), "source", json.dumps(s, ensure_ascii=False)[:200])
print("lines", lines, "missing-source", missing)
print("kinds seen:", dict(kinds))
'

（zstd 用 brew install zstd 或系统自带；只要读权限，不需要 dsh。）把 kind 与 source 一起贴出来，就能定死是「哪个插件写的什么 kind」，而不是「某条日志打不开」。

关于插件面（顺带回答可能的下一个问题）：这个缺口在 session-format-v2-to-v3 的载荷校验层，属于 storage/迁移核心；插件既不能加入 SOURCE_KINDS，也不能替这条 log 提供 successor 迁移（按契约不能移动/覆写已发布代）。所以插件不是可行路径，正确路径就是本贴 —— 带 kind 证据的 issue/讨论，让维护者决定是放宽白名单还是把 offender 加进错误文案。我倾向后者先做（零风险、立刻把每一张这样的工单都变得可诊断），前者要单独判断那个 kind 该不该进 released 代。

[ErickYu-code]

OFFENDER line 43 event user/message kind 'instruction-hint' source {"kind": "instruction-hint", "plugin": "anchored-tool-bootstrap"}
OFFENDER line 2077 event user/message kind 'instruction-hint' source {"kind": "instruction-hint", "plugin": "anchored-tool-bootstrap"}
OFFENDER line 2178 event user/message kind 'instruction-hint' source {"kind": "instruction-hint", "plugin": "anchored-tool-bootstrap"}
lines 2211 missing-source 0
kinds seen: {'user': 8, 'model': 164, 'tool': 159, 'plugin': 2, 'instruction-hint': 3, 'skill-catalog': 1}

[LabLeonOfficial]

同一条报错的完整根因定位与分析在 #6311（含你这条 instruction-hint 作为第二个样本的对比）：
#6311