--- phase: 19-local-auth-no-oidc-mode created: 2026-06-17T18:25:00Z updated: 2026-06-17T18:25:00Z status: pending source: verification + plan-checkpoints gaps: [] --- # 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.)