[memtomem]

Follow-up to #254 / #255: the same defect on the start --trial path. It was found in review of #255. There is no separate issue, so this PR description carries the report.

What was wrong

When a trial step failed, TrialError joined three things with \n:

• the failed step,
• the last five lines of that step's output,
• the note that the trial folder was kept.

start then wrapped the message in a plain click.ClickException. The CLI error boundary escapes such a message to one line, so the user saw one long line with a literal \x0a between the parts, and the diagnostics became hard to read.

What changes

• TrialError(*lines) keeps the line structure in a lines tuple; str() is the newline join, as before.
• TrialSandbox._run puts each line of the failed step's output on its own line, prefixed with |. That is the label the error boundary already uses for a command's output (_output_lines), so external output never reads as syncmill's own line.
• run_trial re-raises with exc.lines plus the kept-folder line.
• start --trial raises _MultilineError(*exc.lines), so each line is still escaped on its own: an ESC in the step's output shows as \x1b.

Tests

• test_a_failed_trial_keeps_its_folder_and_says_where now asserts the exact lines instead of substrings.
• New: test_a_failed_step_keeps_each_output_line_on_its_own drives a real failing subprocess through TrialSandbox._run.
• New: test_start_prints_a_trial_failure_line_by_line checks the exact CLI output, including an escaped ESC on a labelled line.
• All three fail without the fix.

Verification

• Full suite: suite-run CLEAN on macOS.
• End to end, through the real cli entry point with a broken trial scenario: Error: no candidate passed verification; the trial scenario is broken and The trial folder was kept for inspection: … print on two lines, exit 1.
• Codex review: round 1 (focused) SHIP with no findings; round 2 (unprimed, no memories, diff only) SHIP with no findings.

🤖 Generated with Claude Code