[Bug] Conversation pane goes blank on all sessions — TypeError: Cannot read properties of null (reading 'kind')

[pedestrian757]

DSH 对话区整体空白 —— turn 渲染路径空指针缺陷（附完整排查过程）

报告人：DSH 用户（Windows 桌面版 nightly）
日期：2026-10-08
状态：已本地定位根因并验证修复有效（打补丁后恢复正常）

---

0. 摘要（TL;DR）

@deepseek-ai/dsh-client-ui-chat 的 turn 渲染路径有 3 处未做空值保护的属性读取
（X.end?.data.reason.kind）。当某个 turn 节点的 end 存在、但 end.data.reason 为 null 时，
会抛 TypeError: Cannot read properties of null (reading 'kind')。

由于 DSH 的 slot 错误边界会把抛异常的 conversation.view 整块渲染成空 div，
表现为：对话区彻底空白（历史和新回复都看不到），所有会话包括新建会话都一样，且不重载无法恢复。

已确认：与用户数据无关、与第三方插件无关；在纯净内核（仅 dsh-base + dsh-web-app）配置下同样复现。
加上可选链（?.）后问题消失。

---

1. 环境

项	值
应用	DeepSeek Harness 桌面版（Windows）
版本	0.2.0-rc.2（nightly 通道；更新源 https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml 当前最新即为此版本）
Electron / Node	Electron 44.0.0 / Node 24.18.1
系统	win32 x64，locale zh-CN
相关包	@deepseek-ai/dsh-client-ui-chat@0.2.0-rc.2

另经下载比对确认：更新版 @deepseek-ai/dsh-client-ui-chat@0.2.1-alpha.1 中该行同样未修复。

---

2. 症状与影响

• 对话区（conversation pane）完全空白：既看不到历史消息，也看不到模型的新回复。
• 所有会话都空白，包括新建的空会话（发一句就空白，全程看不到任何内容）。
• 侧栏、会话标题、输入框等其它区域正常，只有对话区是空的。
• 重启应用后仍然空白；只有重新加载（Ctrl+R）能短暂恢复，随后再切换又会复发。
• 严重度：功能完全不可用（无法查看/继续任何会话）。

---

3. 复现

1. 启动 DSH 桌面版 0.2.0-rc.2。
2. 打开任意会话（初次渲染正常）。
3. 切换会话 / 切换对话区视图几次。
4. 对话区变空白，此后所有会话（含新建）都空白，直到重新加载。

关键特征：初次装配正常，重新装配（切换）时才崩。

---

4. 崩溃日志证据

日志位置：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-<timestamp>-host.log

--- renderer console (error level) ---
[deepseek-ai/dsh-client-ui-conversation … dsh-client-ui-trajectory/client.js] :23887
    slot entry crashed in 'conversation.view':
    TypeError: Cannot read properties of null (reading 'kind')

app/assets/index-…js:56
    [session-controller] event feed subscriber failed:
    TypeError: Cannot read properties of null (reading 'kind')

DevTools（F12 → Console）中的堆栈：

TypeError: Cannot read properties of null (reading 'kind')
    at turnProcessAlwaysOpen (client.js:1654)
    at ChatNodeSeat (client.js:1678)
    …
[session-controller] event feed subscriber failed
    at ConversationNodeAssembler.replaceWindow
    at ConversationNodeAssembler.apply / accept

---

5. 根因定位

在 @deepseek-ai/dsh-client-ui-chat/lib/client.js 中，3 处同类缺陷：

// 1) turnProcessAlwaysOpen()   ← 堆栈直接指向这里
function turnProcessAlwaysOpen(node) {
  const location = node?.location;
  if (location?.kind !== "turn" && location?.kind !== "step") return false;
  const reason = location.turn.end?.data.reason.kind;   // ← end 有保护，data/reason 没有
  return location.turn.status === "open" || reason === "aborted" || reason === "error";
}

// 2) ChatGroupSeat()
const reason = turnLocation?.end?.data.reason.kind;     // ← 同样问题

// 3) TurnProcessNodeView()
const reason = turn.end?.data.reason.kind;              // ← 同样问题

要点：

• end（turn.end）确实可能不存在（未结束的 turn），所以作者加了 end?.；
• 但 end.data.reason 也可能为 null，而这里没有保护 → 直接抛 reading 'kind'。
• 该函数在每个 turn 座位渲染时都会被调用（const alwaysOpen = liveProcess || interleavedInput || turnProcessAlwaysOpen(routedNode);），
  一旦某个 turn 处于「有 end、无 reason」的中间态就必崩。

