devlyn-cli 1.15.0 → 2.1.0

package/config/skills/devlyn:browser-validate/SKILL.md

@@ -1,164 +0,0 @@
----
-name: devlyn:browser-validate
-description: Browser-based validation for web applications — verifies that implemented features actually work by testing them in a real browser. Starts the dev server, tests the feature end-to-end (click buttons, fill forms, verify results), and reports what's broken with screenshot evidence. Use this skill whenever the user says "test in browser", "check if it works", "does the feature work", "browser test", "validate the UI", or when auto-resolve needs to verify web changes actually function correctly. Also use proactively after implementing UI changes. The primary goal is feature verification, not just checking if pages render.
----
-
-Verify that implemented features actually work in the browser. The primary job is to test the feature that was just built — click the button, fill the form, check the result. Smoke tests and visual checks are supporting checks, not the main event.
-
-The whole point of browser validation is to catch the gap between "code looks correct" and "user can actually do the thing." Static analysis and unit tests can confirm the code is well-structured. Browser validation confirms it *works*.
-
-<config>
-$ARGUMENTS
-</config>
-
-<workflow>
-
-## PHASE 1: DETECT
-
-1. **What was built**: This is the most important input. Read `.devlyn/done-criteria.md` if it exists — it tells you what the feature is supposed to do. If it doesn't exist, read `git diff --stat` and `git log -1` to understand what changed. You need to know what to test before anything else.
-
-2. **Framework detection**: Read `package.json` → identify framework and start command from `scripts.dev`, `scripts.start`, or `scripts.preview`.
-
-3. **Port inference**: Defaults — Next.js: 3000, Vite: 5173, CRA: 3000, Nuxt: 3000, Astro: 4321, Angular: 4200. Override with `--port` flag.
-
-4. **Affected routes**: Map changed files to routes (e.g., `app/dashboard/page.tsx` → `/dashboard`).
-
-5. **Tier selection** — pick the best available browser tool. **You must verify each tier actually works before committing to it** — tools can be registered but not connected:
-   - **Tier 1 probe** (Chrome DevTools): Check if `mcp__claude-in-chrome__*` tools exist. If they do, load `mcp__claude-in-chrome__tabs_context_mcp` via ToolSearch and call it. If the call **succeeds** (returns tab data without error), use Tier 1. Read `references/tier1-chrome.md`. If the call **fails** (timeout, connection error, extension not running), Tier 1 is unavailable — fall through to Tier 2.
-   - **Tier 2 probe** (Playwright): Check if `mcp__playwright__*` tools exist (try ToolSearch for `mcp__playwright__browser_navigate`). If they exist and respond, use Tier 2 Mode A. Else run `npx playwright --version 2>/dev/null` — if it succeeds, use Tier 2 Mode B. Read `references/tier2-playwright.md`.
-   - **Tier 3** (HTTP smoke): Fallback when no browser tool is functional. Read `references/tier3-curl.md`.
-   
-   **Critical rule**: Never treat a tier as available just because its tools appear in the tool list. Deferred/registered tools may not have a running backend. Always probe before committing.
-
-6. **Skip gate**: If no web-relevant files changed (no `*.tsx`, `*.jsx`, `*.vue`, `*.svelte`, `*.astro`, `*.css`, `*.scss`, `*.html`, `page.*`, `layout.*`, `route.*`, `+page.*`, `+layout.*`), skip. Report: "Browser validation skipped — no web changes detected."
-
-7. **Parse flags** from `<config>`:
-   - `--skip-feature` — skip feature testing, only run smoke + visual
-   - `--port PORT` — override detected port
-   - `--tier N` — force a specific tier (1, 2, or 3)
-   - `--mobile-only` / `--desktop-only` — limit viewport testing
-   - `--topic SLUG` — override the auto-derived screenshot topic slug
-
-8. **Derive the screenshot topic slug**. All screenshots for this run go under `.devlyn/screenshots/<topic-slug>/` so runs for different features don't pile up together. Resolution order:
-   1. `--topic` flag value, kebab-cased
-   2. First non-blank heading/line of `.devlyn/done-criteria.md` (strip `#`, kebab-case, max 40 chars)
-   3. Current git branch name, if not `main`/`master`/`HEAD`
-   4. Fallback: `run-<YYYYMMDD-HHMM>`
-
-   Then wipe and recreate the topic dir (fresh evidence per run; don't touch other topics' dirs):
-   ```bash
-   SCREENSHOT_DIR=".devlyn/screenshots/<topic-slug>"
-   rm -rf "$SCREENSHOT_DIR"
-   mkdir -p "$SCREENSHOT_DIR"/{smoke,feature,visual}
-   ```
-
-   Record `$SCREENSHOT_DIR` and reuse it through the run. All screenshot paths below are **relative to `$SCREENSHOT_DIR`**:
-   - Smoke: `smoke/<route-slug>.png` (root → `smoke/root.png`)
-   - Feature: `feature/<criterion-slug>-step<N>.png`
-   - Visual: `visual/<viewport>-<route-slug>.png` (e.g., `visual/mobile-dashboard.png`)
-
-Announce:
-```
-Browser validation starting
-Feature: [what was built, from done-criteria or git diff]
-Framework: [detected] | Port: [PORT] | Tier: [N — name]
-Topic: [topic-slug] → .devlyn/screenshots/<topic-slug>/
-Phases: Server → Smoke → Feature Test → Visual → Report
-```
-
-## PHASE 2: SERVER
-
-Get the dev server running. If it doesn't start, diagnose and fix — don't just report failure.
-
-1. Start the dev server in background via Bash with `run_in_background: true`.
-2. Health-check: poll `http://localhost:PORT` every 2s, timeout 30s. Ready when you get an HTTP response.
-3. **If it doesn't come up — troubleshoot** (up to 2 attempts): read stderr for the error, fix it (npm install, port conflict, build error, etc.), restart, re-check.
-4. If still down after 2 attempts: write BLOCKED verdict and stop.
-
-## PHASE 3: SMOKE (quick prerequisite)
-
-Quick check that the app is alive. This is not the main test — it's a gate to make sure feature testing is even possible.
-
-Navigate to `/` and each affected route. For each page, judge: is this the actual application, or an error page? A connection error, framework error overlay, or blank shell is not the app. If broken, try to fix (read console errors, fix source, let hot-reload pick it up). Up to 2 fix attempts per route.
-
-**Tier downgrade on failure**: If you're on Tier 1 or Tier 2 Mode A and the browser tool consistently fails during smoke (connection errors, timeouts, extension disconnected), **do not skip browser testing**. Instead, downgrade to the next tier (Tier 1 → Tier 2 → Tier 3), re-read the corresponding reference file, and retry the smoke phase with the new tier. Announce: `"Tier [N] browser tools not responding — downgrading to Tier [N+1]."` The goal is to always run the best available browser test, not to give up.
-
-If the app isn't rendering, the verdict is BLOCKED — feature testing can't happen.
-
-## PHASE 4: FEATURE TEST (the main event)
-
-This is the primary purpose of browser validation. Everything else is in service of getting here.
-
-Read `.devlyn/done-criteria.md` (or infer from git diff what was built). For each criterion that describes something a user can do or see in the UI, test it end-to-end in the browser:
-
-1. **Plan the test**: What would a user do to verify this feature works? Navigate where, click what, type what, expect what result?
-2. **Execute it**: Navigate to the page, find the interactive elements, perform the actions, verify the outcome. Read `references/flow-testing.md` for patterns on converting criteria to browser steps.
-3. **Capture evidence**: Screenshot at each key step. Record console errors and network failures that happen during the interaction.
-4. **If it fails — try to fix**: Read the error (console, network, or the UI state) to understand why the feature broke. Fix the source code, let hot-reload update, and re-test. Up to 2 fix attempts per criterion.
-5. **Record the result**: For each criterion — PASS (feature works as specified), FAIL (feature doesn't work, include what went wrong), SKIPPED (criterion isn't browser-testable, e.g., "API returns 401"), or UNVERIFIABLE (feature depends on external services not available in the test environment — e.g., real API keys, third-party auth, paid services).
-
-**Don't churn on external dependencies.** If a feature test is blocked because an API times out, a third-party service isn't configured, or auth credentials aren't available — that's not a bug to fix, it's a test environment limitation. Note it as UNVERIFIABLE, move on to the next criterion. Don't spend more than 30 seconds waiting for a response that's never coming. The goal is to verify what *can* be verified in the current environment, and be honest about what can't.
-
-The verdict depends primarily on this phase. If the implemented features don't work in the browser, the validation fails — even if every page renders perfectly and the layout looks great. And if most features couldn't be verified due to environment limitations, be honest about that — don't call it PASS.
-
-## PHASE 5: VISUAL (supporting check)
-
-Quick layout check at two viewports (skip if `--mobile-only` or `--desktop-only`):
-
-1. **Mobile** (375x812): screenshot each affected route, check for overflow/overlap/unreadable text
-2. **Desktop** (1280x800): screenshot each affected route, check for broken layouts
-
-Judgment-based — look at the screenshots and report visible issues.
-
-## PHASE 6: REPORT
-
-Write `.devlyn/BROWSER-RESULTS.md`:
-
-```markdown
-# Browser Validation Results
-
-## Verdict: [PASS / PASS WITH ISSUES / NEEDS WORK / PARTIALLY VERIFIED / BLOCKED]
-Verdict rules:
-- BLOCKED = server won't start or app doesn't render
-- NEEDS WORK = implemented features don't work in the browser
-- PARTIALLY VERIFIED = some features verified working, but others couldn't be tested due to environment limitations (missing API keys, external service dependencies). Be explicit about what was and wasn't verified.
-- PASS WITH ISSUES = all testable features work but visual issues or minor warnings exist
-- PASS = all testable features verified working, pages render, layout clean
-
-## What Was Tested
-[Brief description of the feature/task from done-criteria or git diff]
-
-## Feature Verification (primary)
-| Criterion | Test Steps | Result | Evidence |
-|-----------|-----------|--------|----------|
-| [what should work] | [what you did] | PASS/FAIL/SKIPPED/UNVERIFIABLE | [screenshot, errors, what went wrong] |
-
-## Unverifiable Features (if any)
-[List features that couldn't be tested and why — e.g., "Badge rendering requires /api/backends/status which needs real API keys not present in test env. Verified via source code and unit tests instead."]
-
-## Smoke Test (prerequisite)
-| Route | Renders | Console Errors | Network Failures |
-|-------|---------|---------------|-----------------|
-| / | YES/NO | [count] | [count] |
-
-## Visual Check
-| Viewport | Route | Issues |
-|----------|-------|--------|
-| Mobile (375px) | / | [issues or "Clean"] |
-| Desktop (1280px) | / | [issues or "Clean"] |
-
-## Fixes Applied During Validation
-[List any bugs found and fixed during testing — server startup issues, broken routes, feature bugs]
-
-## Runtime Errors
-[Console errors captured during testing]
-
-## Failed Network Requests
-[Failed API calls captured during testing]
-```
-
-## PHASE 7: CLEANUP
-
-Kill the dev server PID. If `--keep-server` was passed (auto-resolve pipeline), skip — the pipeline handles cleanup.
-
-</workflow>

