[Bug / Design] PTC 内部工具返回值不应截断：read 缺少结构化截断状态，bash 返回已截断的 stdout

[TTTPOB]

请求：PTC 内部工具返回值不应截断

PTC 程序需要完整数据来解析和计算。展示文本、UI 和日志可以截断或 spill，但不应改变 await tools.read(...) / await tools.bash(...) 交给程序的数据。

官方仓库当前 HEAD d743267388641bc76f17c45ce8b4c231aed1d32c 仍存在以下行为：工具在生成返回值之前先截断，PTC 随后将不完整数据作为成功结果交给程序。

当前行为

bash：stdout.text 只有尾部

默认每流内存上限为 64,000 字节。超限后，输出收集器丢弃头部；工具直接将保留的尾部放进 stdout.text。

PTC 返回对象带有 truncated: true，可用时有 spillPath，但不会自动恢复全文。因此这类代码会因数据不完整而失败，即使命令正常退出：

const r = await tools.bash({
  command: 'command-that-emits-large-json',
  description: 'Read structured command output',
});
const data = JSON.parse(r.stdout.text);

源码：默认限制、丢弃头部、返回值映射。

read：行文本被截断，总字节截断没有状态字段

默认限制：单行 2,000 个 UTF-16 码元，选中行总计 50 KiB。

• 单行超限：lines[i].text 被替换为行头加 ... (line truncated to 2000 chars)。提示混进程序数据，后半行丢失。对于单行 JSON，按行分页的 offset 无法取回剩余内容。
• 总字节超限：只返回部分选中行，内部 truncatedByBytes 没有进入返回对象。

返回 schema 只有 path / offset / lines / totalLines，没有截断状态。Output capped. Showing lines ... Use offset=... to continue. 是 render 阶段添加的展示文案，PTC 程序拿不到这句话。

程序可以比较最后返回行号和 totalLines，判断后面还有行，但不能直接区分正常分页与字节上限截断。

源码：默认限制、行与字节截断、schema 与展示提示、execute 返回对象。

截断发生在 PTC 值与展示分离之前

PTC binding 返回 result.value，spill-policy 处理展示/日志副本。这个分离机制保留了工具返回值，却无法恢复工具内部已经丢弃的原始数据。

源码：PTC binding、spill-policy。

最小验证

直接在内存中调用输出收集器与 read window 函数。已执行验证的两份源码与上述官方提交的 Git blob 完全一致。

import { OutputCollector } from './packages/subprocess/subprocess-local/src/output.ts';
import { buildWindow, READ_MAX_LINE_LENGTH, READ_MAX_BYTES } from './packages/fs/tool-fs/src/read-render.ts';

const source = JSON.stringify({ payload: 'x'.repeat(70000) });
const collector = new OutputCollector(64000, 'stdout', undefined);
collector.push(Buffer.from(source));
const output = collector.readFrom(0);

const window = await buildWindow([source], {
  offset: 1,
  limit: 2000,
  maxLineLength: READ_MAX_LINE_LENGTH,
  maxBytes: READ_MAX_BYTES,
}, 'memory-only.json');

// Parse each result independently.
for (const [name, text] of [
  ['original', source],
  ['bash collector', output.text],
  ['read window', window.lines[0].text],
]) {
  try {
    JSON.parse(text);
    console.log(name, 'OK');
  } catch (error) {
    console.log(name, error.name);
  }
}

数据	返回长度 / 状态	JSON.parse
原始 JSON	70,014 bytes	OK
bash collector	64,000 bytes，lossy=true	SyntaxError
read 第一行	2,034 UTF-16 码元，含截断后缀	SyntaxError

这是截断函数的内存复现；完整 PTC 链路通过上述官方源码核对。collector 不配置 spill，测试不写文件；启用 spill 时，内存返回值仍保留尾部，全文需要另行读取恢复文件。

期望行为

首选：PTC 内部不截断程序数据。

1. 将程序数据与模型/UI/日志的展示预算分开。
2. 保留用户主动指定的 read offset/limit 窗口，但不要在窗口内再用展示预算截断行内容或悄悄少返回行。
3. 大数据可使用完整可读文件、明确的分页或流式接口；达到实际资源硬上限时明确报错，避免成功返回不完整数据。

短期若仍保留截断，至少让 read 返回结构化的截断原因、每行截断状态及可行的恢复位置，并将提示从 lines[].text 中分离。补标志是降级方案，不替代 PTC 内部数据完整性的诉求。

相关讨论

• grep/read: line preview starts at column 0, hiding the match it just reported #4982：read/grep 的行头预览隐藏匹配，单行文件无法分页恢复。
• web_fetch 截断与 tool-result-pruner 剪裁均对上层不可感知，建议增加显式截断标记 #8973：要求 web_fetch / pruner 截断对上层可编程感知。
• [Bug] `workflow` tool clips its result to 50,000 chars BEFORE the spill policy runs; the spill file labelled "Full formatted result" is truncated and the rest is lost #6866：workflow 在 spill 前先截断格式化输出。
• spill 文件超过上限后被删除，披露退化为 (unavailable)（0.1.5-rc.3，附文件行号） #7854：shell spill 越界后不可用的披露问题。

本帖聚焦 PTC 程序收到的数据完整性，以及 read 的程序返回值与展示提示不对称。