spill 文件超过上限后被删除，披露退化为 (unavailable)（0.1.5-rc.3，附文件行号）

[YOUKNOWWHOOO]

spill 文件超过上限后被删除，披露退化为 (unavailable)，模型无法区分两种成因

环境与方法

• @deepseek-ai/dsh 与全部 @deepseek-ai/dsh-* 包 0.1.5-rc.3。
• 下文 文件:行 指 npm 包内的构建产物，即 node_modules/@deepseek-ai/<包名>/lib/，不是仓库源码行号。
• dsh-subprocess-local/lib/ 下的构建产物带内容哈希，下面出现的文件名取自 0.1.5-rc.3。
• 方法：静态阅读。本次未做运行时验证。

机制

单流输出超过 maxSpillBytes 时，spill 文件被删除，该流在本次执行内不再落盘，而模型侧看到的披露退化为同一个 (unavailable) 文案。

默认值为 67108864，见 dsh-bash-local/lib/index.js:89 与 dsh-pwsh-local/lib/index.js:162 的 const DEFAULT_MAX_SPILL_BYTES = 64 * 1024 * 1024;，配置项是同包 :133 的 maxSpillBytes。

删除链路在 dsh-subprocess-local/lib/runner-launch-COYGu0Dl.js：

• :760 判定 if (this.maxSpillBytes !== void 0 && this.total > this.maxSpillBytes) {，命中即执行 :761 的 this.discardSpill();。
• discardSpill() 在 :777 置 this.spillDisabled = true;，在 :784 执行 unlinkSync(file);。
• :742 的落盘条件以该标志为前置，if (!this.spillDisabled && (overflows || this.spillFd !== void 0)) this.spillAll(chunk);，因此置位后该流不再落盘。

模型可见的披露在 dsh-tool-bash/lib/index.js：

• :41 返回 `${output.text}\n[output truncated; full output: ${output.spillPath ?? "(unavailable)"}]`。
• :89 是同一退化在后台进程增量路径上的对应实现。

影响

模型侧只有 (unavailable) 一种形态，该文案不携带成因。除超限删除外，关闭 spill 文件失败时同样会走到该文案。模型因此无法区分「从未落盘」与「落盘后被删除」，也无法判断内容是否曾经可读。

复现

构造一条单流输出超过 maxSpillBytes 的命令即可观察到该文案，把上限调小可以缩短复现时间。

[PerryLink]

包内文档写的意图与你观察到的结果不一致——这正是你这条的价值

1. 文档原文（packages/spill/spill-policy/README.md:65）

A missing owner or spill backend, failed storage, missing route image pricing, or unavailable execution-world image path logs a warning and keeps the original content. The policy never substitutes an unreadable path for an image.

⇒ 文档承诺的是"记录警告并保留原始内容"（不替换、不降级成占位）。而你观察到的是：spill 文件超过上限被删除后，披露退化为 (unavailable)。

这两者对不上，所以按缺陷报是对的。 建议在正文里直接把上面这句原文引出来——它把"我认为应该怎样"变成"文档说应该怎样，实际不是"，这是最容易推进的形式。

2. 请补三样

1. 你 cite 的文件行号对应的那段代码（你说"附文件行号"——请把代码本身也贴进正文，不要只给行号：版本一动行号就失效，而符号名 + 代码不会）；
2. 复现到删除的那一步（超过上限时的输出，以及删除发生后同一个披露处显示的内容）；
3. dsh --version。

3. 一个关键区分（决定这条该归到哪一类）

请说明 (unavailable) 是**"本该显示的内容被替换成了占位"，还是"原始内容确实还在、只是这一处附加披露取不到"**：

• 前者 ⇒ 与文档承诺直接冲突（严重度更高，且可能影响模型看到的上下文）；
• 后者 ⇒ 是"披露缺失"的可观测性问题（较轻）。

你写的"披露退化为 (unavailable)"倾向前者，但请用实测确认——这两类的修法完全不同。

4. ⚠️ 版本：请先在 next 上复现

你在 0.1.5-rc.3——这正是 npm 的 latest，是旧的；当前最新是 next = `0.1.7-rc.2：

npm i -g @deepseek-ai/dsh@next

0.1.5 → 0.1.7 之间这类"上限/淘汰/披露"路径有改动（同类机制里，压缩与溢出相关的分支在 0.1.7 线被重做过）。先在 next 上走一遍你的最小复现：若已不再出现，这条可结；若仍出现，按 0.1.7-rc.2 重提，说服力最强。

一条边界

我确认的是README 里那句"保留原始内容、绝不替换"的承诺（这足以支撑"文档与行为不一致"这个判断）。具体是哪段代码产生 (unavailable)要以你贴出的代码为准——我在本仓按其描述检索时没有直接命中该降级路径。

[YOUKNOWWHOOO]

按你的要求补四项：代码本身、复现到删除那一步、版本号，以及 (unavailable) 的成因分类。另有三处需要更正原报告与一处需要说明你的建议里的归属问题，我放在最后，先说结论。

版本身份

• npm 包：@deepseek-ai/dsh 与全部 @deepseek-ai/dsh-* 包 0.1.5-rc.3（当前 dist-tags 的 latest；2026-09-27 实测 latest = 0.1.5-rc.3、next = 0.1.7-rc.2、alpha = 0.1.7-alpha.2）。
• 下文标「产物」的是 npm 包内 lib/ 路径；标「源码」的是仓库路径（标签 dsh-v0.1.5-rc.3，提交 a4c74a91）。

一、代码：删除链路（产物）

dsh-subprocess-local/lib/runner-launch-COYGu0Dl.js（该文件名带内容哈希，0.1.5-rc.3 下即为 COYGu0Dl），符号 OutputCollector：

	/** Open the spill file lazily and append `chunk` (and any prior chunks once). */
	spillAll(chunk) {
		if (this.maxSpillBytes !== void 0 && this.total > this.maxSpillBytes) {   // :760
			this.discardSpill();                                                   // :761
			return;
		}
		if (this.spillFd === void 0) {
			this.spillFile = join(this.spillDir, `dsh-subprocess-${process.pid}-…-${this.label}.log`);  // :765
			this.spillFd = openSync(this.spillFile, "wx", 384);                     // :766
			for (const prior of this.chunks) writeSync(this.spillFd, prior);        // :767
		}
		writeSync(this.spillFd, chunk);                                             // :769
	}

	/** Stop spilling and remove the file once it can no longer hold the complete stream. */
	discardSpill() {
		const fd = this.spillFd;                                                    // :773
		const file = this.spillFile;                                                // :774
		this.spillFd = void 0;                                                      // :775
		this.spillFile = void 0;                                                    // :776
		this.spillDisabled = true;                                                  // :777
		if (fd !== void 0) try { closeSync(fd); } catch { this.spillFd = fd; }       // :778-:782
		if (file !== void 0) try { unlinkSync(file); } catch {}                     // :783-:785
	}

落盘条件以 spillDisabled 为前置（:742）：

		if (!this.spillDisabled && (overflows || this.spillFd !== void 0)) this.spillAll(chunk);

因此 :777 置位之后，该流在本次执行内不再产生任何 spill 文件。

符号与位置的对应关系（这一组是我在原报告中写错的地方，已更正）：

符号	位置	事实
DEFAULT_MAX_SPILL_BYTES	dsh-bash-local/lib/index.js:89、dsh-pwsh-local/lib/index.js:162	值为 64 * 1024 * 1024
maxSpillBytes（Config）	dsh-bash-local/lib/index.js:133、dsh-pwsh-local/lib/index.js:204	schema 默认取上一行的常量
上限传递到子进程层	dsh-bash-local/lib/index.js:184、dsh-pwsh-local/lib/index.js:285	spill: { maxBytes: this.config.maxSpillBytes }

原报告把常量位置写成「dsh-bash-local/lib/index.js:89 与 dsh-pwsh-local/lib/index.js:162」，这两处是对的；但把配置项写成「同包 :133」，只对 bash 成立，pwsh 的对应位置是 :204。此处更正。

二、代码：披露链路（产物）

dsh-tool-pwsh/lib/index.js，符号 streamText：

/** Append the truncation notice (with the full-output spill path) to a stream's text. */
function streamText(output) {
	if (!output.truncated) return output.text;
	return `${output.text}\n[output truncated; full output: ${output.spillPath ?? "(unavailable)"}]`;   // :48
}

后台读取路径同形，同文件 :94：[some output was dropped from memory; full output: ${paths.length > 0 ? paths.join(", ") : "(unavailable)"}]。dsh-tool-bash 的对应实现是同文件 :41 与 :89，与我原报告引用的一致。

三、复现到「删除」那一步

删除是累积字节数的判定，不是单条命令规模的下限，因此把上限调小即可在秒级复现，不需要真的产出 64 MiB 输出。

1. 把上限降下来。宿主侧配置位置是 pwsh-sandbox / bash-sandbox 行的 maxSpillBytes（该类行在本机组合树中为顶层行），或在 profile patch 里覆盖同一键；该行的 Config 由本地执行器继承而来，键名就是 maxSpillBytes。
2. 触发 spill 并越过上限：让单条命令的单一流输出超过该上限。注意 spill 是每流独立的，跨流不累加。
3. 越过上限的那一刻应观察到：discardSpill() 被调用 ⇒ 文件被 unlinkSync 删除、spillDisabled = true、spillFile 置空。
4. 同一步的工具结果里应观察到披露退化为字面量 (unavailable)，即 [output truncated; full output: (unavailable)]（前台路径）或 [some output was dropped from memory; full output: (unavailable)]（后台增量路径）。

实测结果（已执行，不再是设计稿）：在本机用一次性 --patch 把 pwsh-sandbox 的 maxSpillBytes 由 67108864 改为 32768（其余键保持不变），让 pwsh 执行一条向 stdout 输出约 120000 字符的命令，工具结果的逐字形态为：

AAAA…（stdout 尾部，含 \r\n）\r\n\n[output truncated; full output: (unavailable)]\n\n(Omitted 14266 bytes. Full formatted result stored at: <OS 临时目录>/dsh-spill-<随机>/session-<id>/<哈希>-pwsh.txt. Use read with offset/limit, or grep this path to search within it.)

上述文本取自该次运行的会话日志中 tool/result 事件的逐字内容，不是转述。三点值得注意：

1. [output truncated; full output: (unavailable)] 确实出现，形态与 streamText() 的实现一致；
2. 同一条结果里还跟着 spill-policy 的 (Omitted N bytes. Full formatted result stored at: …) 通知，即这一次的工具结果自身还有一层可读副本；
3. 被我调小的那个上限是沙箱执行器的 argv 上限，也就是 pwsh-sandbox 行的 maxSpillBytes，与 spill-policy 的 maxInlineBytes 是两个不同的键、不同的机制。

因此实测让第 4 步的判据从「应当观察到」变成「已观察到」，并额外暴露出本报告原先没有写清的三层结构，见下一节。

四、你要的关键区分：不是二选一，而是三层结构，每层的答案不同

你在评论中问 (unavailable) 是「本该显示的内容被替换成了占位」还是「原始内容确实还在、只是这一处附加披露取不到」。实测结论是要分成三层来看，每一层的答案不同：

层	机制	该层的内容是否还在	该层的披露
执行器 spill（沙箱 argv 上限）	dsh-subprocess-local 的 OutputCollector.discardSpill()	不在：文件被 unlinkSync 删除，该流此后不再落盘	[output truncated; full output: (unavailable)]，不携带成因
工具结果 spill（spill-policy 的 maxInlineBytes）	dsh-spill-policy/lib 的 tools/post-execute 替换	还在：工具结果的完整格式化正文落盘并给出可读路径	(Omitted N bytes. Full formatted result stored at: <路径>. Use read with offset/limit, or grep this path…)，路径可用
模型可见正文	适配器序列化	超出执行器上限的 stdout 部分不再出现	只有上一行的占位符

两处落盘的位置与上限都不同：执行器那道在每进程私有的 0700 临时目录里、上限是 maxSpillBytes；spill-policy 那道是本机 OS 临时目录下的 dsh-spill-* 结构、上限是 maxInlineBytes（本机由宿主组合层设为 50000 字节）。实测中，spill-policy 那份文件在核对时仍然存在且为 64047 字节，说明「附加披露取不到」这一档在这一层并不成立。

所以对你的问题，答案是：

• 「本该显示的内容被替换成占位」成立，但只针对执行器 spill 覆盖的那一段 stdout：它确已被删除、不可取回。
• 「原始内容确实还在、只是这一处附加披露取不到」对「工具结果是否有副本」这一层不成立：工具结果的完整正文仍有可读副本、且披露给出了路径。
• 真正的问题落在信息丢失的边界的判定上：模型读到的 [output truncated; full output: (unavailable)] 只说明「执行器的 spill 文件不可用」，不说明原命令输出的哪一部分丢了、丢了多少、是否还有别处副本。同一份结果里既有「不可用」也有「完整副本在路径 X」，两者指向不同的东西，而正文没有区分它们。

原报告把「披露退化为 (unavailable)」写成单一结论，被你这么一问，确实不够准确：准确表述是「执行器 spill 层的披露退化 + 该层内容不可取回」，而不是「整条工具结果的披露退化」。

五、(unavailable) 的成因不止删除一种

(unavailable) 是 spillPath ?? "(unavailable)" 的取值，因此凡 spillPath 为 undefined 都走这一文案，删除只是其中一种。可识别的成因至少有：

• 流越过 maxSpillBytes，spill 文件被删除（本条）；
• spill 文件的最终关闭失败：实现里 closeSpill 一带的注释写明，此时会停止公布 spill 路径（dsh-subprocess-local/lib/runner-launch-COYGu0Dl.js:807-809 的注释）；该分支在读取时可能仍延迟写回故障，即文件可能仍存在，但路径不再公布。这一条我尚未逐行核对，按注释与 :831 的条件写法（仅在 spillFile 仍存在时才给出路径）列出，不作为已核对的结论；
• 流从未越界，因而从未创建 spill 文件。

这三种在模型侧完全同形。

六、需要更正你评论中的一处归属问题

你在建议中提出引用 dsh-spill-policy 的 README 里那句「a missing owner or spill backend, failed storage, missing route image pricing, or unavailable execution-world image path logs a warning and keeps the original content」，用来把本条变成「文档说应该怎样、实际不是」。这一点我不能接受，理由是那句承诺讲的是另一条路径：

• (unavailable) 这个文案不在 dsh-spill-policy 内——该包全树对字符串 unavailable 零命中。
• 它的真实位置是工具层的输出渲染器，即本文第二节的 dsh-tool-pwsh/lib/index.js:48（bash 侧 :41）。也就是说，披露退化发生在 dsh-tool-pwsh / dsh-tool-bash，不在 spill 策略层。
• dsh-spill-policy 的那句 README 承诺描述的是它自己的失败分支：saveText 失败或缺少会话所有者、缺少 spill 后端时，记录警告并返回原始内联结果（产物侧对应 dsh-spill-policy/lib/index.js:150-153 的「通知本身超预算则保留内联内容」分支）。它与「子进程收集器删除自己的 spill 文件」没有因果关系。
• 引用它会把两条独立路径混为一谈，使本条从「披露不携带成因」被误读成「spill 策略违反了自述承诺」，后者不成立。

正确的对照位置是工具包自己的文档：dsh-tool-pwsh/README.md:155（中文版 README.zh.md:155）逐字列出条件行 [output truncated; full output: <path-or-(unavailable)>]。也就是说，(unavailable) 这个取值本身是被文档声明过的契约，本条要报的不是「实现与文档不一致」，而是「该契约不携带成因」。

七、删除本身有文档披露，本条的问题是披露层级

这一点也必须写清，否则本条会被读成漏读文档：

• dsh-subprocess-local/README.md:45（中文版 README.zh.md:45）逐字写明：「某条流大于 spill 上限时，会丢弃不完整的 spill，只返回带截断标记的尾部。」删除行为在此有明文，且被描述为设计意图而非缺陷。
• 同包限制段落 :139 另有一句反向陈述：「不会删除已完成的 spill 文件」。它讲的是已完成的 spill（流未越上限、文件完整），与本文讲的未完成 spill 是两回事。引用 :139 时若不写清「已完成」，会得出与本条相反的结论。

因此本条的准确表述是披露层级不匹配：删除行为写在子系统包的 README 里，而模型侧唯一可见的信号是一个不说明任何成因的占位符。模型和使用者都无法据它推断「spill 曾存在、因越界被删除、此后不再落盘」。

八、期望

不主张改变删除行为本身——删除是「spill 文件必须承载完整流」这一保证的必然代价，这一点我认可。期望的是让模型侧的披露与已知事实对齐，任取其一：

1. 让 (unavailable) 携带成因，例如区分「未创建」与「已删除」，使模型能判断该内容是否曾经可读；
2. 若维持单一占位符，请在 dsh-tool-pwsh / dsh-tool-bash 的 README 里说明该取值的全部成因（至少本文第五节列出的三种），使读者不必反查 dsh-subprocess-local 的实现才能理解它。

九、版本口径

本条的证据与结论限定在 0.1.5-rc.3（latest）。本机未安装 0.1.7 线，我也没有该线产物可核对，因此不对新版是否仍成立作任何判定。若维护者以新版为判定基准，请以维护者自己的核对为准。

[PerryLink]

你的三处更正我接受——我引错了层，而且引错了对象

1. 先承认错在哪

我把 dsh-spill-policy 的 README 那句当成了"本条应当满足的标准"。你指出的是对的：

• 那句话描述的是该策略自己的失败分支（缺少所有者 / 缺少 spill 后端 / 存储失败 / 图像路径不可用 ⇒ 记警告并保留原始内联结果）；
• 它与"子进程收集器删除自己不完整的 spill 文件"没有因果关系。

⇒ 我把两条独立路径混为一谈，正如你说，会把本条从"披露不携带成因"误读成"spill 策略违反了自述承诺"，而后者不成立。这一处是我的错，请你按你的准确表述提交。

顺带交代我当初为什么会引它：packages/spill/spill-policy/README.md:65 确实含 unavailable 这个词（"...or unavailable execution-world image path logs a warning and keeps the original content"）。所以你测到的"该包全树零命中"与我看到的"README 里有这个词"并不矛盾——我们看的是包内代码与仓库 README两个面。但这不改变结论：那句话不是本条的判据。

2. 你的两处引用我在最新版上核过了，都成立

当前 HEAD = dsh-v0.2.1-alpha.1（比 0.1.5-rc.3 晚了 714 个提交），packages/subprocess/subprocess-local/README.md 里那两句仍然逐字对应你的读法：

A stream larger than the spill cap discards its incomplete spill and returns only the marked truncated tail.

Completed spill files are not deleted — bounded full-output recovery files accumulate under the OS tmpdir until something external cleans them…

⇒ 也就是说："删除不完整 spill"是写明的设计意图，而"不删除已完成的 spill"讲的是另一回事——你提醒"引 :139 时必须写清『已完成』"这一点完全正确，否则会得出与本条相反的结论。

3. 一条版本提示（对你有用）

(unavailable) 那条契约行现在确实在工具包（与你的定位一致）：packages/shell/tool-bash/README.md（以及 packages/jobs/tool-jobs/src/render.ts）里都能检索到 full output:。

但请注意目录在 0.2 线搬过家：packages/tool/ 已经不存在，工具包现在在 packages/shell/ 下（tool-bash、tool-pwsh）。⇒ 包名 dsh-tool-pwsh 不变，仓库路径变了。你若要在报告里给"源码位置"，建议写成 packages/shell/tool-pwsh，并同时保留包名——这样跨版本都可核。

4. 你的第 8 节诉求我支持

"不主张改变删除行为，只要求模型侧披露与已知事实对齐"——这个定性我认为是对的，而且第 2 条（在工具包 README 里列全 (unavailable) 的成因）成本极低、收益明确，建议作为首选。

5. 版本口径

你已声明结论限定在 0.1.5-rc.3。⇒建议补跑一次：npm i -g @deepseek-ai/dsh（现在 latest = 0.2.0-rc.2，不再是旧的 0.1.5-rc.3）后复核第 1、2 节那两处引用是否仍逐字相同。注意这条与我此前给过你的"别用 latest"相反——那是我 09 月的旧结论，现已废止（见登记表 §0.170）。