package/config/skills/devlyn:browser-validate/references/flow-testing.md

@@ -1,118 +0,0 @@
-# Flow Testing: Done-Criteria to Browser Steps
-
-How to read `.devlyn/done-criteria.md` and convert testable criteria into browser action sequences. This is the bridge between "what should work" and "prove it works in the browser."
-
-Read this file only during PHASE 4 (FLOW) when done-criteria exists.
-
----
-
-## Step 1: Classify Each Criterion
-
-Read `.devlyn/done-criteria.md` and classify each criterion:
-
-**Browser-testable** — the criterion describes something a user can see or do in the UI:
-- "User can create a new project from the dashboard"
-- "Error message appears when form is submitted with empty fields"
-- "Navigation shows active state on current page"
-- "Data table loads and displays 10 rows"
-
-**Not browser-testable** — the criterion is about backend logic, data integrity, or code quality:
-- "API returns 401 for unauthenticated requests"
-- "Database migration runs without errors"
-- "Test coverage exceeds 80%"
-- "No TypeScript errors"
-
-Skip non-browser-testable criteria. Note them as "Skipped — not browser-testable" in the report.
-
-## Step 2: Convert to Action Sequences
-
-For each browser-testable criterion, generate a sequence of steps:
-
-### Pattern: Navigation + Verification
-```
-Criterion: "Dashboard shows project count"
-Steps:
-  1. Navigate to /dashboard
-  2. Find element containing project count (look for text matching a number pattern)
-  3. Verify: element exists and contains a numeric value
-  4. Screenshot
-```
-
-### Pattern: Form Interaction
-```
-Criterion: "User can create a new project"
-Steps:
-  1. Navigate to /dashboard (or wherever the create action lives)
-  2. Find "Create" or "New Project" button
-  3. Click it
-  4. Find form fields (name, description, etc.)
-  5. Fill with test data: name="Test Project", description="Browser validation test"
-  6. Find and click submit button
-  7. Verify: success indicator appears (toast, redirect, new item in list)
-  8. Screenshot at steps 3, 6, and 7
-```
-
-### Pattern: Error State
-```
-Criterion: "Error message shows when form submitted empty"
-Steps:
-  1. Navigate to the form page
-  2. Find submit button
-  3. Click submit without filling any fields
-  4. Verify: error message(s) visible
-  5. Screenshot showing error state
-```
-
-### Pattern: Conditional UI
-```
-Criterion: "Empty state shows when no data exists"
-Steps:
-  1. Navigate to the list/table page
-  2. Check if data exists — if so, this test needs a clean state
-  3. If clean state achievable: verify empty state message/illustration
-  4. If not: skip with note "Cannot verify empty state — data already exists"
-  5. Screenshot
-```
-
-## Step 3: Handle Data Dependencies
-
-Some flow tests need specific data to exist (or not exist). Approach:
-
-1. **Read-only tests preferred** — test flows that verify existing state rather than create/modify
-2. **Create test data if safe** — if the flow creates something (like a project), use obvious test names ("Browser Validation Test — safe to delete")
-3. **Skip if destructive** — don't test delete flows, don't modify existing data, don't test flows that send emails or notifications
-4. **Note dependencies** — if a test can't run because of missing data, note it as "Skipped — requires [specific data state]"
-
-## Step 4: Handle Auth-Protected Pages
-
-If a route requires authentication:
-1. Check if the app redirects to a login page
-2. If login is a simple form (email + password): note "Auth required — skipping unless test credentials available"
-3. If login uses OAuth/SSO: skip entirely, note "Skipped — requires OAuth flow"
-4. Do not attempt to log in with guessed credentials
-
-## Test Data Guidelines
-
-When filling forms during flow tests, use obviously fake but valid data:
-- Name: "Test User" or "Browser Validate Test"
-- Email: "test@browser-validate.local"
-- Description: "Created by browser-validate skill — safe to delete"
-- Numbers: use small, obvious values (1, 10, 100)
-
-This makes test data easy to identify and clean up later.
-
-## Output Format
-
-For each flow test, report:
-
-```
-Criterion: [original text from done-criteria]
-Classification: browser-testable | skipped
-Steps executed: [N of total]
-Result: PASS | FAIL | SKIPPED
-Evidence:
-  - Screenshot: [path]
-  - Console errors during flow: [count] — [details]
-  - Network failures during flow: [count] — [details]
-  - Failure point: [which step failed and why]
-```

