Files
familysync/.planning/phases/19-local-auth-no-oidc-mode/19-UAT.md
T

3.5 KiB

phase, created, updated, status, source, gaps
phase created updated status source gaps
19-local-auth-no-oidc-mode 2026-06-17T18:25:00Z 2026-06-17T18:25:00Z pending verification + plan-checkpoints

Phase 19: Local Auth (No-OIDC Mode) — User Acceptance Tests

All automated verification passed (API 446/446, PWA 266/266, e2e desktop 42 passed / 3 skipped, typecheck clean; VERIFICATION.md status: passed, 21/21 must-haves). The single blocker found during verification (admin reset-password URL mismatch) was fixed and confirmed live (commit 53da4be).

The items below are the remaining human / live-stack checks that cannot be driven from the dev DEV_AUTH_BYPASS harness or a headless box. They do not block automated goal achievement but should be confirmed before shipping.

UAT Items

1. Login page visual + flow (real, non-bypass stack)

  • Test: Run the stack with OIDC/Authelia configured and DEV_AUTH_BYPASS off. Visit the app unauthenticated → confirm redirect to /login. Verify the brand slot ("FS" mark, "FamilySync", "Family calendar & lists"), the form (username auto-focus, password show/hide), wrong-creds single error ("Incorrect username or password."), correct-creds navigation into the app, and the OIDC button only when oidcEnabled.
  • Expected: All surfaces per 19-UI-SPEC; no "Authelia" text anywhere; error copy never blames a specific field.
  • Why human: The unauth login-gate redirect is unreachable under the bypass-only harness (covered at unit level in App.test.tsx); the full visual flow needs a real browser against a non-bypass deployment. (Desktop/Chromium portions are already e2e- covered via login.spec.ts.)

2. Admin Reset-password sheet (live, end-to-end)

  • Test: As an admin, open Admin → Local Accounts → Reset password for a member; submit a new password; confirm the member can then log in with it.
  • Expected: POST /api/admin/members/:id/password returns 200; new password works.
  • Why human: Needs a live stack with an admin session and a real local member. (URL fix already verified: route reachable, 404 eliminated.)

3. Settings Change-password sheet (live, local user)

  • Test: As a local user, Settings → Account → Change password; verify wrong current password shows "Current password is incorrect.", correct current updates, and the new password works on next login.
  • Expected: Current-password verification enforced; update succeeds; re-login works.
  • Why human: Needs a live stack with a local-user session.

4. Rate-limit / lockout test flakiness (harden)

  • Test: Run apps/api/tests/routes/localAuth.test.ts Test 5 (10 failures → 423) ~10 times; characterize the intermittent failure the orchestrator observed (1 failure across 3 runs, then stable).
  • Expected: Stable pass; if timing-dependent, harden the in-memory rate-limit test (e.g. fake timers / deterministic clock).
  • Why human: Timing-dependent in-memory test; needs repeated runs to characterize.

5. CI harness green + D-15 image boundary (push, outward-facing)

  • Test: Push the branch and open the PR so Gitea CI runs. Confirm the harness job (iphone + pixel + desktop, incl. login.spec.ts) is green, the api job is green, and the published-image hygiene checks (no apps/api/scripts/ or apps/pwa/e2e/ in the prod image) pass.
  • Expected: CI all green; no dev artifact in the shipped image (D-14/D-15).
  • Why human: Pushing to the remote / triggering CI is an outward-facing action the operator owns. (Plan 19-05's blocking checkpoint.)