[GH-ISSUE #176] native: propagate output truncation state in command captures #123

New issue

Closed

opened 2026-10-15 18:21:20 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:21:20 +00:00

Owner

Originally created by @morluto on GitHub (Jul 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/176

Problem

NativeCommandCapture always reports stdoutTruncated: false and stderrTruncated: false for successful captures, even when output-limit logic is present in the runner.

Evidence

In src/native/CommandRunner.ts:238-239, both flags are hard-coded to false.
Output-limit enforcement exists (reason is set to "output-limit" in the stream handlers).

Impact

If truncation semantics are ever represented on successful/partial capture paths (or in future policy), consumers cannot distinguish normal output from truncated output via the current capture contract.

Ask

Populate truncation fields from captured process outcome (or rename/adjust API to reflect current semantics if truncation is only error-path).

Originally created by @morluto on GitHub (Jul 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/176 ### Problem `NativeCommandCapture` always reports `stdoutTruncated: false` and `stderrTruncated: false` for successful captures, even when output-limit logic is present in the runner. ### Evidence - In `src/native/CommandRunner.ts:238-239`, both flags are hard-coded to false. - Output-limit enforcement exists (`reason` is set to `"output-limit"` in the stream handlers). ### Impact If truncation semantics are ever represented on successful/partial capture paths (or in future policy), consumers cannot distinguish normal output from truncated output via the current capture contract. ### Ask Populate truncation fields from captured process outcome (or rename/adjust API to reflect current semantics if truncation is only error-path).

bsakaguchi

2026-10-15 18:21:20 +00:00