ahmido
12fb5ebb30
Some checks failed
Main Confidence / confidence (push) Failing after 1m20s
## Summary - add the workspace-scoped findings hygiene report, overview signal, and supporting classification service for broken assignments and stale in-progress work - add Spec 225 artifacts and focused findings hygiene test coverage alongside the new Filament page and workspace overview wiring - align product roadmap and spec candidates around the layered canonical control catalog, CIS library, and readiness model - extend SpecKit constitution and templates with the XCUT-001 shared-pattern reuse guidance ## Notes - validation commands and implementation close-out notes are documented in `specs/225-assignment-hygiene/plan.md` and `specs/225-assignment-hygiene/quickstart.md` - this PR targets `dev` from `225-assignment-hygiene` Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #264
295 lines
8.8 KiB
Markdown
295 lines
8.8 KiB
Markdown
---
|
|
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. |