package/config/skills/devlyn:browser-validate/references/tier1-chrome.md

@@ -1,137 +0,0 @@
-# Tier 1: Chrome DevTools (claude-in-chrome)
-
-The richest testing tier. Requires the claude-in-chrome MCP extension running in a Chrome browser. Provides full DOM interaction, console monitoring, network inspection, screenshots, and GIF recording.
-
-Read this file only when Tier 1 was selected during DETECT phase.
-
----
-
-## Setup
-
-Before any browser interaction, load the tools you need via ToolSearch:
-```
-ToolSearch: "select:mcp__claude-in-chrome__tabs_context_mcp"
-ToolSearch: "select:mcp__claude-in-chrome__tabs_create_mcp"
-ToolSearch: "select:mcp__claude-in-chrome__navigate"
-ToolSearch: "select:mcp__claude-in-chrome__get_page_text"
-ToolSearch: "select:mcp__claude-in-chrome__read_page"
-ToolSearch: "select:mcp__claude-in-chrome__find"
-ToolSearch: "select:mcp__claude-in-chrome__computer"
-ToolSearch: "select:mcp__claude-in-chrome__form_input"
-ToolSearch: "select:mcp__claude-in-chrome__resize_window"
-ToolSearch: "select:mcp__claude-in-chrome__read_console_messages"
-ToolSearch: "select:mcp__claude-in-chrome__read_network_requests"
-ToolSearch: "select:mcp__claude-in-chrome__gif_creator"
-ToolSearch: "select:mcp__claude-in-chrome__javascript_tool"
-```
-
-Then call `tabs_context_mcp` first to understand current browser state. Create a new tab for testing — never reuse existing user tabs.
-
-## Tool Mapping by Action
-
-### Navigate to a page
-```
-tabs_create_mcp → create new tab with URL http://localhost:{PORT}{route}
-  OR
-navigate → go to URL in existing tab
-```
-After navigating, wait 2-3 seconds for client-side rendering, then call `get_page_text` to verify content loaded.
-
-### Check if page rendered
-```
-get_page_text → extract visible text content
-```
-Read the text and judge: is this the actual application, or an error/fallback page? Browser error pages, framework error overlays, "Unable to connect" screens, and empty shells all have text — but they're not the app. If the page content doesn't look like what the application is supposed to show, it's a failure.
-
-### Read page structure
-```
-read_page → get DOM structure and layout info
-```
-Use this to understand component hierarchy before interacting.
-
-### Find interactive elements
-```
-find → locate buttons, links, inputs by text content or attributes
-```
-Returns element positions for clicking.
-
-### Click elements
-```
-computer → click at coordinates returned by find
-```
-After clicking, wait 1-2 seconds, then check console + network for errors.
-
-### Fill form fields
-```
-form_input → set values on input fields, selects, textareas
-```
-Identify fields with `find` first, then use `form_input` with the field selector.
-
-### Take screenshots
-```
-computer → screenshot action captures the visible viewport
-```
-Save screenshots into the topic-scoped directory that PHASE 1 set up (`.devlyn/screenshots/<topic-slug>/`), organized by phase:
-- Smoke: `<topic>/smoke/<route>.png` — e.g., `smoke/root.png`, `smoke/dashboard.png`
-- Feature: `<topic>/feature/<criterion>-step<N>.png` — e.g., `feature/create-project-step3.png`
-- Visual: `<topic>/visual/<viewport>-<route>.png` — e.g., `visual/mobile-dashboard.png`
-
-Since `computer → screenshot` writes to a default location, move/rename the captured file into the right subdirectory immediately after taking it, so evidence paths in the report match this scheme.
-
-### Resize viewport
-```
-resize_window → set width and height
-```
-Mobile: `resize_window(375, 812)`. Desktop: `resize_window(1280, 800)`.
-
-### Read console messages
-```
-read_console_messages → get all console output
-```
-Use `pattern` parameter to filter. Useful patterns:
-- `"error|Error|ERROR"` — catch errors
-- `"warn|Warning"` — catch warnings
-- Exclude known noise: React dev warnings (`"Warning: "` prefix), HMR messages (`"[vite]"`, `"[HMR]"`, `"[Fast Refresh]"`), favicon 404s
-
-### Read network requests
-```
-read_network_requests → get all HTTP requests with status codes
-```
-Flag: any request with status 4xx or 5xx (excluding `/favicon.ico`). Flag: any CORS error. Ignore: HMR websocket connections, source map requests (`.map`).
-
-### Record multi-step flows
-```
-gif_creator → record a sequence of actions as an animated GIF
-```
-Use for flow tests with 3+ steps. Capture extra frames before and after actions for smooth playback. Name meaningfully: `flow-user-registration.gif`.
-
-### Run custom assertions
-```
-javascript_tool → execute JS in the page context
-```
-Useful for checking specific DOM state that other tools can't easily verify:
-- `document.querySelectorAll('.error-message').length` — count error elements
-- `window.__NEXT_DATA__` — check Next.js hydration data
-- `document.title` — verify page title
-
-Avoid triggering alerts or confirms — they block the extension. Use `console.log` + `read_console_messages` instead.
-
-## Error Filtering
-
-Not every console message is a real problem. Apply these filters:
-
-**Ignore (dev noise)**:
-- `[HMR]`, `[vite]`, `[Fast Refresh]`, `[webpack-dev-server]`
-- `Warning: ReactDOM.render is no longer supported` (React 18 dev warning)
-- `Download the React DevTools`
-- `/favicon.ico` 404
-- Source map warnings
-
-**Flag as errors**:
-- `Uncaught` anything
-- `TypeError`, `ReferenceError`, `SyntaxError`
-- `Failed to fetch` (network errors)
-- `CORS` errors
-- `Hydration` mismatches
-- `ChunkLoadError` (code splitting failures)
-- Any `console.error` call from application code

