[Bug][0.1.5-rc.1]畸形 tool-call（空 id/name）被持久化进会话日志，导致会话永久不可恢复（每次回放 400 missing field tool_call_id）

[HeZhaoyin]

• 版本基线：DSH 0.1.5-rc.1（文中代码行号均基于该版本；旧版 DSH 上同类事故同样存在，见 §5.2）

---

1. 摘要（TL;DR）

当 LLM 上游（OpenAI 兼容流式协议）因抖动产生空 id / 空 name 的 tool-call 块时（伴随 500 风暴、断流等场景），DSH 在四个环节均无拦截：

1. 流组装：空字符串 "" 穿透 ?? 兜底，组装出 {id:"", name:"", arguments:"完整参数"} 的 tool-call 块；
2. 工具执行：空 name 直通工具注册表 → unknown tool ""（ToolNotFoundError，code UNKNOWN_TOOL）；
3. 结果记录：错误结果以空 toolCallId 原样写入持久化会话日志；
4. 历史回放：空 toolCallId 直通 OpenAI wire 序列化 → 上游拒绝整个请求：400 json_parse_error: messages[N]: missing field tool_call_id；且 400（INVALID_REQUEST）不在可重试错误集合内，内置会话修复模块也不覆盖"平衡但空 id"的记录。

结果：毒记录一旦落盘，该会话的后续每一次 LLM 请求（包括用户新消息）都携带毒记录并被拒绝，会话永久死亡，无自愈、无恢复路径。

两次独立事故（不同 DSH 版本、不同会话）呈现完全相同的终端签名；其中一次已做到逐行源码级验证。

2. 环境

项	值
DSH 版本	0.1.5-rc.1（Node v22.23.2，Linux）
Provider	某 OpenAI 兼容服务端（api: openai-completions；名称已隐去）
模型	512K 上下文窗口的推理模型（名称已隐去）
会话日志格式	事故 A：v3；事故 B：v0（旧版 DSH）
涉及包	@deepseek-ai/dsh-llm、dsh-agent-loop、dsh-tools、dsh-llm-pi-ai、dsh-session（repair）、dsh-llm-retry、@earendil-works/pi-ai

3. 触发条件（上游侧背景）

• 事故时刻上游正处于 500 风暴：单 turn 内 8 次 500 "Generation failed, try later"（会话日志中均有对应 llm/retry 记录）；旧会话事故中还有 Stream ended without finish_reason（TRANSPORT 断流）与 500 "upstream error: do request failed"。
• OpenAI 系 SSE 协议中，tool-call 的首个 chunk 携带 id 与 function.name，后续 chunk 只携带 arguments 片段。流中断/重组时若首个 chunk 丢失，即产出"完整 arguments + 空 id/name"的畸形块——与两起事故记录到的毒块形状完全一致（旧版日志直接记录了原始 chunk：id 为显式空字符串，见 §5.2）。
• 触发源在上游；但"触发"与"永久损毁"之间隔着 DSH 的四层缺失（§4）。上游再抖一次即可复现，与用户环境、插件、配置无关。

4. 故障链与代码位置（0.1.5-rc.1 逐行验证）

① 组装层  空 id/name 穿透兜底          dsh-llm/lib/index.js
② 执行层  空 name 直通调度            dsh-agent-loop/lib/index.js
③ 记录层  空 toolCallId 原样落盘      dsh-agent-loop + dsh-llm
④ 回放层  空值直通 wire 序列化        dsh-llm-pi-ai + @earendil-works/pi-ai
⑤ 恢复层  400 不可重试 + 修复模块不覆盖  重试策略 + dsh-session/repair

4.1 组装层：空字符串穿透 ?? 兜底

dsh-llm/lib/index.js（BlockAssembler）：

