# Authenticated responsive app QA

Use this playbook when a responsive change affects both a public/login surface and an authenticated application shell.

## Viewport matrix

Test both surfaces at representative widths, not only one phone and one desktop:

- 320px — worst-case narrow phone
- 375px — common phone
- 768px — tablet / breakpoint boundary
- 1024px — compact desktop
- 1440px — wide desktop

For every viewport, collect:

- full-page screenshot;
- `document.documentElement.scrollWidth` vs viewport width;
- elements whose bounding boxes escape the viewport;
- browser console errors;
- failed network requests;
- serious/critical accessibility violations;
- interactive controls with effective targets below 44×44px.

A native checkbox may have a small input box while its wrapping `<label>` provides a large target. Inspect the effective labeled hit area before treating it as a failure.

## Authenticated state

Do not infer the app shell from the login page. Create or obtain a short-lived test session through the application's own server-side auth API, inject only that cookie into an isolated browser context, and never print the token. Verify login and app independently.

## Interaction probes

For mobile drawers:

1. Open through the visible toggle.
2. Confirm focus moves into the drawer.
3. Confirm `aria-expanded`, backdrop, and body scroll lock.
4. Verify forward and reverse Tab wrapping.
5. Close through the close button, backdrop, and Escape.
6. Confirm focus returns to the opener.
7. Resize across the desktop breakpoint while open; stale drawer classes, backdrop, and body lock must clear.

For cards and dialogs:

- avoid nested buttons or `role=button` containers containing buttons;
- give the primary open action a real `<button>`;
- verify keyboard opening and dialog close behavior;
- preserve a 44px effective target without making an entire card ambiguously clickable.

For live filtering:

- debounce rapid input;
- assign a monotonically increasing request sequence or abort prior requests;
- ignore stale responses so a slow old query cannot overwrite the latest result set.

## Production verification

After writes, confirm deployed files remain readable by the runtime account. Editor/write tools may replace a file and reset its group or mode even when the content is correct.

Run verification from an explicit working directory and use fail-fast execution (`set -e` or equivalent). A shell sequence that continues after an early path or permission error can print a misleading success marker.

Final gate:

- source tests and syntax/format checks pass;
- public assets match source content;
- login and authenticated app matrix pass;
- service is active;
- logs after the final deployment timestamp contain no new exceptions or 5xx errors.