package/config/skills/devlyn:browser-validate/references/tier2-playwright.md

@@ -1,195 +0,0 @@
-# Tier 2: Playwright (Headless Browser)
-
-Solid middle-ground tier. No browser extension needed — works in CI, SSH, Docker, and headless environments. Provides DOM interaction, console monitoring, screenshots, and network inspection. No GIF recording.
-
-Read this file only when Tier 2 was selected during DETECT phase.
-
----
-
-## Two Modes
-
-Playwright Tier 2 has two sub-modes depending on what's available. The skill auto-detects which to use.
-
-### Mode A: Playwright MCP (preferred)
-
-If `mcp__playwright__*` tools are available (installed via `npx devlyn-cli` → select "playwright" MCP), use them directly. This gives interactive browser control similar to Tier 1:
-
-- `mcp__playwright__browser_navigate` — navigate to URL
-- `mcp__playwright__browser_screenshot` — capture screenshot
-- `mcp__playwright__browser_click` — click elements
-- `mcp__playwright__browser_type` — type into inputs
-- `mcp__playwright__browser_console` — read console messages
-- `mcp__playwright__browser_network` — read network requests
-- `mcp__playwright__browser_resize` — resize viewport
-
-When Playwright MCP is available, follow the same interaction pattern as Tier 1 (navigate → check → interact → screenshot) but using `mcp__playwright__*` tools instead of `mcp__claude-in-chrome__*`.
-
-Load tools via ToolSearch before use: `ToolSearch: "select:mcp__playwright__browser_navigate"` etc.
-
-### Mode B: Script Generation (fallback)
-
-If Playwright MCP is not installed but `npx playwright` CLI is available, generate and execute test scripts. This is the approach documented below.
-
-## Setup (Mode B only)
-
-Playwright runs via `npx` with auto-download. No global install needed. If browsers aren't installed yet:
-```bash
-npx playwright install chromium 2>/dev/null
-```
-This downloads only Chromium (~130MB), not all browsers. It's a one-time cost.
-
-## Approach (Mode B)
-
-Generate a temporary test script from the test steps, run it with Playwright's JSON reporter, then parse the results. This avoids needing a persistent test infrastructure — the script is created, executed, and cleaned up.
-
-## Script Generation
-
-For each phase (smoke, flow, visual), generate a test script at `.devlyn/browser-test.spec.ts`.
-
-### Smoke Test Script Template
-
-```typescript
-import { test, expect } from '@playwright/test';
-
-const PORT = {PORT};
-const ROUTES = {ROUTES_JSON_ARRAY};
-
-test.describe('Smoke Tests', () => {
-  for (const route of ROUTES) {
-    test(`smoke: ${route}`, async ({ page }) => {
-      const errors: string[] = [];
-      const failedRequests: string[] = [];
-
-      page.on('console', msg => {
-        if (msg.type() === 'error') errors.push(msg.text());
-      });
-
-      page.on('response', response => {
-        if (response.status() >= 400 && !response.url().includes('favicon')) {
-          failedRequests.push(`${response.status()} ${response.url()}`);
-        }
-      });
-
-      // If goto throws (connection refused), the test fails — that's correct behavior
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle', timeout: 15000 });
-
-      // Verify this is the actual application, not an error page.
-      // When a server is down or a route is broken, the browser shows an error page
-      // that still has text content — "Unable to connect", "This site can't be reached", etc.
-      // A naive length check would pass on these. The title is the best signal:
-      // browser error pages have titles like "Problem loading page" or the URL itself,
-      // while real apps have meaningful titles set by the application.
-      const title = await page.title();
-      const bodyText = await page.textContent('body') || '';
-
-      // Page must have substantive content
-      expect(bodyText.trim().length, 'Page body is empty').toBeGreaterThan(0);
-
-      // Fail if the page navigation itself failed (Playwright sets title to the URL on error)
-      const pageUrl = page.url();
-      expect(title, 'Page shows a browser error — server may be down').not.toBe(pageUrl);
-
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/smoke/${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-      // SCREENSHOT_DIR is the topic-scoped dir set up in PHASE 1 of SKILL.md
-      // (e.g., .devlyn/screenshots/add-login-page). Inject it at test-generation
-      // time so every test writes into the same per-run folder.
-
-      if (errors.length > 0) {
-        test.info().annotations.push({ type: 'console_errors', description: errors.join(' | ') });
-      }
-      if (failedRequests.length > 0) {
-        test.info().annotations.push({ type: 'network_failures', description: failedRequests.join(' | ') });
-      }
-
-      expect(errors.filter(e => !e.includes('[HMR]') && !e.includes('favicon'))).toHaveLength(0);
-      expect(failedRequests).toHaveLength(0);
-    });
-  }
-});
-```
-
-### Flow Test Script Template
-
-For each flow test step from done-criteria, generate a test block:
-
-```typescript
-test('flow: [criterion description]', async ({ page }) => {
-  // Navigate
-  await page.goto(`http://localhost:${PORT}{start_route}`);
-
-  // Find and interact
-  await page.click('[text or selector]');
-  await page.fill('[selector]', '[value]');
-  await page.click('[submit selector]');
-
-  // Verify
-  await expect(page.locator('[verification selector]')).toBeVisible();
-
-  // Screenshot
-  await page.screenshot({ path: `${SCREENSHOT_DIR}/feature/[criterion-slug]-step[N].png` });
-});
-```
-
-### Visual Test Script Template
-
-```typescript
-test.describe('Visual - Mobile', () => {
-  test.use({ viewport: { width: 375, height: 812 } });
-  for (const route of ROUTES) {
-    test(`visual-mobile: ${route}`, async ({ page }) => {
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle' });
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/visual/mobile-${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-    });
-  }
-});
-
-test.describe('Visual - Desktop', () => {
-  test.use({ viewport: { width: 1280, height: 800 } });
-  for (const route of ROUTES) {
-    test(`visual-desktop: ${route}`, async ({ page }) => {
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle' });
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/visual/desktop-${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-    });
-  }
-});
-```
-
-## Execution
-
-```bash
-mkdir -p "$SCREENSHOT_DIR"/{smoke,feature,visual}
-npx playwright test .devlyn/browser-test.spec.ts \
-  --reporter=json \
-  --output=.devlyn/playwright-results \
-  2>&1 | tee .devlyn/playwright-output.json
-```
-
-## Parsing Results
-
-Read `.devlyn/playwright-output.json`. The JSON structure contains:
-- `suites[].specs[].tests[].results[].status` — `"passed"`, `"failed"`, `"timedOut"`
-- `suites[].specs[].tests[].results[].errors` — error messages with stack traces
-- `suites[].specs[].tests[].annotations` — custom annotations (console_errors, network_failures)
-
-Map these to BROWSER-RESULTS.md findings:
-- `failed` → route fails smoke, include error message
-- Annotations with `console_errors` → list in Runtime Errors section
-- Annotations with `network_failures` → list in Failed Network Requests section
-
-## Cleanup
-
-After parsing results:
-```bash
-rm -f .devlyn/browser-test.spec.ts
-rm -rf .devlyn/playwright-results
-rm -f .devlyn/playwright-output.json
-```
-
-Keep `$SCREENSHOT_DIR` (`.devlyn/screenshots/<topic-slug>/`) — those are evidence referenced by the report. Don't touch other topics' directories.
-
-## Limitations vs Tier 1
-
-- No GIF recording (can't capture multi-step flow animations)
-- No live DOM exploration (tests are scripted, not interactive)
-- Screenshots are full-page captures, not viewport-specific (use `fullPage: true`)
-- Console filtering is code-based (less flexible than chrome MCP pattern matching)

package/config/skills/devlyn:browser-validate/references/tier3-curl.md

@@ -1,57 +0,0 @@
-# Tier 3: HTTP Smoke (curl)
-
-Bare-minimum fallback. No browser, no JavaScript execution, no interaction testing. This tier confirms the dev server responds and pages return valid HTML. It catches "app doesn't start" and "page returns 500" but nothing subtler.
-
-Read this file only when Tier 3 was selected during DETECT phase.
-
----
-
-## What You Can Test
-
-- Server responds on the expected port
-- Pages return HTTP 200
-- HTML contains a `<body>` with content (not an empty shell)
-- No server-side error indicators in the HTML
-
-## What You Cannot Test
-
-- Client-side rendering (SPA content won't appear in curl output)
-- JavaScript errors or console output
-- Network requests made by the client
-- Interactive elements (forms, buttons, navigation)
-- Visual layout or responsive behavior
-- Screenshots
-
-## Smoke Test
-
-For each affected route:
-
-```bash
-# Check HTTP status
-STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:{PORT}{route} --max-time 10)
-
-# Get HTML content
-HTML=$(curl -s http://localhost:{PORT}{route} --max-time 10)
-```
-
-### Pass Criteria
-
-A route passes if:
-1. curl succeeds (doesn't error out with connection refused or timeout)
-2. `STATUS` is `200` (or `301`, `302`, `304`) — not `000`, not `5xx`
-3. HTML contains `<body` tag
-3. HTML body has more than 100 characters of text content (not just empty divs)
-4. HTML does not contain server error indicators: `Internal Server Error`, `500`, `ECONNREFUSED`, `Cannot GET`, `404`
-
-### Parsing HTML Content
-
-Since curl returns raw HTML (no JS execution), for SPAs the body may only contain a root `<div id="root"></div>` or `<div id="__next"></div>`. This is normal and counts as a PASS for Tier 3 — note it as "SPA shell detected, client-side rendering not verifiable at this tier."
-
-For SSR frameworks (Next.js with server components, Nuxt, Astro), the HTML should contain actual rendered content.
-
-## Report Adjustments
-
-When writing BROWSER-RESULTS.md from Tier 3:
-- Set confidence level to LOW
-- Leave Console Errors, Network Failures, Flow Tests, and Visual Check sections as "N/A — Tier 3 (HTTP only)"
-- Note the limitation: "Tier 3 testing provides HTTP-level validation only. Client-side behavior, JavaScript errors, and visual rendering were not tested. For comprehensive browser validation, install the claude-in-chrome extension (Tier 1) or Playwright (Tier 2)."