Edge-Case Test Suite

• implemented features that should be regression tested now
• planned features in PLAN.md that need acceptance coverage before shipping
• cross-cutting risks that apply to nearly every module

​

How to use this

• Treat each section as a source of candidate unit, integration, and browser tests.
• For implemented work, prioritize the cases marked by user-impact, data-loss risk, permission risk, or multi-tenant leakage risk.
• For planned work, use the cases to refine acceptance criteria before implementation.
• When a new feature lands, move its cases from the planned section into the implemented section and add automated coverage where practical.

​

Cross-cutting cases

• User belongs to the right organization but lacks the exact permission for the action.
• User has the permission but no access to the specific location or pool.
• User has manage permission but not the paired view permission.
• Archived users, testers, locations, or pools still appear in active pickers.
• Soft-deleted records still affect counts, filters, exports, charts, or status cards.
• A page links to a record the current user can no longer access.
• Browser submits the same action twice because of double-click, refresh, or back/forward replay.
• Server action partially succeeds, then follow-up work fails, leaving orphaned rows or files.
• A file upload is accepted by the browser but rejected by server-side validation.
• Empty state, loading state, and permission-denied state render the same generic UI.
• UTC timestamps vs. local facility dates cause records to fall on the wrong day.
• Daylight-saving transitions create duplicate or missing hour windows in filters or reports.
• Numeric 0, blank string, null, and undefined are treated differently across forms.
• Long notes, unusual punctuation, or pasted content break table layout or print views.
• Filters persist stale values from query params or client defaults after the underlying data changes.
• Mobile cards and desktop tables disagree on data, actions, or navigation affordances.
• Print views expose hidden controls, stale filters, or truncated content.
• Export/download endpoints return a success status with an empty or malformed file.
• Audit history misses actor identity, changed fields, or before/after values.
• A seeded/demo org has enough unusual data to expose edge cases without hand-editing production-like rows.

​

Implemented features

​

Authentication, session, shell, and navigation

• Login succeeds with valid credentials, fails with invalid credentials, and does not leak whether the email exists.
• User with no matching users row or no active org membership is blocked cleanly after Auth succeeds.
• Session refresh keeps protected pages working across long-lived browsing without redirect loops.
• Signing out from one tab invalidates protected actions in another tab.
• Deep-linking to a protected route redirects correctly and returns after login if intended.
• Sidebar, mobile tabs, and mobile “More” sheet all hide routes the user cannot access.
• Nav group headings stay correct when only one child route in a group is visible.
• Keyboard navigation still reaches row links and action buttons after the clickable-row changes.
• not-found and permission-denied flows do not imply the record exists when it should be hidden.
• Printing any authenticated route hides shell chrome and does not expose navigation-only content.