Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.gitignore:
- Around line 1-34: The .gitignore contains duplicated patterns; remove the
redundant entries so each ignore pattern appears only once (e.g. duplicate lines
for .DS_Store, .env, .npmrc, .pnpm-store, .qlty/* entries, *.png, *.tsbuildinfo,
coverage, dist, examples/report.md, examples/snapshots/*_T*.snapshot.deepnote,
and node_modules) ensuring the file only lists unique patterns; update the
.gitignore by deleting the duplicate lines and keep one canonical occurrence of
each pattern.

In `@packages/cli/src/commands/run.test.ts`:
- Around line 568-595: The test "renders output immediately via onOutput in
non-machine mode" asserts only for a checkmark but not the streamed text; update
the test to assert that the streamed output "Hello World" was written to stdout
by checking the spy used for process.stdout.write (stdoutWriteSpy) rather than
consoleLogSpy, e.g., verify that stdoutWriteSpy was called with or contains
"Hello World" after invoking action(HELLO_WORLD_FILE, {}); locate the
mockRunProject stub and the test block around it and add the assertion
referencing stdoutWriteSpy and the action/HELLO_WORLD_FILE test flow.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/cli/src/commands/run.test.ts`:
- Around line 192-199: The mock implementation for mockRunProject calls
lifecycle callbacks fire-and-forget causing race conditions; change the
implementation in mockRunProject.mockImplementation to await the async callbacks
on options (await options?.onBlockStart?.(TEST_BLOCK, 0, 1), await
options?.onOutput?.(TEST_BLOCK.id, blockOutput) for each streamedOutputs
iteration, and await options?.onBlockDone?.(result)) so the mock resolves only
after all lifecycle handlers complete, ensuring tests wait for the same async
contract used in run.ts.
- Around line 609-653: The tests don't actually exercise the onOutput path
because they include the same chunk in result.outputs as well as streamedOutputs
and never assert that interactive rendering stayed silent in JSON mode; update
the two tests that call setupStreamingRun/action (the human-mode and
machine-mode cases) so that: for the human-mode test (the one calling
action(HELLO_WORLD_FILE, {})) provide the chunk only via streamedOutputs and
ensure result.outputs is empty so onOutput must do the rendering, then assert
stdoutWriteSpy (or getOutput(consoleLogSpy)) contains "Hello World" and the
success marker; for the machine-mode test (action(HELLO_WORLD_FILE, { output:
'json' })), keep the chunk in streamedOutputs but assert that no interactive
writes occurred (e.g., stdoutWriteSpy has no calls containing "Hello World") and
still parse getOutput(consoleLogSpy) to verify parsed.blocks[0].outputs contains
the chunk; change setupStreamingRun, test inputs, and assertions accordingly to
reference setupStreamingRun, action, HELLO_WORLD_FILE, stdoutWriteSpy,
consoleLogSpy, and getOutput.

---

Outside diff comments:
In `@packages/cli/src/commands/run.ts`:
- Around line 1040-1094: The boolean blocksWithStreamedOutput is too coarse —
change streaming state to track whether the last streamed chunk for a block
ended with a newline and use that in onBlockDone to avoid inserting an extra
blank line; when onOutput(streaming) runs for a blockId set both
state.blocksWithStreamedOutput.add(blockId) and
state.blocksLastChunkEndedWithNewline.set(blockId,
blockOutput.stream?.text?.endsWith('\n') ?? false) (use the same symbols
onOutput, blockOutput), and in onBlockDone compute hadStreamedOutput =
state.blocksWithStreamedOutput.delete(result.blockId) and lastEndedNewline =
state.blocksLastChunkEndedWithNewline.get(result.blockId) then remove the map
entry; change prefix to insert '\n' only when state.agentStreamed is true OR
(hadStreamedOutput is true and lastEndedNewline is false) so you don't add an
extra newline after output that already ended with '\n'.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/cli/src/commands/run.test.ts`:
- Around line 658-673: The test currently leaves payloads in result.outputs
which allows non-stream fallback rendering to satisfy assertions; update the
tests (those invoking setupStreamingRun and any other cases around lines
referencing streamedOutputs/result) to remove result.outputs so the test
exercises stream-only paths — ensure setupStreamingRun calls supply
streamedOutputs but do not include outputs in the result object (and do the same
for the other case around lines 709–721) so only the streaming path (not
onBlockDone fallback rendering) can pass the assertions.
- Around line 595-755: Add unit tests in the existing "streaming output via
onOutput" suite to cover streamed stderr and special-character outputs: call
setupStreamingRun with streamedOutputs containing an output object with
output_type: 'stream', name: 'stderr' and text including unicode and newline
characters (e.g., "error ✓ 🚀\nsecond line"), then invoke
action(HELLO_WORLD_FILE, {}) and assert using stdoutWriteSpy (or a
stderrWriteSpy if present) and getLogCalls(consoleLogSpy) that stderr text is
handled distinctly from stdout (not rendered in machine JSON mode, included in
blocks outputs in JSON), that special characters and newlines are preserved in
rendered output, and that newline/blank-line sequencing behavior (the tests
using getLogCalls, serverReadyIdx, and checkIdx) still holds for stderr streams;
reuse existing helpers setupStreamingRun, action, getOutput, getLogCalls,
mockRunProject identifiers to locate where to add these cases.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@packages/cli/src/commands/run.test.ts`:
- Around line 649-659: The tests currently include payloads in both
streamedOutputs and result.outputs, allowing a fallback onBlockDone path to
satisfy assertions; update the two failing tests to be stream-only by removing
payloads from the result.outputs in the setupStreamingRun call (i.e., leave
streamedOutputs populated but set result.outputs to an empty array or undefined)
and then assert only against streamedOutputs/streaming state (not
result.outputs). Target the setupStreamingRun usage and the assertions that
reference streamed outputs in run.test.ts so the expectations rely solely on the
streaming path rather than onBlockDone fallback.