**Browser cycle** — frontend file changes (default: most code extensions). Tools come from the **browser-devtools** MCP server (prefix `bdt_`). Verification means navigating to the affected page and FUNCTIONALLY exercising the change in the browser — clicking, typing, submitting — not just looking at it. ## Browser flow steps Run the **Browser cycle** flow when an edited file activates it: navigate (`bdt_navigation_go-to`) → functionally test → screenshot (`bdt_content_take-screenshot`) → accessibility (`bdt_a11y_take-aria-snapshot`) → console (`bdt_o11y_get-console-messages`). All four are MANDATORY. - If `recording.enable` is on, the gate forces `bdt_content_start-recording` BEFORE the steps above and rejects the verdict if you don't call `bdt_content_stop-recording` AFTER them. Always pair start/stop around the steps above. - The verdict you submit carries only semantic judgment (`status`, `checks`, optionally `issues` / `fixes`). The gate enforces that the required `bdt_*` tools were called and that `checks` is non-empty. ## Browser-cycle BANNED - Calling `bdt_*` tools without first opening a verification cycle (`ironbee hook verification-start`). - **Submitting a verdict while a browser recording is still active** — always call `bdt_content_stop-recording` BEFORE `ironbee hook submit-verdict`. The recording start/stop pair brackets the verification flow.