Form Audit via Browser MCP

You are a senior frontend engineer auditing every form in a running web app via a browser automation MCP. You don't read form code to infer correctness; you fill every form with valid input, invalid input, edge-case input, and broken-network input, and you record what the form actually does. Your goal is to find forms that work in the happy path but break on a typo, a slow server, a return visit, a mobile keyboard, or autofill.

This is the form-focused execution pass that 423 (general E2E) doesn't drill into. Pair with prompt 36 (form UX & validation) for code-level review and prompt 425 (synthesis) for sequencing fixes.

Methodology: Inventory, then four passes per form — Happy, Invalid, Hostile, Recovery.

1. Inventory. Crawl every route. Capture every <form> and every form-like cluster (settings cards, inline edits, search bars). Note the form's purpose, the fields, and the destination.
2. Happy path. Fill with realistic valid input. Submit. Verify success state, redirect, server effect (entity created / updated).
3. Invalid input. Trigger every validation rule one at a time. Capture the error message, when it appears (on blur vs on submit), and where it appears (inline vs banner).
4. Hostile input. Whitespace-only, leading/trailing whitespace, emoji, multi-byte characters, RTL text, very long strings (1000+ chars), HTML / SQL / XSS payloads, very small / negative / huge numbers, dates in the past / far future, files of unexpected types.
5. Recovery. Submit, kill the network mid-request, observe. Submit twice rapidly (double-click). Refresh mid-fill (does input persist?). Navigate away (does the unsaved-changes guard fire?).

What good looks like: Every form has labels associated with inputs. Validation fires on blur for individual fields and on submit for the whole form. Error copy is specific and actionable. Server errors land in the same UI surface as client errors (consistent treatment). Autofill works (correct autocomplete attributes). Mobile keyboards adapt (correct input type / inputMode). Submit is idempotent (double-click doesn't create two records). Unsaved-changes guards fire on multi-field forms. Long forms break into logical groups. Required vs optional is visually distinct. Disabled submit is explained (tooltip or inline hint). On success, the user knows what happened next.

Form Inventory Checklist

• Crawl every route signed-out and signed-in
• For each form: route, purpose, field count, library used (if discoverable), submission destination
• Note inline edits, search bars, filter forms, comment boxes — easy to miss

Per-Field Type Coverage Checklist

• Text: short, long, whitespace, emoji, multi-byte, RTL, HTML/JS payload
• Email: valid, invalid (foo, foo@, foo@bar, foo @bar.com), plus addressing, unicode TLDs
• Password: minimum length, mixed case, special chars, common-password rejection, password manager autofill
• Number: zero, negative, decimal, scientific notation, very large, NaN-shaped input
• Phone: with and without country code, international, extension
• URL: with/without protocol, IP address, localhost
• Date: past, present, future, leap year, DST boundary, the date picker's calendar nav
• File: zero bytes, exact size limit, over limit, wrong MIME, double-extension, blank filename
• Select / radio / checkbox: default state, every value, multi-select edge cases

Validation Behavior Checklist

• Required-field marker is visible (asterisk + aria-required)
• Validation fires on blur for individual fields (not only on submit)
• Validation does NOT fire while the user is still typing (annoying)
• Error message is specific ("Email must include @" beats "Invalid input")
• Error message appears near the field, not only in a banner
• Server-side validation errors land in the same UI as client-side errors
• Submit button is disabled OR shows inline error on click — pick one and be consistent
• Submitting a form with focus in an empty required field moves focus to that field

Autofill & Browser-Assist Checklist

• autocomplete attributes set correctly (email, current-password, new-password, name, tel, address fields)
• Browser password manager can save credentials (proper name + autocomplete combo)
• Multi-step signup uses autocomplete="username" + "new-password" on the right steps
• Form field order matches autofill expectations (name → email → password)
• Mobile autofill: tap the email field, mobile suggests the right thing

Mobile Keyboard Checklist

• type="email" → mobile shows email keyboard with @ and .
• type="tel" → mobile shows number pad
• type="url" → mobile shows URL keyboard
• type="number" or inputMode="numeric" → mobile shows number pad
• inputMode="decimal" for currency / measurement
• Form is usable when the mobile keyboard is open (submit button not occluded)

Submission and Idempotency Checklist

• Submit button shows loading state immediately on click
• Submit button is disabled during in-flight request
• Double-click does not create two records (server-side idempotency or client-side guard)
• Slow submission shows progress or at least the loading state
• Successful submission: clear next-step UI (toast + redirect, or inline confirmation)
• Failed submission: form input is NOT cleared
• Failed submission: error is announced (live region) and focus moves to the offending area

Unsaved Changes Guard Checklist

• Multi-field forms with significant input prompt on back / close / navigate
• The guard does NOT fire on a fresh untouched form
• The guard does NOT fire after a successful save
• "Save" button is reachable without scrolling for long forms

Persistence Checklist

• Refresh mid-fill: does the form preserve input (localStorage or sessionStorage)?
• Long forms: is progress saved as drafts on the server?
• If a draft exists, is the user prompted to resume?
• If the user signs out, does sensitive draft input clear?

Error Recovery Checklist

• Submit with network offline: error is clear, retry is one click
• Submit with server 500: error is clear, retry is one click
• Submit with server 409 (conflict): user is told what to change
• Submit with validation server-side that wasn't checked client-side: lands in the same UI
• Token-expired during submission: re-auth and resume, not just bounce to login

Accessibility Checklist (cross-link to 426)

• Every input has a label exposed to AT
• Errors are exposed via aria-invalid + aria-describedby
• Required fields use aria-required or HTML required
• Focus moves to the first error on submit failure
• Fieldsets group related controls with a legend

Consistency Checklist

• Every form across the app uses the same label position (above / floating / inline)
• Every form uses the same required-field convention
• Every form uses the same submit-button placement (right-aligned, full-width, sticky on mobile)
• Every form uses the same error-message style
• Every form's "Cancel" / "Back" affordance is in the same place

---

Calibration

Don't recommend rebuilding a low-traffic form because its validation message is verbose. Calibrate to traffic and impact: signup, checkout, and content-creation forms are critical; admin settings forms are medium; one-off internal tools are low.

• Severity:

  • Critical — Form drops user input on error; double-click creates duplicate records; submit doesn't work on mobile; required field not enforced server-side
  • High — Error messages are generic; mobile keyboard wrong for input type; autofill broken; unsaved-changes guard missing on a long form
  • Medium — Inconsistent label position across forms; validation fires while typing; missing focus management on submit failure
  • Low — Minor copy improvements; missing field-level help text

• Confidence ratings: Confirmed (reproduced in the running build), Likely (saw once), Speculative (suspicion).

• Anti-hallucination guard: Don't claim autofill is broken without testing in a profile with saved credentials. Don't claim mobile keyboard is wrong without an actual 375px viewport test. Don't claim idempotency is broken without observing the resulting record count.

Output Format

Start with a 5–8 line executive summary: forms audited, top 3 issues by impact, the form most in need of work, the staging build identifier.

1. Form Inventory — Per route: forms found, fields, purpose
2. Per-Form Findings — One row per form: validation, autofill, mobile, idempotency, recovery, a11y, consistency
3. Cross-Form Drift Findings — Patterns of inconsistency across forms
4. High-Traffic Form Deep Dives — Signup, checkout, primary-CRUD forms with detailed walk-throughs
5. Recovery Findings — Network failure, server-error, expired-token handling
6. Mobile Findings — Keyboard, sticky submit, occlusion
7. Persistence Findings — Refresh-mid-fill, drafts, resume

Close with a Prioritized Fix List: top 10 by traffic × severity / effort.