---
name: browsertest
description: Führe einen vollständigen Smoke-Browser-Test im Integrated Browser für das aktuelle Feature aus, inklusive Happy Path, zentraler Regressionen, Kontext-Prüfung und belastbarer Ergebniszusammenfassung.
license: MIT
metadata:
  author: GitHub Copilot
---

# Browser Smoke Test

## What This Skill Does

Use this skill to validate the current feature end-to-end in the integrated browser.

This is a focused smoke test, not a full exploratory test session. The goal is to prove that the primary operator flow:

- loads in the correct auth, workspace, and tenant context
- exposes the expected controls and decision points
- completes the main happy path without blocking issues
- lands in the expected end state or canonical drilldown
- does not show obvious regressions such as broken navigation, missing data, or conflicting actions

The skill should produce a concrete pass or fail result with actionable evidence.

## When To Apply

Activate this skill when:

- the user asks to smoke test the current feature in the browser
- a new Filament page, dashboard signal, report, wizard, or detail flow was just added
- a UI regression fix needs confirmation in a real browser context
- the primary question is whether the feature works from an operator perspective
- you need a quick integration-level check without writing a full browser test suite first

## What Success Looks Like

A successful smoke test confirms all of the following:

- the target route opens successfully
- the visible context is correct
- the main flow is usable
- the expected result appears after interaction
- the route or drilldown destination is correct
- the surface does not obviously violate its intended interaction model

If the test cannot be completed, the output must clearly state whether the blocker is:

- authentication
- missing data or fixture state
- routing
- UI interaction failure
- server error
- an unclear expected behavior contract

Do not guess. If the route or state is blocked, report the blocker explicitly.

## Preconditions

Before running the browser smoke test, make sure you know:

- the canonical route or entry point for the feature
- the primary operator action or happy path
- the expected success state
- whether the feature depends on a specific tenant, workspace, or seeded record

When available, use the feature spec, quickstart, tasks, or current browser page as the source of truth.

## Standard Workflow

### 1. Define the smoke-test scope

Identify:

- the route to open
- the primary action to perform
- the expected end state
- one or two critical regressions that must not break

The smoke test should stay narrow. Prefer one complete happy path plus one critical boundary over broad exploratory clicking.

### 2. Establish the browser state

- Reuse the current browser page if it already matches the target feature.
- Otherwise open the canonical route.
- Confirm the current auth and scope context before interacting.

For this repo, that usually means checking whether the page is on:

- `/admin/...` for workspace-context surfaces
- `/admin/t/{tenant}/...` for tenant-context surfaces

### 3. Inspect before acting

- Use `read_page` before interacting so you understand the live controls, refs, headings, and route context.
- Prefer `read_page` over screenshots for actual interaction planning.
- Use screenshots only for visual evidence or when the user asks for them.

### 4. Execute the primary happy path

Run the smallest meaningful flow that proves the feature works.

Typical steps include:

- open the page
- verify heading or key summary text
- click the primary CTA or row
- fill the minimum required form fields
- confirm modal or dialog text when relevant
- submit or navigate
- verify the expected destination or changed state

After each meaningful action, re-read the page so the next step is based on current DOM state.

### 5. Validate the outcome

Check the exact result that matters for the feature.

Examples:

- a new row appears
- a status changes
- a success message appears
- a report filter changes the result set
- a row click lands on the canonical detail page
- a dashboard signal links to the correct report page

### 6. Check for obvious regressions

Even in a smoke test, verify a few core non-negotiables:

- the page is not blank or half-rendered
- the main action is present and usable
- the visible context is correct
- the drilldown destination is canonical
- no obviously duplicated primary actions exist
- no stuck modal, spinner, or blocked interaction remains onscreen

### 7. Capture evidence and summarize clearly

Your result should state:

- route tested
- context used
- steps executed
- pass or fail
- exact blocker or discrepancy if failed

Include a screenshot only when it adds value.

## Tool Usage Guidance

Use the browser tools in this order by default:

1. `read_page`
2. `click_element`
3. `type_in_page`
4. `handle_dialog` when needed
5. `navigate_page` or `open_browser_page` only when route changes are required
6. `run_playwright_code` only if the normal browser tools are insufficient
7. `screenshot_page` for evidence, not for primary navigation logic

## Repo-Specific Guidance For TenantPilot

### Workspace surfaces

For `/admin` pages and similar workspace-context surfaces:

- verify the page is reachable without forcing tenant-route assumptions
- confirm any summary signal or CTA lands on the canonical destination
- verify calm-state versus attention-state behavior when the feature defines both

### Tenant surfaces

For `/admin/t/{tenant}/...` pages:

- verify the tenant context is explicit and correct
- verify drilldowns stay in the intended tenant scope
- treat cross-tenant leakage or silent scope changes as failures

### Filament list or report surfaces

For Filament tables, reports, or registry-style pages:

- verify the heading and table shell render
- verify fixed filters or summary controls exist when the spec requires them
- verify row click or the primary inspect affordance behaves as designed
- verify empty-state messaging is specific rather than generic when the feature defines custom behavior

### Filament detail pages

For detail or view surfaces:

- verify the canonical record loads
- verify expected sections or summary content are present
- verify critical actions or drillbacks are usable

## Result Format

Use a compact result format like this:

```text
Browser smoke result: PASS
Route: /admin/findings/hygiene
Context: workspace member with visible hygiene issues
Steps: opened report -> verified filters -> clicked finding row -> landed on canonical finding detail
Verified: report rendered, primary interaction worked, drilldown route was correct
```

If the test fails:

```text
Browser smoke result: FAIL
Route: /admin/findings/hygiene
Context: authenticated workspace member
Failed step: clicking the summary CTA
Expected: navigate to /admin/findings/hygiene
Actual: remained on /admin with no route change
Blocker: CTA appears rendered but is not interactive
```

## Examples

### Example 1: Smoke test a new report page

Use this when the feature adds a new read-only report.

Steps:

- open the canonical report route
- verify the page heading and main controls
- confirm the table or defined empty state is visible
- click one row or primary inspect affordance
- verify navigation lands on the canonical detail route

Pass criteria:

- report loads
- intended controls exist
- primary inspect path works

### Example 2: Smoke test a dashboard signal

Use this when the feature adds a summary signal on `/admin`.

Steps:

- open `/admin`
- find the signal
- verify the visible count or summary text
- click the CTA
- confirm navigation lands on the canonical downstream surface

Pass criteria:

- signal is visible in the correct state
- CTA text is present
- CTA opens the correct route

### Example 3: Smoke test a tenant detail follow-up

Use this when a workspace-level surface should drill into a tenant-level detail page.

Steps:

- open the workspace-level surface
- trigger the drilldown
- verify the target route includes the correct tenant and record
- confirm the target page actually loads the expected detail content

Pass criteria:

- drilldown route is canonical
- tenant context is correct
- destination content matches the selected record

## Common Pitfalls

- Clicking before reading the page state and refs
- Treating a blocked auth session as a feature failure
- Confusing workspace-context routes with tenant-context routes
- Reporting visual impressions without validating the actual interaction result
- Forgetting to re-read the page after a modal opens or a route changes
- Claiming success without verifying the final destination or changed state

## Non-Goals

This skill does not replace:

- full exploratory QA
- formal Pest browser coverage
- accessibility review
- visual regression approval
- backend correctness tests

It is a fast, real-browser confidence pass for the current feature.