Playwright Auth/Session Audit

flow-runner verifies that logging in works. This checks what happens around that — session expiring mid-task, two sessions existing at once, logout not fully propagating, a "remember me" checkbox that doesn't actually do what it says.

Relationship to the other skills

Reuse scenario-mapper's Auth flow-type entries to know where the login/session surfaces are, rather than rediscovering them. This is a lifecycle check layered on top of what flow-runner already verified once — it doesn't replace that happy-path verification, it tests the edges around it.

Core principles (and why)

Use separate browser contexts for "different devices," multiple pages in one context for "different tabs." These are genuinely different scenarios with different expected behavior. A real second device has its own independent cookie jar — simulate that with a separate Playwright browser context. A second tab of the same browser shares cookies and storage with the first — simulate that with two pages inside one context. Testing "does logout in one tab affect another" using two separate contexts wouldn't actually be testing what it looks like it's testing.

Manipulate session state directly rather than waiting out a real timeout. A 30-minute or 24-hour expiry isn't practical to sit through. Clear or overwrite the session cookie/token directly via the browser context's cookie APIs, then take the next action and observe — this gets the same test in seconds. Be explicit in the report about what was actually simulated this way versus what would need a genuinely longer-running test to confirm (the exact stated duration itself, for instance, isn't verified just because expiry-handling behavior was).

There's no single correct answer for concurrent sessions — verify the behavior is intentional and consistent, not that it matches an assumption. Some apps deliberately allow simultaneous sessions from multiple devices; others intentionally invalidate the older one on a new login. Neither is inherently wrong. What matters is whether the actual behavior is clear and consistent rather than undefined or confusing — flag it for the team to confirm it matches their intended policy rather than grading it against an assumed "correct" answer.

A logged-out state should never be reachable via the back button. After logout, pressing back shouldn't reveal cached authenticated content. No special technique needed here — log out, click back, look at what's shown.

Scope any lockout/rate-limit check narrowly, and only if a policy is actually documented. If the app states an account-lockout or rate-limiting policy, verify it activates as described, using only your own test account, and stop the moment the stated threshold triggers. Never probe for an undocumented limit by trial and error — that stops being verification of a stated control and starts being something else, which isn't this skill's job.