--- 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.