为什么会「整个对话区」空白：DSH 的 slot 错误边界在组件抛异常时，会把整个
conversation.view 哨位渲染成一个空 <div data-slot-error="conversation.view">，
所以不是「某条消息没渲染」，而是整块对话区被清空；且该状态会保持到重载。

---

6. 已排除的可能（附证据）

排查过程中逐项排除，供官方参考：

假设	结论	依据
会话数据损坏	排除	全量解压校验所有 session.v4.jsonl.zstd：多帧解压 0 失败、JSON 0 坏、尾部完整；所有 turn/end 事件均带 reason
第三方插件导致	排除	把 bundles 精简到只剩 dsh-base + dsh-web-app（≈纯净内核）后仍复现
已知的「重复 callId 挤掉会话」缺陷	排除	该 build 里不存在 received more than one start Match，conversationContextKey 已是防碰撞实现
皮肤 / 壁纸引擎插件	排除	分别停用后无效
客户端缓存损坏	排除	清空 Cache / Code Cache / GPUCache 后无效
应用安装损坏	排除	该版本 feed 无更新；0.2.1-alpha.1 中同一行同样未修

关键结论：问题在 DSH 内核代码，与用户配置/插件/数据无关。

---

7. 建议修复

给三处补上可选链（一行改动）：

- const reason = location.turn.end?.data.reason.kind;
+ const reason = location.turn.end?.data?.reason?.kind;

- const reason = turnLocation?.end?.data.reason.kind;
+ const reason = turnLocation?.end?.data?.reason?.kind;

- const reason = turn.end?.data.reason.kind;
+ const reason = turn.end?.data?.reason?.kind;

已验证有效：本地对 app.asar 内该文件按上述方式打补丁（等长替换 + 同步更新 asar 完整性哈希）后，
对话区恢复正常，反复切换不再复现。

顺带建议：即便加了 ?.，也建议复查同文件中其它未保护的读取，
例如 event.data.reason.kind（fallbackState、stateFrom、tailData、apply 等多处），
若 turn/end 的 reason 在某些写入路径上可能缺失，这些位置同样会抛错。

---

8. 临时绕过（给其他用户的建议）

• 崩溃后按 Ctrl+R 重新加载即可恢复；
• 修复发布前，尽量避免频繁来回切换会话/视图；
• 不建议用户自行改 app.asar（有完整性校验风险，需先备份）。

---

English Summary

Title: Entire conversation pane goes blank — null dereference in the turn render path

Affected: @deepseek-ai/dsh-client-ui-chat in DSH 0.2.0-rc.2 (desktop, nightly).
Confirmed still present in 0.2.1-alpha.1.

Symptom: The whole conversation pane renders blank (no history, no new replies) for all
sessions, including brand-new ones. Restarting does not help; only a reload (Ctrl+R) recovers it,
and switching again re-triggers it. Rest of the UI is fine.

Trigger: The first render is fine; the crash happens on re-assembly (switching
sessions/views).

Root cause: Three unguarded property reads in dsh-client-ui-chat/lib/client.js
(turnProcessAlwaysOpen, ChatGroupSeat, TurnProcessNodeView):

const reason = location.turn.end?.data.reason.kind;   // `end` is guarded, `data.reason` is not

When a turn node has an end but end.data.reason === null, it throws
TypeError: Cannot read properties of null (reading 'kind'). DSH's slot error boundary then renders
the whole conversation.view slot as an empty <div>, hence the fully blank pane.

Not caused by: session data corruption (all session files validate), third-party plugins
(reproduces with a vanilla core-only profile), the known duplicate-callId defect (absent in this
build), the skin/wallpaper plugins, or client caches.

Fix: add optional chaining — location.turn.end?.data?.reason?.kind.
Verified locally: patching those three lines restores the conversation pane.

Workaround until fixed: reload (Ctrl+R) after a crash; avoid rapid session/view switching.

Logs: %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-*-host.log
(contains slot entry crashed in 'conversation.view' and
[session-controller] event feed subscriber failed: TypeError: Cannot read properties of null (reading 'kind')).

[spicytougan]

补一条写入侧证据：reason: null 不只出现在用户数据里，它可由第三方插件的取消路径稳定产生。链路已在本机逐字核对（Win11 / 桌面版 0.2.0-rc.2）：