// L928-932
case "tool-call-delta": {
    const partial = this.ensure(chunk.index, "tool-call");
    if (partial.block) return;
    partial.toolCallId = chunk.id;              // 流送来 "" → 记录为 ""
    if (chunk.name) partial.toolCallName = chunk.name;   // 无 name → 保持 undefined
    ...
// L978-979
id:   partial.toolCallId   ?? brandString(`call-${index}`),   // "" ?? x → ""（空串非 nullish，兜底失效）
name: partial.toolCallName ?? "",                              // 无 name → ""

缺陷：?? 只对 null/undefined 兜底；上游送来显式空字符串 id: ""（两起事故的实际形态）时兜底不生效，组装出空 id 块；空 name 更是设计性产出（?? ""）。

4.2 执行层：空 name 直通工具注册表

dsh-agent-loop/lib/index.js：

// L512
async function executeToolCalls(ctx, turn, step, toolCalls, signal, acceptContext) {
    const planned = toolCalls.map((block) => ({
        block,
        exec: { callId: block.id, name: block.name, ... }   // L518：无任何空值校验

空 name 进入工具调度器的注册表查询 → 查无 "" → dsh-tools/lib/index.js L2449 抛出 unknown tool ""（错误码 UNKNOWN_TOOL）。

缺陷：畸形块被当作正常调用"执行"，且以工具执行错误形态进入结果记录，而不是作为"本步流异常"被丢弃/重试。

4.3 记录层：空 toolCallId 原样持久化

// dsh-agent-loop/lib/index.js
L687  function appendToolCall(...)   { ... callId: block.id ... }   // L691
L697  function appendToolResult(...) { ... callId: block.id ... }    // L699
// dsh-llm/lib/index.js
L94   function createToolResultMessage(input) { ... toolCallId: input.callId ... }   // L102

毒块对应的 tool/call + tool/result 记录成对、平衡地写入会话日志（toolCallId: ""）。

4.4 回放层：空值直通 wire 序列化

// dsh-llm-pi-ai/lib/index.js（DSH 消息 → pi-ai 消息，回放路径）
L1263  toolCallId: result.toolCallId,      // "" 原样通过
L1327  toolCallId: result.toolCallId,
// @earendil-works/pi-ai/dist/api/openai-completions.js（OpenAI 兼容 wire 序列化）
L1082  tool_call_id: toolMsg.toolCallId,    // 空值进入请求体

上游拒绝整个请求，错误原文（节选）：

400: ***.BadRequestError: OpenAIException -
{"error":{"message":"Invalid JSON data: Failed to deserialize the JSON body into
 the target type: messages[467]: missing field `tool_call_id` at line 1 column 2031656",
  "type":"invalid_request_error","code":"json_parse_error"}}

缺陷：回放路径对"空/孤儿 toolCallId"无任何清洗。注：messages[467]/[614] 索引均指向请求消息数组尾部（毒记录所在位置），与"最后一次正常 step 的记录"相符。

4.5 恢复层：无任何自愈路径

• 重试策略（会话日志 llm/retry 记录中的 policyKey）：
  ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]
  —— 400 的 INVALID_REQUEST 不在可重试集合，一次 400 即 turn 终止。
• 内置修复模块 dsh-session/lib/types/repair.js（interruptedTurnClosers）：只处理崩溃尾部不平衡（有 call 无 result，合成补 result）；本事故的毒记录是平衡的（call/result 成对、id 为空），模块判定"无需修复"直接返回。
• 结果：毒记录永久驻留会话日志 → 会话对任何新消息都返回同一 400 → 永久不可恢复（实测：用户新消息触发新 turn 仍同错）。

5. 事故证据（日志节选）

以下为两次独立事故的日志节选（非完整日志）。
事故 A：v3 日志格式，DSH 0.1.5-rc.1，逐行验证；事故 B：v0 日志格式，旧版 DSH。

5.1 事故 A（Session A）

事件	日志记录（节选）
上游 500 风暴	8 条 llm/retry 记录，failure 均为 500: {"message":"Generation failed, try later","type":"upstream_error","code":"500"}，重试后恢复
毒块组装	assistant 消息 content 含 {"type":"tool-call","id":"","name":"","arguments":"{...完整 bash 命令...}"}
毒调用记录	tool/call：{"turn":11,"step":59,"callId":"","name":"","arguments":"{...}"}
执行失败	tool/result：{"toolCallId":"","isError":true,"text":"Error: unknown tool \"\""}，error:{"name":"ToolNotFoundError","code":"UNKNOWN_TOOL"}
首次 400	turn/end（step 60）：400 ... messages[467]: missing field tool_call_id ... json_parse_error
会话死亡	下一个 turn（用户新消息）第一步：同一 400，会话最后一条记录

5.2 事故 B（Session B，旧版 DSH）

• 原始流块直接记录了畸形形态（chunk 记录节选）：
  {"type":"tool-call-delta","index":2,"id":"","argumentsDelta":"{"} —— 显式空字符串 id；后续块均无 name 字段；块结束记录组装为 {id:"", name:"", arguments:"完整"}。
• 旧版记录层曾合成修补（tool/call 记为 callId:"call_bb923…", name:"todo_write"），但执行层仍收到空 name（result：unknown tool ""）——即使记录被修补，回放仍 400（turn 44/45 均为 messages[614]: missing field tool_call_id）。
• 同会话触发背景：Stream ended without finish_reason（TRANSPORT）与 500 upstream error: do request failed。

结论：该缺陷在旧版与 0.1.5-rc.1 上均存在，属长期架构缺口而非版本回归；旧版"记录层合成修补"的方向正确但不够（未堵住回放）。

6. 后果

1. 会话永久损毁：毒记录落盘后，该会话所有后续请求（含用户新消息）100% 失败，无恢复路径（不可重试、repair 不覆盖、无回放清洗）。
2. 数据不可用：用户只能弃用该会话（新会话 + 人工交接上下文），历史推理成果对模型不可见。
3. 可预期复发：只要上游再发生 500 风暴/断流且 tool-call 首块丢失，同样流程必然重演——与用户环境、插件、配置无关。
4. 隐蔽性强：损毁前无用户可见告警（毒块本身只是一次看似普通的工具报错 unknown tool ""），会话是"从下一个消息起 400"。

7. 推荐修复位置（供参考，按性价比排序）

优先级	位置	建议
P0	组装层 dsh-llm BlockAssembler（L978-979）	空 id 走 brandString 兜底（partial.toolCallId || brandString(...)）；空 name 的 tool-call 块判定为畸形：不产出该块，将本次 LLM 调用标记为 step 级失败（如 MALFORMED_TOOL_CALL 错误码并纳入可重试集合），不落盘。
P0	执行层 dsh-agent-loop executeToolCalls（L512-518）	调度前校验 name 非空且已注册；失败时不记录 tool/call+tool/result 毒对，改记"本步流异常、可重试"的 step 级事件。
P1	回放层（dsh-llm-pi-ai L1263/1327 → wire 序列化前）	构建请求时清洗：toolCallId 为空、或与该助手消息 tool_calls 的 id 对不上的 tool-result 消息，丢弃或合成有效 id（一次性清除已落盘的存量毒记录）。
P1	恢复层	捕获 400 且错误体含 tool_call_id 反序列化错误时：执行 P1 清洗 + 自动重试一次（把"永久损毁"降级为"一次可恢复的 400"）。
P2	dsh-session/repair.js	interruptedTurnClosers 增加对"平衡但空 id 的 tool 对"的识别与清洗（覆盖存量损坏会话的恢复入口）。

P0 两条任一条即可阻止新增毒记录；P1 负责清理存量毒记录并兜底；齐备后，上游抖动的最坏情况退化为"单步重试失败"，不再损毁会话。

---

• Version baseline: DSH 0.1.5-rc.1 (all line numbers refer to this build; an identical incident occurred on an older DSH build, see §5.2-EN)

---

1. Summary (TL;DR)

When an OpenAI-compatible LLM upstream emits a tool-call block with an empty id and empty name due to jitter (500 storms, stream truncation, …), DSH has no guard at any of four layers:

1. Stream assembly: an empty string "" slips past the ?? fallback, producing a {id:"", name:"", arguments:"full args"} tool-call block;
2. Tool dispatch: the empty name goes straight to the tool registry → unknown tool "" (ToolNotFoundError, code UNKNOWN_TOOL);
3. Result recording: the error result is persisted into the durable session log with an empty toolCallId;
4. History replay: the empty toolCallId flows straight into the OpenAI wire serialization → the upstream rejects the whole request: 400 json_parse_error: messages[N]: missing field tool_call_id; and 400 (INVALID_REQUEST) is not in the retryable error set, while the built-in session-repair module does not cover "balanced but empty-id" records.

Consequence: once the poison record is on disk, every subsequent LLM request for that session (including new user messages) carries the poison and is rejected — the session is permanently dead, with no self-heal and no recovery path.

Two independent incidents (different DSH builds, different sessions) show the identical terminal signature; one of them is verified line-by-line against the source.

2. Environment

Item	Value
DSH version	0.1.5-rc.1 (Node v22.23.2, Linux)
Provider	an OpenAI-compatible endpoint (api: openai-completions; name redacted)
Model	a reasoning model with 512K context window (name redacted)
Session log format	Incident A: v3; Incident B: v0 (older DSH build)
Packages involved	@deepseek-ai/dsh-llm, dsh-agent-loop, dsh-tools, dsh-llm-pi-ai, dsh-session (repair), dsh-llm-retry, @earendil-works/pi-ai

3. Trigger conditions (upstream-side context)

• At the time of the incident the upstream was in a 500 storm: eight 500 "Generation failed, try later" within a single turn (each with a corresponding llm/retry record in the session log); the older incident also had Stream ended without finish_reason (TRANSPORT) and 500 "upstream error: do request failed".
• In OpenAI-style SSE, the first tool-call chunk carries id and function.name, and later chunks carry only arguments fragments. If that first chunk is lost during a stream break/reassembly, the assembled tool call is "full arguments + empty id/name" — exactly the shape recorded in both incidents (the v0-format log captured the raw chunks: id was an explicit empty string, see §5.2-EN).
• The trigger originates upstream; but between "trigger" and "permanent corruption" sit four missing DSH defenses (§4). One more upstream jitter reproduces it; it is independent of user environment, plugins, or configuration.

4. Failure chain and code locations (verified line-by-line on 0.1.5-rc.1)

① assembly layer   empty id/name passes the fallback      dsh-llm/lib/index.js
② dispatch layer   empty name goes straight to the registry dsh-agent-loop/lib/index.js
③ record layer     empty toolCallId persisted as-is       dsh-agent-loop + dsh-llm
④ replay layer     empty value straight into wire format  dsh-llm-pi-ai + @earendil-works/pi-ai
⑤ recovery layer   400 not retryable + repair module out of scope

4.1 Assembly: empty string slips past the ?? fallback

dsh-llm/lib/index.js (BlockAssembler):

// L928-932
case "tool-call-delta": {
    const partial = this.ensure(chunk.index, "tool-call");
    if (partial.block) return;
    partial.toolCallId = chunk.id;              // upstream sends "" → stored as ""
    if (chunk.name) partial.toolCallName = chunk.name;   // no name → stays undefined
    ...
// L978-979
id:   partial.toolCallId   ?? brandString(`call-${index}`),   // "" ?? x → "" ("" is not nullish; fallback dead)
name: partial.toolCallName ?? "",                              // no name → ""

Defect: ?? only catches null/undefined; an explicit empty string id: "" (the actual shape in both incidents) defeats the branded-id fallback. An empty name is even produced by design (?? "").

4.2 Dispatch: empty name goes straight to the tool registry

dsh-agent-loop/lib/index.js:

// L512
async function executeToolCalls(ctx, turn, step, toolCalls, signal, acceptContext) {
    const planned = toolCalls.map((block) => ({
        block,
        exec: { callId: block.id, name: block.name, ... }   // L518: no empty-value validation

The empty name reaches the registry lookup → miss on "" → dsh-tools/lib/index.js L2449 throws unknown tool "" (code UNKNOWN_TOOL).

Defect: the malformed block is executed like a normal call and its failure enters the record layer as a tool-execution error, instead of being dropped/retried as a step-level stream anomaly.

4.3 Record layer: empty toolCallId persisted as-is

// dsh-agent-loop/lib/index.js
L687  function appendToolCall(...)   { ... callId: block.id ... }   // L691
L697  function appendToolResult(...) { ... callId: block.id ... }    // L699
// dsh-llm/lib/index.js
L94   function createToolResultMessage(input) { ... toolCallId: input.callId ... }   // L102

The poison tool/call + tool/result pair is written to the durable log balanced and paired (toolCallId: "").

4.4 Replay: empty value flows straight into wire serialization

// dsh-llm-pi-ai/lib/index.js (DSH message → pi-ai message, replay path)
L1263  toolCallId: result.toolCallId,      // "" passes through
L1327  toolCallId: result.toolCallId,
// @earendil-works/pi-ai/dist/api/openai-completions.js (OpenAI-compatible wire format)
L1082  tool_call_id: toolMsg.toolCallId,   // empty value in the request body

The upstream rejects the whole request (error excerpt):

400: ***.BadRequestError: OpenAIException -
{"error":{"message":"Invalid JSON data: Failed to deserialize the JSON body into
 the target type: messages[467]: missing field `tool_call_id` at line 1 column 2031656",
  "type":"invalid_request_error","code":"json_parse_error"}}

Defect: the replay path performs no sanitization of empty/orphan toolCallId. Note that the messages[467]/[614] indices point at the tail of the request's message array (the poison record's position), consistent with "the record of the last normally-completed step".

4.5 Recovery: no self-heal path at all

• Retry policy (from the llm/retry policyKey in the session logs):
  ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]
  — a 400 INVALID_REQUEST is not retryable; one 400 ends the turn.
• Built-in repair dsh-session/lib/types/repair.js (interruptedTurnClosers): only handles unbalanced crash tails (a recorded call with no result gets a synthetic result). This incident's poison is balanced (call/result paired, id empty), so the module decides "nothing to repair" and returns.
• Net effect: the poison record lives in the durable log forever → every request for the session (any new user message) gets the same 400 → permanently unrecoverable (verified: the user's next message starting a new turn hit the identical 400).

5. Incident evidence (log excerpts)

Short excerpts from two independent incidents (no full logs provided).
Incident A: v3 log format, DSH 0.1.5-rc.1, verified line-by-line. Incident B: v0 log format, older DSH build.

5.1 Incident A (Session A)

Event	Log record (excerpt)
Upstream 500 storm	8 llm/retry records, each 500: {"message":"Generation failed, try later","type":"upstream_error","code":"500"}, all recovered by retry
Poison block assembled	assistant message content contains {"type":"tool-call","id":"","name":"","arguments":"{...a full bash command...}"}
Poison call recorded	tool/call: {"turn":11,"step":59,"callId":"","name":"","arguments":"{...}"}
Dispatch failure	tool/result: {"toolCallId":"","isError":true,"text":"Error: unknown tool \"\""}, error:{"name":"ToolNotFoundError","code":"UNKNOWN_TOOL"}
First 400	turn/end (step 60): 400 ... messages[467]: missing field tool_call_id ... json_parse_error
Session death	next turn (new user message), step 1: identical 400; this is the session's final record

5.2 Incident B (Session B, older DSH build)

• The raw stream chunks (recorded in the v0 format) capture the malformed shape directly:
  {"type":"tool-call-delta","index":2,"id":"","argumentsDelta":"{"} — an explicit empty-string id; no name field on any following chunk; the block-end record assembled {id:"", name:"", arguments:"complete"}.
• The old build's record layer synthesized a patch (tool/call stored as callId:"call_bb923…", name:"todo_write"), but the dispatch layer still received an empty name (result: unknown tool "") — even with the record patched, replay still 400'd (turns 44/45, both messages[614]: missing field tool_call_id).
• Trigger context in the same session: Stream ended without finish_reason (TRANSPORT) and a 500 upstream error: do request failed.

Conclusion: the defect exists on both the older build and 0.1.5-rc.1 — a long-standing architectural gap, not a regression. The older build's "record-layer synthesis" pointed the right way but did not close the replay path.

6. Impact

1. Permanent session loss: once the poison record is on disk, 100% of subsequent requests for that session (including new user messages) fail, with no recovery path (not retryable; repair out of scope; no replay sanitization).
2. Data unusable: the user can only abandon the session (start a new one and hand over context manually); prior reasoning results become invisible to the model.
3. Reproducible on demand: any future upstream 500 storm / stream break that loses the first tool-call chunk will re-trigger the exact same chain — independent of user environment, plugins, or configuration.
4. Silent until it happens: there is no user-visible warning before corruption (the poison block looks like an ordinary tool error, unknown tool ""); the session simply "400s from the next message onward".

7. Suggested fix locations (for reference, ordered by cost/benefit)

Priority	Location	Suggestion
P0	Assembly, dsh-llm BlockAssembler (L978-979)	Fall back to brandString on empty id (partial.toolCallId || brandString(...)); treat a tool-call block with empty name as malformed: do not emit the block, mark the LLM call as a step-level failure (e.g. a MALFORMED_TOOL_CALL error code, added to the retryable set), and do not persist it.
P0	Dispatch, dsh-agent-loop executeToolCalls (L512-518)	Validate name (non-empty and registered) before dispatch; on failure, do not record the poison tool/call+tool/result pair — record a "step-level stream anomaly, retryable" event instead.
P1	Replay, dsh-llm-pi-ai L1263/1327 → before wire serialization	Sanitize request construction: drop or re-id any tool-result message whose toolCallId is empty or matches no tool_calls id in the preceding assistant message (one-shot cleanup of already-persisted poison).
P1	Recovery layer	On a 400 whose body indicates a tool_call_id deserialization error: run the P1 sanitization and auto-retry once (downgrade "permanent death" to "one recoverable 400").
P2	dsh-session/repair.js	Extend interruptedTurnClosers to detect and clean "balanced but empty-id" tool pairs (recovery entry point for already-corrupted sessions).

Either P0 item alone prevents new poison records; the P1 items clean up existing poison and provide a backstop; with all in place, the worst case of upstream jitter degrades to a single failed-and-retried step, never a corrupted session.

[argszero]

逐行复核了你的失败链：四个环节我都能在 c291e7961a（tag dsh-v0.1.5-rc.2）上复现，§7 的"回放清洗"方向也对。但有两条仓库事实会实质性改变修法排序，先说它们。

① 这个缺口被修过一次，又被完整回退了——回退的理由正是你的场景

translate.ts:184-185 的 acceptIdentity（:85-87）只接受非空字符串，空串/null/非字符串一律"不更新"。该规则 2026-09-01 落地（a1271a4903），dsh-v0.1.3-alpha.1（09-04 发布）就已在树里，你测的 rc.1 自然包含。

即"首个 delta 带 id、后续 delta 重复空串/null 抹掉身份"这条路径已关闭（#5884/#6152 属此类）。你记录的毒块（完整 arguments + 空 id/name）是另一类：整个流从未给出身份。

关键在后面：那次提交顺带做掉了你 §7 的 P0 前两条（新增 MALFORMED_TOOL_CALL 码、加入默认可重试集合、[DONE] 处不发 block-end 而以 error finish 收尾），随后被 b03261caad（09-02）完整回退，理由原文与你的场景直接相关：

needed a new failure code, a change to the default retryable set, and a [DONE] gate that overrode the finish reason a provider had already sent — turning a safe max-tokens truncation into up to five retries. The lenient wire it guarded against is hypothetical: no report describes a stream that omits identity entirely.

今天 MALFORMED_TOOL_CALL 在 packages/、apps/ 零出现；归档决策记录 .agents/notes/archived/architecture/2026-09-01-streamed-tool-call-identity.md 的 "Refuse a response whose tool call never receives an identity" 一节写着 Deferred，依据就是上面那句 hypothetical / no report。

⇒ 你的报告恰好是那条被推迟路径的第一个真实证据。 这改变了提议性质：不是"修已知 bug"，而是"重开一个被显式推迟、且上次实现被回退过的决策"。上次代价是真实的。所以重做时必须把"身份缺失"与"provider 已发出的 finish"正交处理，绝不再用 [DONE] 门覆盖 finish reason——否则大概率以同样理由再被回退。建议把这点写进提议。

② 空 id 落盘的闸门在写边界，不在组装/执行层（这让 P0 变便宜）

你 §4.5"repair 不覆盖 balanced 空 id"准确，但还有更基础一层：校验器早就有，写路径根本没调用它。

• packages/core/session/src/index.ts:328 assertMessageEventShape，:369-374 对 tool/result 要求 source.kind === 'tool' 且 callId 非空字符串，:382 还要求 content[0].toolCallId === source.callId。
• 它只在读/边界侧被调用：adoptSessionEvent（:167-172）、seed（:228/:272）、持久化读路径 validateStoredEvents（session-persistence/src/storage-contract.ts:69，:95 即 adoptSessionEvent；由 jsonl 后端 :627/:758 与 generation.ts:524 调用）。
• 而 Session.append 只调用 validateSessionEventData（:739），后者只查 request/header 与 tool/result 的 error 一致性（surface.ts:140-167），从不看 callId。

⇒ 不变量应是"读得进才写得出"，实际是"写得进、读不出"：写路径放行了它自己读取器会拒收的事件。这就是你 P1 那个洞的精确位置。

由此得到比组装层更便宜、且完全不碰 finish reason 的修法：在 append（或 append 前复用 assertMessageEventShape）对 tool/result 空 callId 拒收。它把"永久毒记录"降级为"本步结果无法记录"，零新错误码、零重试集合改动、零 [DONE] 门——正好绕开上次回退的全部理由。（是否再做成可重试 step 级失败是第二步；先堵落盘。）

两条既有约束也印证"清洗"而非"放松读侧"：session-format-v0-to-v1/src/payload-validation.ts:253-256 迁移层早已要求 tool/call 的 callId 与 name 非空（同一不变量在迁移强制、在 append 不强制）；归档 note 的 "Relax the session reader's empty-callId refusal" 是 Rejected（"an empty callId cannot be paired back to the provider … the producer was the defect"）——读侧拒收是有意的持久边界，正解在写/产侧。

③ 你 P0 第一条的 brandString 兜底在本树是空操作

packages/util/brand/src/index.ts：brandString<T>(value) { return value as T } —— 纯编译期断言，运行时恒等。所以 ?? brandString(...) 与 || brandString(...) 只在 '' 上不同（?? 放空串穿过）；"空 id 走兜底"这个前提不成立——代码里没有"空值兜底"，只有"未定义兜底 + 编译期 brand"。

而且它只在 block-end 缺席时才重要：llm/src/assembler.ts:109 先 if (partial.block) return partial.block——block-end 权威、覆盖累计值；两条已发布适配器正常/异常收尾都发 block-end（llm-deepseek/src/translate.ts:129 的 closeBlock；llm-pi-ai/src/stream.ts:196-201 用 pi-ai 的 event.toolCall）。⇒ 有权威 block-end 时只改 delta 兜底是无效的——这也正是 #6152 类修复必须同时改 delta 与 block-end 的原因。

④ 两条已发布适配器在"身份缺席"上都产出未识别调用

llm-pi-ai/src/stream.ts:188（delta）/:200（block-end）都走恒等 brandString；llm-deepseek/src/translate.ts:191 发 id: brandString<ToolCallId>(block.callId ?? '')，身份从未出现时 block.callId 仍是 undefined ⇒ 同样发 ''。不是某家 provider 的怪癖，而是两条适配器共有的缺席语义。

建议在你的报告里点明适配器：你写 api: openai-completions，这是 pi-ai 的路由键（llm-pi-ai/src/catalog.ts:312）且 pi-ai 自 0.1.2-rc.1 起为默认 ⇒ 你的实际路径很可能是 llm-pi-ai 而非 llm-deepseek。上游落点不同（stream.ts:188/200 vs translate.ts:191），而 acceptIdentity 的位置决定了"身份被抹"与"从未出现"要不要分开修。

另：brandString('') 本身诊断上无害（类型层恒等，不伪造东西），真正问题是下游没有任何消费者验证它非空。

⑤ 判别启发式

这个形状不需要"提供方怪癖"——只需"tool-call 首块在断流/重组中丢失"，任何 OpenAI 兼容 SSE 都可能发生，包括官方端点。别归因为"某个网关太重"：直接看事件流，tool-call-delta 带非空 id/name 的比例≈ 0 就说明是平台层。同一启发式适用于 #5884 / #6152 / #6300 这一整族——三个报告都闭锁在同一个缺失上。

⑥ 该形状已有插件侧止血（producer 缝）

针对同族 #6152 我发布了 @argszero/cordis-plugin-llm-tool-call-guard（npm + GitHub argszero/cordis-plugin-llm-tool-call-guard），挂在 llm/stream 瀑布：

• repair: 'repair'（默认）：同时改写 tool-call-delta 与 block-end 的空 id（两处都要改，理由同 ③），有意不动空 name——harness 已把它转成 ToolNotFoundError/UNKNOWN_TOOL 错误结果，诚实且可恢复；抹掉 name 会让调用消失，编一个则伪造模型没发出的调用。
• repair: 'error'：以 error finish 断流（TOOL_CALL_EMPTY_IDENTITY），让未识别调用根本不执行。

对你的场景：默认模式已足以让会话可再打开（毒记录不再带空 id），error 模式给出"本步失败"语义。但这是缝上止血、不是修复——写边界仍放行（见 ②），插件挡得住"新毒"，挡不住"写边界本身"。

⑦ 对 §7 的重排建议

优先级	位置	建议
P0	写边界：append（core/session/src/index.ts:739，或 append 前置校验）	对 tool/result 的 source.callId 做非空校验，与读侧 :369-374 用同一谓词。零新错误码、零重试集合改动、零 finish 覆盖，直接堵住"写得进读不出"。
P0'	产侧：llm-pi-ai/src/stream.ts:188/200、llm-deepseek/src/translate.ts:191	身份缺席 ⇒ 不产出可派发调用。必须按 b03261caad 的教训：不得用 [DONE] 门覆盖 provider 已发出的 finish（尤其 max-tokens），应做成"不产出该块 + 标记本次响应不可用"，与 provider finish 正交。
P1	回放清洗（llm-pi-ai/src/context.ts:202 之前）	丢弃或补齐"toolCallId 为空、或与该助手消息 tool_calls 对不上"的 tool-result。你这条对；:382 的配对断言说明清洗是唯一方向。
P1'	恢复：400 含 tool_call_id 反序列化错误	写边界修好后新增价值下降（新会话不再产毒），仍可作存量救援。注意 interruptedTurnClosers 只处理"不平衡尾部"，毒记录是平衡的，需新增形状识别。
P2	repair 模块	同上，针对存量。

⑧ 旁注：toolName 也一起失真

llm-pi-ai/src/context.ts:202-203 回放时 toolCallId 原样映射，且 toolName: toolNames.get(result.toolCallId) ?? 'unknown'——toolNames 也按 callId 建立。空 id 时写出去即 toolName: 'unknown'：工具名与 id 双双失真。若上游清洗，可恢复顺序是 name（若调用名尚存）→ id；两边都空只能判为无法回填。

⑨ 核验边界

• 行号与谓词基于 c291e7961a（= dsh-v0.1.5-rc.2），你基于 0.1.5-rc.1；就这几处而言两版一致（alpha.1→rc.2 间 llm/jobs 的 src 只动了 README 与 package.json）。
• 我未在你的环境复现（无你的 provider 与完整日志），以上为源码级复核 + 你提供的日志节选。
• 从 §5.2 的原始 chunk（显式 id:""、后续块均无 name）看，事故 B 更接近"从未出现身份"而非"身份被抹"；事故 A 我无法判定。

---

EN TL;DR. Your four-layer chain checks out on c291e7961a, but two repo facts reorder the fix. (1) The identity-erasure path was already closed in dsh-v0.1.3-alpha.1 (a1271a4903); that commit's companion mechanism — a new MALFORMED_TOOL_CALL code plus a [DONE] gate — was fully reverted in b03261caad (reason: the gate overrode a provider-sent finish, turning a safe max-tokens truncation into up to 5 retries; "no report describes a stream that omits identity entirely" — your report is the first such evidence, so re-proposing it needs the finish-reason separation spelled out). (2) The durable gate already exists but only on the read boundary (assertMessageEventShape, core/session/src/index.ts:369-374, via adoptSessionEvent/validateStoredEvents); Session.append calls only validateSessionEventData (:739), which never inspects callId — so the cheapest P0 is a non-empty callId check at append: no new error code, no retry-set change, no finish-reason involvement. Also: brandString is a compile-time cast, so the "brandString fallback for empty id" is a no-op; and block-end is authoritative (llm/src/assembler.ts:109), so fixing only deltas is inert. Both shipped adapters (llm-pi-ai/src/stream.ts:188/200; llm-deepseek/src/translate.ts:191) emit '' when identity never arrives; since api: openai-completions is a pi-ai route key (catalog.ts:312), your path is most likely llm-pi-ai, not llm-deepseek — worth stating in the report. Producer-seam mitigation for this shape already exists: @argszero/cordis-plugin-llm-tool-call-guard (repairs the empty id on both delta and block-end; repair: 'error' cuts the stream before dispatch) — mitigation, not the fix, since the append boundary still admits it.