name: production-verification
description: "Verify the deployed application works as a real user would experience it — browser automation against live production, asset rendering checks, multi-variant verification. Use as Phase 9 of the deployment pipeline or for standalone production smoke testing."

Production Verification

Verify the deployed application works as a real user would experience it. This is not a unit test — it's a usability test against production.

Detect

Look for existing smoke test infrastructure:

• Smoke test scripts (test:smoke in package.json, Playwright smoke config)
• Health check endpoints
• Browser automation tools (Playwright, Cypress, MCP browser tools)
• curl-based verification scripts

What to Verify

• The app loads in a real browser (not just a 200 status code)
• Core user flows work end-to-end: create an account, perform the primary action, see the expected result
• UI renders correctly: icons display as icons (not as text fallbacks), styles load, interactive elements respond to clicks
• If the app is a game, play a game. If it's a dashboard, navigate all pages. If it has forms, submit them.
• Check for console errors, uncaught exceptions, and failed network requests during the entire flow

Asset Rendering Verification

After confirming routes return 200, verify that external resources (fonts, stylesheets, scripts, images) are actually loaded and applied — not just preloaded or referenced:

• Icon fonts render as glyphs, not as ligature text (e.g., seeing "delete" instead of a trash icon)
• CSS stylesheets appear as rel="stylesheet" in the served HTML, not just rel="preload" as="style"
• Images render with correct dimensions, not as broken placeholders
• Use curl on the production HTML and inspect the actual tags, or use browser automation to check computed styles

See lessons-learned.md items 1 and 2 for why this matters.

Multi-Variant Verification

If the app supports multiple locales, themes, or entry points, test at least two variants in production. A font, stylesheet, or API call that works in one locale may fail in another due to different SSG pages, caching boundaries, or conditional rendering paths.

• i18n apps: curl/test the default locale AND at least one alternate
• Themed apps: test both light and dark
• Feature flags: test the primary and at least one alternate configuration

See lessons-learned.md item 3 for the rationale.

How It Works in Practice

Playwright (or equivalent) opens a real browser, navigates to the production URL, and drives the full user flow through real browser interactions: clicking buttons, filling and submitting forms, following links, scrolling through content, uploading and downloading files, completing multi-step workflows, and reading rendered output.

The test should exercise the application the way the project's docs and specs say a user would — not a simplified version. Consult the project's README, CLAUDE.md, or test documentation to understand what user flows exist and automate them faithfully.

Playwright clicks are ~50ms each; database/API round-trips are typically 100-500ms; so multi-step flows completing in a few seconds per step is normal and expected.

If No Smoke Tests Exist

At minimum, curl the production URL and verify it returns 200. But flag this as a gap — a curl check only proves the server responds, not that the app works. Recommend adding browser-based smoke tests and update this skill with the new test commands once they exist.

Collect

• Test results (pass/fail for each check)
• Total duration
• Console/page errors
• Any application-specific metrics (API response times, items created, pages rendered, etc.)

Stop Conditions

STOP if: Smoke tests fail on production. The deployment is broken — investigate immediately.