1. 插件调用 agent.cancel({ kind: '<自定义>', reason, detail, sessionId })（实例：社区插件 dsh-thinking-guard@1.0.2 熔断时）；
2. 内核 dsh-agent-loop 的取消归因 abortedCancelCause(signal) 只有 4 个 case（user / parent / disposed / hook），其它 kind 落 default: return assertNever(cause); —— 该行上方还标着 /* v8 ignore next -- cancel accepts the closed AgentCancelCause union */，即作者认为这条分支不可达（运行时却可达：TS 的闭合联合拦不住 JS 侧插件）；
3. 抛错发生在回合收尾的 catch 内：const cause = abortedCancelCause(signal); if (cause !== void 0) { turnEnds = { kind: "aborted", reason: cause }; throw error; } → let turnEnds = null; 从未被赋值 → finally { this.session.append("turn/end", { turn, reason: turnEnds }); } 把 null 落盘。

证据

坏记录原文（磁盘上，取自修复前备份）：

{"type":"turn/end","seq":537,"time":1791482813806,"data":{"turn":2,"reason":null}}

共 8 条 / 5 个会话：

会话	条数	时间（本地）
会话 A	2（seq 537/574）	10-09 02:05:34 / 02:06:53 ← 最早
会话 B	1（seq 761）	10-11 14:58:06
会话 C	2（seq 21/45）	10-11 15:01:35 / 15:01:57
会话 D	1（seq 98）	10-11 15:01:54
会话 E	2（seq 54/62）	10-12 00:00:31 / 00:00:52

• 时间线：该插件落盘时间 10-09 01:59:11（包 mtime），全库第一条 null 出现在 02:05:34（+6 分钟）；安装前全库 0 条。
• 修复可验证：只把该条 reason 改成 {"kind":"aborted","reason":{"kind":"user"}}，records 数不变（48/101/602/776/64）、null 归零，会话立即恢复渲染（与 [Bug] 一条 turn/end 的 reason 为 null 会让整个会话列表变空白（Agent Team 场景，附定位与修复建议） #8832「补 kind 即恢复」一致）。注意简写 {"kind":"aborted"} 会撞下游 reason.reason.kind，必须写完整形状。
• 本机现场栈（今天）：[session-controller] event feed subscriber failed: TypeError: Cannot read properties of undefined (reading 'kind') at Object.match ← ConversationNodeAssembler.dispatchInput / matchInput / replaceWindow ← MutableSessionEventSource.publish / replace。磁盘上是显式 null，栈里却是 undefined —— 推测是投影层把 null 变成了 undefined（此点未证实，请官方核对；正是 [Bug] 一条 turn/end 的 reason 为 null 会让整个会话列表变空白（Agent Team 场景，附定位与修复建议） #8832 里问的「null 还是缺字段」）。
• 读侧现状：npm 最新 @deepseek-ai/dsh-client-ui-chat@0.2.1-alpha.2 仍有 11 处未保护读取：end?.data.reason.kind ×3、event.data.reason.kind ×6、reason.reason.kind ×2。本贴列的 3 处之外还有 8 处。
• 写入侧现状：npm 最新 @deepseek-ai/dsh-agent-loop@0.1.0-rc.6 里 let turnEnds = null; 仍在。

建议（三层一起修）

1. 写入侧：turnEnds 初值改为 {kind:"interrupted"}（v1→v2 迁移已有 {kind:"interrupted"} 先例，本机全库实测 24 条该 kind 均正常渲染）；取消归因的 default 分支不要 assertNever 硬抛，未知 kind 降级为 {kind:"interrupted"}。
2. 读侧：不止 3 处，见上（11 处）。
3. 订阅侧：单条坏记录不得让 session-controller 的 event feed 订阅整体失败（同意 [Bug] 一条 turn/end 的 reason 为 null 会让整个会话列表变空白（Agent Team 场景，附定位与修复建议） #8832 里「坏记录必须局部化」的定性）。

另：写出 null 的路径已知不止一条（#8832 怀疑 agent/inbox / Agent Team 回合收尾，未证实），建议写入侧统一堵。

---

本报告由账号主指导 DeepSeek V4.1 Flash 在 Hermes 上进行整理创作（因为我的 DeepSeek Harness 刚才挂掉了）。

[argszero]

Three write-side facts, version-scoped — plus two producers I have to own.

1. The null is a 0.1.7-and-later regression, not a property of cancel()

