Agentic workflows / Practical guide # How to verify a UI fix before marking feedback resolved A resolution record that connects the change to its evidence. [By CRRT](/)·November 2, 2026·3 min read [← All resources](/resources) ## The short answer Verify a UI fix by repeating the original reproduction steps on the changed build, checking the accepted outcome, and inspecting relevant nearby states or shared consumers. Record the build, checks performed, and anything unverified before marking the feedback resolved. ## 1\. Return to the accepted request Read the original observation and expected outcome before inspecting the implementation. Confirm that the feedback still describes the current product. A code change can be correct in isolation while addressing a different interpretation of the request. Find the original route, viewport, content, and interaction state. Use a specific build link or version so the reviewer and implementer are checking the same result. If the issue cannot be reproduced from the available context, record that limitation rather than treating an unrelated screenshot as proof. ## 2\. Repeat the task on the changed build Follow the original reproduction steps, then complete the next meaningful action. If the issue concerned a validation message, submit the invalid value, correct it, and confirm the successful path. If it concerned a menu, open, use, and dismiss the menu in the relevant layout. Compare the result with the approved outcome. A screenshot can support a visual check, but the behavior often needs direct interaction. Label evidence accurately: a unit test, a screenshot comparison, and a manual task review establish different things. Copy & adapt ``` UI fix verification Request: [accepted feedback link] Build: [URL and version] Original state: [route, viewport, content, interaction] Expected: [observable outcome] Checked: [reproduction steps and resulting behavior] Nearby checks: [responsive state or shared consumers] Evidence: [screenshots, test output, or review notes] Unverified: [remaining limits] Decision: [resolved, needs correction, or needs a product decision] ``` ## 3\. Inspect the meaningful impact around the fix Choose neighboring checks based on what changed. A shared spacing token needs more than the original screen. A local wrapper change may need a narrow layout and long content. A keyboard interaction change needs a focus and activation check. Ask which consumers were inspected and why they were representative. Do not claim that a library-wide change is safe because one example looks better. Equally, avoid retesting an entire application for an isolated copy adjustment when there is no evidence of wider impact. * Check the original viewport and a nearby width when layout changed. * Review another consumer when a shared component or token changed. * Check keyboard behavior when controls or focus handling changed. * Confirm that a visual improvement preserves the intended task. ## 4\. Record the decision and remaining limits State what was fixed in terms of the original outcome, then list what was actually checked. If something remains unverified, say so and identify who will decide whether it blocks release. This makes a resolution useful to the next reviewer instead of merely changing a status. When an agent implements the correction, keep human review distinct from its completion report. CRRT’s handoff workflow preserves that boundary. If the result misses the accepted outcome, reopen or follow up with the observed difference, the changed build, and the specific check that still fails. ## Common questions ### Are passing automated tests enough to resolve visual feedback? Only if those tests establish the accepted outcome and relevant impact. Many visual or interaction requests also need a direct review of the running product. ### What should I include when a fix still fails? Identify the changed build, repeatable state, expected result, and remaining difference. Separate the original unresolved problem from unrelated new observations. ## Sources & further reading * [CRRT: human review and agent completion](https://crrt.ai/docs/agent-handoff) * [Playwright: what screenshot comparisons measure](https://playwright.dev/docs/test-snapshots) Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project. Keep going ## Put the next piece in place. [ Practical guide · 3 min read ### How to scope one visual fix for a coding agent A bounded implementation brief with a clear review point. ](/resources/scope-a-visual-fix)[ Practical guide · 3 min read ### Visual feedback vs visual regression testing: when to use each A practical way to combine human judgment with screenshot checks. ](/resources/visual-feedback-vs-visual-regression) ## See something off? Ship the fix. Pin the feedback. Give your coding agent the context. Review what comes back. [Try CRRT](/docs/install)