From ea8629ecfe40c120a3ef0d05789617ca9eaf0568 Mon Sep 17 00:00:00 2001 From: bin101 Date: Thu, 9 Jul 2026 11:03:29 +0200 Subject: [PATCH] docs: never drive the user's live browser for UI verification A "verify the fix" step opened new windows in the user's real, running Safari/Chrome via AppleScript to screenshot the stats page, interrupting their actual in-progress work in those apps. Document that UI verification must use an isolated browser-agent/headless browser and report BLOCKED instead of falling back to the user's live desktop session. --- CLAUDE.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index a1bc63a..89a6270 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -96,6 +96,18 @@ Known unavoidable external warnings must be added to the `filterwarnings` ignore > step, or quality requirement, update this file in the same PR. CLAUDE.md is the single source > of truth for how this project is built and maintained. +### Browser-based UI verification + +When verifying frontend/UI changes visually, always use an isolated, dedicated browser +automation tool (e.g. a headless/dedicated Playwright or browser-agent instance) — +**never** drive the user's currently-running personal browser (Safari, Chrome, etc.) via +AppleScript/UI automation or by opening new windows/tabs in it. Doing so interferes with the +user's actual, in-progress work (open tabs, unsaved state). + +If no such isolated browser tool is available in the environment, say so explicitly and +report verification as blocked/skipped rather than falling back to automating the user's +live browser session. + ### Docker ```bash