/playwright — Browser Test Runner

You are running browser tests on behalf of Vera. The code review is already done. This step is the proof — the running application in a real browser, exercising real flows, catching what code reading never will.

Reference implementation: fde-demos-worlds — playwright.config.js + tests/shell.spec.js. When in doubt, follow that pattern.

Step 1 — Confirm Live Server

Check whether the dev server is running:

curl -s -o /dev/null -w "%{http_code}" http://localhost:5173/ 2>/dev/null
# or whichever port this project uses (3000, 4321, etc.)

If not running: start it in background (npm run dev / pnpm dev / pnpm dev:ui), wait for the port to respond, then continue. Do not proceed without a live server — a 000 or connection refused means every test will fail silently.

Step 2 — Check Playwright Setup

npx playwright --version 2>/dev/null || echo "NOT_INSTALLED"
ls playwright.config.js playwright.config.ts 2>/dev/null || echo "NO_CONFIG"
ls tests/*.spec.* 2>/dev/null || echo "NO_TESTS"

If Playwright is not installed:

npm install -D @playwright/test
npx playwright install chromium

If no playwright.config.js exists, create it — use the fde-demos-worlds pattern exactly:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  timeout: 30000,
  use: {
    baseURL: 'http://localhost:[PORT]',
    headless: true,
    viewport: { width: 1440, height: 900 },
  },
  webServer: {
    command: '[DEV_COMMAND]',
    url: 'http://localhost:[PORT]',
    reuseExistingServer: true,
    timeout: 30000,
  },
});

Fill in [PORT] and [DEV_COMMAND] from the project's package.json scripts.

Step 3 — Write Smoke Tests (if none exist)

If tests/ has no .spec.js or .spec.ts files, read the actual app source and generate tests/smoke.spec.js.

Read before writing:

• src/App.tsx or src/main.tsx — find all routes
• Component files for each route — find key UI elements (headings, buttons, forms, cards)
• package.json — confirm dev server command and port

Test structure — follow this pattern exactly (from fde-demos-worlds):

import { test, expect } from '@playwright/test';

// One test per route — minimum
test('[page name] loads — [key elements] visible', async ({ page }) => {
  await page.goto('/[route]');

  // Confirm the page actually rendered something meaningful
  await expect(page.locator('[specific visible element]')).toBeVisible();
  await expect(page.locator('[another key element]')).toBeVisible();
});

// Navigation flows — test that clicking things goes where expected
test('[flow name] — click [element] navigates to [route]', async ({ page }) => {
  await page.goto('/');
  await page.locator('[selector]').click();
  await expect(page).toHaveURL('/[expected-route]');
  await expect(page.locator('[element that proves the page loaded]')).toBeVisible();
});

// Form interactions — test enable/disable state, validation
test('[form name] — [button] disabled when [condition]', async ({ page }) => {
  await page.goto('/[route]');
  await expect(page.locator('button', { hasText: '[button text]' })).toBeDisabled();
});

// Content integrity — no markdown leaking, no raw tokens
test('[page] — no raw markdown markers in rendered output', async ({ page }) => {
  await page.goto('/[route]', { waitUntil: 'networkidle' });
  const bodyText = await page.locator('body').innerText();
  expect(bodyText).not.toContain('###');
  expect(bodyText).not.toMatch(/^##\s/m);
  expect(bodyText.trim().length).toBeGreaterThan(50);
});

Use exact text locators over CSS selectors where possible — page.locator('text=Start demo (English)') is more resilient than page.locator('.card .btn'). The fde-demos-worlds tests do this correctly.

Minimum test count: one test per route, one per significant interactive flow. Do not write tests you cannot verify against the running app — generic tests create false confidence.

Step 4 — Run Tests

npx playwright test --reporter=list 2>&1

If tests fail due to timing on first run, retry once:

npx playwright test --reporter=list --retries=1 2>&1

Do not retry more than once. Flaky is a signal, not a nuisance.

Capture full output: test names, pass/fail, error messages, line numbers on failures.

Step 5 — Manual Golden Path (always, even if all tests pass)

Automated tests cover routes that were already written into tests. The golden path covers what was just built. For every new feature in this delivery:

1. Navigate to it in the browser
2. Complete the primary action the user would take
3. Check the browser console — zero errors (F12 → Console)
4. Check the Network tab — zero failed requests (red rows)
5. Try one edge case: empty input, wrong value, fast click

Document each item: what you did, what you saw.

Step 6 — Report to Vera

PLAYWRIGHT REPORT
Date: YYYY-MM-DD
App: [name] at http://localhost:[PORT]
Tests: [N] run | [N] passed | [N] failed

Results:
✓ [test name]
✓ [test name]
✗ [test name] — [exact error message and line]

Console errors on golden path: [none / list]
Network failures on golden path: [none / list]

Manual golden path:
✓ [what you did — what happened]
✓ [what you did — what happened]
✗ [what you did — what failed]

Playwright verdict: PASS / FAIL / PARTIAL
[One sentence on overall state]

A FAIL here is a Vera BLOCKED. Code that reads correctly but fails in the browser has not been delivered.

Non-Negotiables

• No running server = no Playwright run = BLOCKER. Flag it. Do not approximate.
• Write tests from the actual source. Read the router and components before writing smoke.spec.js. Tests guessed from nothing create false confidence — worse than no tests.
• Console errors are failures. A page that renders but throws errors is broken.
• The golden path is not optional even if all tests pass. New features aren't in tests yet. Manual verification is the only proof for new code.
• This skill is called by Vera before every sign-off on any web app. Not sometimes. Not on big deliveries. Every time.

Step 7 — Write Playwright Sentinel

After reporting to Vera, write .squad/playwright-results.md with this format:

PLAYWRIGHT RESULTS — YYYY-MM-DD
Tests: [N] run | [N] passed | [N] failed
Console errors: [none / list]
Network failures: [none / list]
Golden path: [pass / fail]

Fill values from the Step 6 report. File presence (not content) is what the push gate checks — but write accurate content for Coach. Without this file, H2 in pre-push-vera.ps1 blocks the push on any project with playwright.config.*.

/deliver Step 4 deletes .squad/playwright-results.md as part of sentinel cleanup.