clickthrough-test-engineer

name	clickthrough-test-engineer
description	MANUAL-ONLY; never auto-invoke. Execute a systematic interactive clickthrough of a RUNNING app — a route-by-route walkthrough plan covering navigation, forms (valid + invalid input), dialogs, permission-gated controls, empty/loading/error states, and destructive-action confirmations, then drive the UI through it, recording per-step observations with severity-rated defects and screenshot evidence at named checkpoints. One-session verification pass, not a permanent scripted suite. Use when asked to click through the app and report what's broken, smoke-check the UI before a demo/release, verify a deployed build interactively, or sanity-check changed routes after a merge. DRIVES a browser against a live app. Do NOT use to build permanent automated journeys (playwright-e2e-engineer), write reusable manual test-case documents (manual-test-case-creator), run keyboard/contrast/screen-reader passes (accessibility-test-harness), or define which screenshots releases require (screenshot-evidence-planner).
disable-model-invocation	true

Clickthrough Test Engineer

Purpose

Perform a disciplined interactive walkthrough of a running application and come back with evidence: what was clicked, what happened, what's broken and how badly, with screenshots at named checkpoints. The deliverable is a clickthrough report — coverage of the planned routes, per-step observations, severity-rated defects, and evidence — from ONE session against ONE build. This is systematic verification-by-driving, not a permanent test suite and not exploratory wandering.

Use When

• Use when: asked to "click through the app and see what's broken", smoke-check the UI before a demo or release, or verify a deployed build.
• Use when: a merge changed several routes and someone wants an interactive pass over the affected screens.
• Use when: manual cases don't exist yet and a structured pass must find the obvious breakage fast.
• Do NOT use when: the ask is a PERMANENT automated journey — playwright-e2e-engineer; a clickthrough is one session, not a suite.
• Do NOT use when: the ask is reusable step-by-step case documents for other testers — manual-test-case-creator (this skill may EXECUTE those cases, but writing them is that skill).
• Do NOT use when: the focus is keyboard/focus/contrast/screen-reader — accessibility-test-harness owns the a11y pass.
• Do NOT use when: deciding evidence/naming/masking policy — screenshot-evidence-planner defines it; this skill follows it.

Inputs to Inspect

1. The running target: URL/environment, build/commit identity (record it — a report against "some build" is worthless), and which account(s)/roles are safe to use.
2. Scope: all routes, or the routes affected by a change (diff/PR list); route inventory from the router config where available.
3. Personas/roles available and the permission expectations per route (authorization matrix if present).
4. Evidence rules in force (screenshot-evidence-planner output): naming, masking, storage; defaults in the reference if none exist.
5. Known issues/quarantines, so the report doesn't re-file them as new.

Workflow

1. Pin the target and build the walkthrough plan. Record environment + build id. Enumerate routes in scope; per route, list the interaction checklist items that apply (nav, forms, dialogs, permissions, states, destructive confirmations) from references/clickthrough-route-catalog.md. The plan is written BEFORE clicking so coverage is checkable afterward.
2. Establish session safety: test accounts only; no real-customer data entered; destructive actions exercised only on disposable fixtures (compose test-data-architect seeds where available) — otherwise verify the confirmation dialog appears and CANCEL.
3. Drive each route: navigate (direct URL and in-app nav), exercise each planned interaction — forms with valid AND invalid input, dialogs open/close/escape, permission-gated controls per persona, empty/loading/ error states where reachable.
4. Observe like an instrument: per step record expected vs observed; capture the browser console for errors on every route (silent console errors are findings); screenshot at plan-named checkpoints and at every defect, masked per the evidence rules.
5. Rate and file defects: severity (blocker/major/minor/cosmetic) + reproduction steps + evidence reference. A defect without repro steps and a screenshot is a rumor, not a finding.
6. Report coverage honestly: routes/interactions completed vs planned vs skipped (with why — auth wall, data unavailable, time). Unvisited ≠ passing.
7. Hand off: blockers → systematic-debugger/owner immediately; recurring passes worth automating → playwright-e2e-engineer candidates (with the journey named); evidence bundle → release closeout (ai-closeout-reporter).

Output Format

CLICKTHROUGH REPORT — <app> @ <env> / build <id> / <date>
Session: <persona(s)/roles used, viewport(s)>
Plan: <routes × interaction checklist — written before execution>
Results per route:
  <route> — <steps executed> — <pass | defects found> — console <clean|errors>
Defects:
  <id> — <severity> — <route/step> — expected vs observed — repro steps
       — evidence <screenshot ref>
Checkpoints captured: <named screenshots per evidence rules, masked>
Coverage: executed <n/n routes, n/n interactions> | skipped <what + why>
Automation candidates: <journeys worth a permanent Playwright spec + why>
Handoffs: <blockers → owner/systematic-debugger; evidence → closeout>

Validation Checklist

• Environment + build id recorded; test accounts only.
• Walkthrough plan existed BEFORE execution; coverage measured against it.
• Forms exercised with invalid input, not just valid.
• Permission-gated controls checked per persona in scope.
• Console checked on every route; errors filed as findings.
• Every defect has severity, repro steps, and evidence.
• Screenshots follow naming/masking rules; sensitive data masked.
• Skipped items listed with reasons — no silent coverage inflation.
• No permanent spec files written (that's Playwright's lane).

Safety Rules

• Never enter real customer data, real payment instruments, or production credentials during a clickthrough.
• Destructive actions on non-disposable data: verify the confirmation appears, then CANCEL — deletion is only completed on fixtures created for this session.
• If the target turns out to be production with live customers, downgrade to read-only navigation and flag writes for human-approval-boundary.

Gotchas

• Clicking only the happy path through forms finds nothing — invalid input, double-submit, and back-button-after-submit are where UIs break.
• A clean-looking page with console errors is not a pass; the console is part of the observation surface.
• Direct-URL navigation catches missing route guards that in-app nav hides — always try both.
• Session bleed between personas (testing admin then member in one browser profile) produces false permission results — separate profiles/contexts.
• Reporting "everything works" when three routes were skipped for missing data is coverage inflation — the skipped list is mandatory.

Stop Conditions

• The app won't run / can't authenticate / no safe test account → report the blocker; do not click through with real user credentials.
• Scope says "everything" but the route inventory is huge → propose a risk-ranked route subset for this session and get it confirmed.
• A blocker defect makes downstream routes untestable → file it, mark the affected coverage as blocked, and continue elsewhere rather than forcing.
• The target is production and the plan includes writes → stop for human-approval-boundary before any mutating step.

Supporting Files

• references/clickthrough-route-catalog.md — the per-route interaction checklist (nav, forms, dialogs, permissions, states, destructive), viewport set, and default evidence conventions.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the UI/manual cluster and against playwright-e2e-engineer.