Published builds, each verified by unpacking its tarball:

@deepseek-ai/dsh-agent-loop	turn catch	what a bad kind writes
0.1.6-alpha.2	turnEnds = { kind:'aborted', reason: signal.reason }; abortedCancelCause does not exist in the build (0 hits)	the cause verbatim
0.1.7-rc.2, 0.2.0-rc.2, 0.2.1-alpha.2	const cause = abortedCancelCause(signal); if (cause !== void 0) { turnEnds = { kind:'aborted', reason: cause }; throw error }	reason: null

In the newer three, abortedCancelCause ends in default: return assertNever(cause) (in 0.2.0-rc.2: lib/index.js:731-745), under the comment "cancel accepts the closed AgentCancelCause union" — true of TypeScript, false at runtime for a JS-side caller. The throw happens inside the catch, so the assignment never runs, turnEnds is still null, and the finally appends turn/end with reason: null. That is exactly your record.

So the same misuse has two different fates: on 0.1.6-alpha.2 and earlier it lands as a malformed-but-tolerated reason: "thinking-loop" (the client reads ('thinking-loop').kind → undefined, no throw); from 0.1.7 on it lands as reason: null, which is fatal.

2. Two producers — both of them are mine

AgentCancelCause is a closed 4-member union (packages/core/session/src/types.ts:189): user | parent | disposed | hook(reason). hook is the member that exists for plugins — core uses it itself ({ kind:'hook', reason:'deepseek-account/signed-out' }). Two of my published packages hand a bare string instead:

// @argszero/cordis-plugin-thinking-loop-guard@0.1.11   (escalate:'cancel')
agent.cancel(config.cancelCause as unknown as AgentCancelCause)   // cancelCause is z.string(), default 'thinking-loop'

// @argszero/cordis-plugin-turn-budget-guard@0.1.1
cancel(cause?: string, options?: { keepInbox?: boolean }): void   // → agent.cancel(action.cause, { keepInbox: true })

('thinking-loop').kind is undefined → the switch falls through to default → assertNever throws → reason: null. The as unknown as on the first line is the tell that the union was being lied to. Both will emit { kind:'hook', reason: <the configured string> } in their next releases; the config field stays a string, so nothing changes for a user.

3. The write boundary never inspected the field

Session.append snapshots the payload (snapshotJsonValue) and then calls validateSessionEventData (packages/core/session/src/surface.ts:166), which inspects surface message slots, request/header and tool/result only. turn/end.reason is a TypeScript-only invariant — nothing rejects null at the append site, which is why the record is durably on disk.

On the null-vs-undefined question

The append-time snapshot does not drop nulls: walkJsonValue (packages/util/values/src/index.ts) has an explicit if (current === null) { assign(task.destination, null); continue }. The log therefore preserves the explicit null; the undefined in your stack comes from a later stage, not from that projection.

Read side at HEAD

Still 11 unguarded reason.kind reads in dsh-client-ui-chat on origin/master: contract/turn-process.ts:72, chat/ChatGroupSeat.tsx:149, chat/TurnProcessNodeView.tsx:20, client/apply.ts:106, conversation-nodes/turn-error.ts:34,35,66,67, conversation-nodes/turn-max-tokens.ts:42,51, conversation-nodes/turn-tail.ts:82 — your count of 11 matches exactly.

Thanks for splitting the report into read and write halves; the version table is what made "which part is a regression" answerable at all.

[ahitzm]

补一条可能推翻「全生态只有两个生产者」的样本：

本机 profile 未安装 thinking-loop-guard / turn-budget-guard（node_modules 下没有 @argszero，全库也无 cancelCause 引用），但仍有一条同样的坏记录：会话 26375d09，seq 229，turn 1，reason 为 null，时间 2026-10-14T16:49:10.606Z（前一事件 step/end turn1 step22，后一事件 session/end-seed）。本机 bundles 只有 base、web-app、voice-input、pet bridge、dshmarket、computer-use。

