Antigravity Browser QA

Instructions

Use Google Antigravity’s browser sub-agent for autonomous browser-based quality assurance. The browser sub-agent is powered by Gemini 3.1 Pro and uses multimodal visual reasoning to interact with web applications like a human tester — clicking elements by appearance rather than hard-coded DOM selectors.

Prerequisites:

• Antigravity v1.18.0+ (browser sub-agent minimum; ITI pins v1.107.0)
• Chrome browser installed (Antigravity’s browser extension connects to Chrome)
• Local dev environment running at a known URL
• Browser Allow List in Antigravity settings includes only *.local or your dev domain
• Plugin/feature activated in the local environment

Browser sub-agent capabilities:

Capability	Description
Visual-based testing	Evaluates UI elements by appearance and functionality, not DOM selectors
Screenshot capture	Automatic screenshots at each significant state change
Session recording	Full browser session recordings saved as Walkthrough artifacts
Visual regression	Baseline comparisons to detect unintended UI changes
Viewport testing	Tests at specified viewport widths (desktop, tablet, mobile)
Form interaction	Fills forms, clicks buttons, navigates multi-step flows
Error detection	Identifies console errors, HTTP failures, and visual anomalies

Standard browser QA dispatch (WordPress):

Pre-flight checklist:

• [ ] Local WordPress environment running at the dev URL
• [ ] Plugin activated in WordPress admin
• [ ] Admin credentials available
• [ ] Browser Allow List includes only the dev domain

/iti-design-agents

Navigate to [local dev URL]/wp-admin and log in with admin credentials.
Test [specific feature or admin screen].

For each test:
1. Record the session as a browser recording Artifact
2. Capture screenshots at each significant state
3. Verify against the UI checklist in /iti-design-agents:
   - Keyboard navigation works
   - Error states show actionable messages
   - Mobile viewport (375px) renders correctly
   - No raw PHP errors visible
4. Flag any failure as [TEST-FAILURE] with screenshot reference

Do not modify any source files. Do not save form data to production.

WordPress admin QA test matrix:

Area	What to verify
Settings page	All options save and load correctly; nonce validation works; default values display
Admin notices	Success/error/warning messages appear correctly; dismissible where appropriate
AJAX handlers	Spinner appears; response renders correctly; error states handled
Gutenberg blocks	Block renders in editor; block renders on frontend; block settings save
Classic editor metaboxes	Metabox renders; data saves on post save; data loads on post edit
REST endpoints	Authenticated access works; unauthenticated access returns 401; CORS headers present
Multisite	Network admin screens render; site-level vs network-level settings separated

Visual regression testing:

Set up baseline comparisons to detect unintended UI changes:

1. Capture baseline: Run browser QA on the current stable version and save screenshots as baseline artifacts
2. Compare after changes: Run the same browser QA flow after code changes
3. Review diff: The browser sub-agent highlights visual differences between baseline and current
4. Accept or reject: Intended changes become the new baseline; unintended changes get flagged as [TEST-FAILURE]

Configure in .agents/rules/:

## Visual Regression Rules
- Compare screenshots against baseline in [path/to/baseline/]
- Flag any pixel difference > 5% as [TEST-FAILURE]
- Ignore differences in dynamic content areas (timestamps, user avatars)

Viewport testing:

Standard viewport matrix for ITI products:

Viewport	Width	Use case
Desktop	1440px	Primary admin experience
Laptop	1024px	Smaller desktop/laptop
Tablet	768px	iPad portrait
Mobile	375px	iPhone SE / small mobile

Dispatch viewport-specific testing:

Test [feature] at these viewport widths: 1440px, 1024px, 768px, 375px.
At each viewport:
1. Screenshot the full page
2. Verify no content overflow or horizontal scroll
3. Verify all interactive elements are reachable
4. Flag any layout break as [TEST-FAILURE]

Tauri / native app testing (limitations):

Antigravity’s browser sub-agent cannot directly control native desktop windows. For Tauri apps:

• Use the Tauri dev build (cargo tauri dev) which renders in a webview
• The browser sub-agent can test the web content inside the webview if accessible at a local URL
• For truly native UI elements (title bar, system dialogs), test manually
• Use Antigravity’s code agent (not browser agent) for Rust backend logic testing

See the “Native App QA” prompt in .agents/workflows/prompt-library.md for the recommended dispatch pattern.

Headless mode and CI integration:

For automated CI pipelines, configure the browser sub-agent in headless mode:

In .agents/rules/:

## Browser Sub-Agent CI Configuration
- headless: true
- screenshot-on-failure: true
- viewport: 1440x900
- timeout: 30000

GitHub Actions integration:

1. Install Antigravity in the CI environment
2. Configure .agents/ with CI-specific rules (headless, no interactive prompts)
3. Run browser QA via Antigravity CLI: agy run --workflow browser-test
4. Collect screenshots and recordings as CI artifacts
5. Fail the pipeline if any [TEST-FAILURE] flags are present

Reviewing browser artifacts:

After the agent completes, open the Walkthrough artifact. Browser recordings and screenshots appear inline. For each [TEST-FAILURE]:

1. Review the screenshot
2. Decide: code fix, documentation update, or expected behavior?
3. If code fix: note it for diff review
4. If CLAUDE.md-worthy: note the [CONTEXT-UPDATE] for knowledge sync

Browser Allow List security:

Antigravity’s browser sub-agent can navigate to any URL unless restricted. For security:

• Restrict to *.local, localhost, or your specific dev domain
• Never allow agents to access production URLs, external APIs, or client environments
• Review browser history in session artifacts after every browser QA session
• If an external URL was accessed, investigate for data exposure

[TEST-FAILURE] flag format:

[TEST-FAILURE]
Screen: [admin page or feature name]
Viewport: [width]
Issue: [description of visual or functional failure]
Screenshot: [artifact reference or filename]
Severity: Critical | Major | Minor | Cosmetic

Cross-references:

• operations/documentation/antigravity-runbook.md — Phase 2, Step 6 (Browser QA with Subagents)
• operations/documentation/claude-code-workflow.md — Section 2.3 (Test/Debug Session)
• antigravity-testing skill — test agent dispatch and artifact review
• antigravity-debugging skill — debugging browser-visible issues
• test-plan-writing skill — test plan structure for browser test cases
• wordpress-development skill — WordPress UI conventions and security patterns

Outputs: Browser session recordings, screenshots at each significant state, visual regression comparison reports, [TEST-FAILURE] flags with severity classification, viewport compatibility reports, and CI pipeline test evidence.