另外 abortedCancelCause 是直接读 signal.reason.kind，所以「未带 reason 的裸 abort」（AbortError 不带 kind 字段）同样会落到 default 分支抛错——若扫描只匹配 agent.cancel(，这类调用方会被漏掉。建议在降级分支里把未知的 signal.reason 记一次日志/计数，否则事后无法定位调用方。

[argszero]

The two producers are found, fixed, and published.

Following up on this report: a source sweep for agent.cancel( across every published package in this ecosystem found exactly two producers of a turn/end whose reason is null — and both were our own community plugins, passing a bare string where the closed AgentCancelCause union is required. Both are fixed and on npm:

• @argszero/cordis-plugin-thinking-loop-guard@0.1.12
• @argszero/cordis-plugin-turn-budget-guard@0.1.2

Each now hands over the hook member it owns — { kind: 'hook', reason: <configured cause> }, the same shape core writes for deepseek-account/signed-out. A turn ended by either plugin now persists { kind: 'aborted', reason: { kind: 'hook', reason: 'thinking-loop' } } (respectively 'turn-budget') instead of a null. The user-facing config is unchanged: cancelCause is still the knob, now read as the member's reason.

Three details worth recording for anyone else hitting this thread:

1. Cannot be found from the stack trace. The throw happens in abortedCancelCause's default: return assertNever(cause) branch, which the turn loop calls inside its catch. So the loop never reports "bad cause" — the turnEnds = { kind: 'aborted', reason: cause } assignment simply never runs, let turnEnds = null survives into the finally, and the append writes the null. The stack you see points at the original error that aborted the turn, not at the cause handling. Locating our producers took a source sweep, not log reading.
2. Nothing on the write path objects. validateSessionEventData inspects surface messages, request/header and tool/result only, so the record is durably on disk before any reader sees it. A guard on that field is a core-side change.
3. Version boundary, measured not read. 0.1.6-alpha.2 has no abortedCancelCause at all (the abort reason was written verbatim), so an out-of-union cause passes through harmlessly there. 0.1.7-rc.2, 0.2.0-rc.2 and 0.2.1-alpha.2 all carry the reader. We did not infer that from the source: scripts/witness-cancel-cause.mjs (in either plugin repo) extracts the shipped abortedCancelCause out of each published @deepseek-ai/dsh-agent-loop tarball and executes it — on all three affected lines a bare string still yields reason: null, and the fixed cause does not.

One note for other plugin authors who need to abort a turn: the union is closed, but it has a member plugins own, and hook is it. A cast (cause as unknown as AgentCancelCause) typechecks and is still wrong — that is precisely the cast we were shipping.

[ahitzm]

本机 profile 未安装 thinking-loop-guard / turn-budget-guard（node_modules 下没有 @argszero，全库也无 cancelCause 引用），但仍有一条同样的坏记录：会话 26375d09，seq 229，turn 1，reason 为 null，时间 2026-10-14T16:49:10.606Z（前一事件 step/end turn1 step22，后一事件 session/end-seed）。本机 bundles 只有 base、web-app、voice-input、pet bridge、dshmarket、computer-use。

另外 abortedCancelCause 是直接读 signal.reason.kind，所以「未带 reason 的裸 abort」（AbortError 不带 kind 字段）同样会落到 default 分支抛错——若扫描只匹配 agent.cancel(，这类调用方会被漏掉。建议在降级分支里把未知的 signal.reason 记一次日志/计数，否则事后无法定位调用方。

[argszero]

Your read of the two mechanisms is right, and I can now put exact lines under both.

1. Where the null comes from — it is the initializer, not a coercion.

packages/core/agent-loop/src/agent.ts:

• :312 — let turnEnds: TurnEndReason | null = null
• :369-372 — the catch computes const cause = abortedCancelCause(signal), and only if it returns does it assign turnEnds = { kind: 'aborted', reason: cause }
• :387 — the finally appends this.session.append('turn/end', { turn, reason: turnEnds! })

So when abortedCancelCause throws, the append runs with turnEnds still at its initializer: the durable row carries "reason": null literally. That is why the record exists at all — the throw happens inside the catch, and the finally is the write path.

2. Your reason-less-abort observation — measured, not just reasoned.

abortedCancelCause (:80-97) switches on signal.reason.kind and its default arm is assertNever(cause), under /* v8 ignore next -- cancel accepts the closed AgentCancelCause union */ (:92-93) with the comment at :82 that cancel() is the only aborter of these signals. Node says:

abort()            -> AbortError: This operation was aborted | kind= undefined
abort(undefined)   -> AbortError: This operation was aborted | kind= undefined
abort({kind:'user'}) -> {"kind":"user"} | kind= user

So default is reached by two shapes the union cannot describe, and neither is findable by grepping for cancel({kind::

• (a) cancel({ kind: <anything outside the closed union> }) — the union is packages/core/session/src/types.ts:190-194 (user / parent / hook / disposed), and TypeScript enforces it only for typed callers.
• (b) cancel() with no argument at all — the signature is cancel(cause, options = {}), so a JS caller can pass nothing; WebIDL then puts a fresh AbortError DOMException on signal.reason, which is exactly the undefined-kind case above.

3. On reachability from the shipped tree. The loop-owned controllers are created at :188, :229, :393, and the sole .abort() on them is cancel()'s own at :180 — so every in-tree caller passes a union member: acp/src/session.ts:341,453,504 and api/session-controller/src/commands.ts:509 and agent/src/archive-admission.ts:36 and goal/goal-round-driver/src/index.ts:310 (user), goal-round-driver/src/index.ts:467 and subagent/src/archive-admission.ts:33 and subagent/src/manager.ts:1116 (parent), agent-loop/src/index.ts:564,825 (disposed), credentials/deepseek-account/src/account-tasks.ts:30 (hook), and subagent/src/manager.ts:222, whose cause is authority.kind === 'user' ? 'user' : 'parent'. AbortSignal.any propagates a winner's reason verbatim, so a fused signal is no help here either.

Which means the record on your machine — session 26375d09, seq 229, turn 1, no @argszero package anywhere — is consistent with your bundle list rather than against it: the producer is not a shipped caller. One of the non-default bundles (dshmarket / pet bridge / computer-use / voice-input) either cancelled with a value outside the union or cancelled with no argument.

4. Your suggestion. Agreed, and it is worth stating what the current shape assumes: the v8 ignore and the "only aborter" comment are the author's model that the arm is unreachable from the tree, which is defensible for in-tree callers but says nothing about plugin callers — and the cost of being wrong is a durable record no client can render, not a log line. A default that logs (or counts) the offending signal.reason and still produces a resolvable ending would degrade far better than an assert.

On the plugin side, @argszero/dsh-cancel-cause-guard@0.2.0 (npm) shadows Session.append and rewrites a turn/end whose reason cannot be resolved into a resolvable one, so an already-poisoned log stops blanking the list. It is a stand-in for exactly the reason you give: it repairs the record, it cannot tell you which caller produced it — which is what your logging suggestion would give, and it is the half I would most like to see in the tree.

If you can paste the raw line (whether it reads "reason":null literally, plus the neighbouring step/end and session/end-seed seqs), that pins (a) versus (b): both land in the same arm, so the record alone cannot distinguish them, but the surrounding lifecycle sometimes can.

[ahitzm]

找到生产者了 —— 就在这台机器上，是宠物插件的 watchdog 控制。

精确链路（同一次运行的时间戳）：

%APPDATA%\dsh-pet-bridge\dsh-pet-control-23316.jsonl
{"ts":1791996550.5454,"event":"pet/control-clicked","operation":"replan","sessionId":"session-26375d09-01ee-4012-a4cb-d4edeb3f5f2d","requestId":"9c0d62a1eee849b7960a27fab2323fd7"}
{"ts":1791996550.5454,"event":"pet/control-queued","operation":"replan", ...}

→ …\integrations\dsh-pet-bridge\index.js:316（即 @dsh-pet/bridge 这个 link 的真实目录）：
await controlTarget.cancel("dsh-pet-watchdog-replan", { keepInbox: true });
（interrupt 路径在 :302 / :307，用的是 "dsh-pet-watchdog"）

→ 61 毫秒后（ts 1791996550.606）会话日志落盘：
{"type":"turn/end","seq":229,"time":1791996550606,"data":{"turn":1,"reason":null}}

所以确实是 (a) 形状：裸字符串当 cause → signal.reason === "dsh-pet-watchdog-replan" → cause.kind === undefined → abortedCancelCause 的 default: assertNever(cause) 在 catch 内抛错 → turnEnds 保持 null → finally 落盘 reason: null。

补充一条对扫描有影响的细节：@dsh-pet/bridge 是 junction/link 指向 C:\Users\Administrator\AppData\Local\Programs\dsh-pet-standalone-webm-chat\_internal\integrations\dsh-pet-bridge，rg 默认不跟随软链，所以「对 profile 做 agent.cancel( 全量扫描」会漏掉它 —— 这次就是这么漏过去的。

结论：本机那条记录的生产者是 @dsh-pet/bridge 的 replan / interrupt 控制（用裸字符串传 cause），与本机未安装 @argszero 包一致。