docs(tasks): add 2FA recovery code and rate limiting tasks for Jury

Two follow-ups from reviewing the auth work before a dev->master release.

2FA recovery codes are non-functional and live: enrollment generates 10
codes with Math.random(), never persists them, and the challenge screen's
backup-code branch rejects every code. Users who enable 2FA and lose their
authenticator are permanently locked out.

Sign-in rate limiting was added but never called — lib/rate-limiter.ts is
imported in auth/actions.ts and nothing invokes it. Same change left two
other unused imports and introduced a user-enumeration leak in password
reset.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: deocagunot

docs/tasks/Jury-FS/2FA-Recovery-Codes-Are-Non-Functional.md

@@ -0,0 +1,105 @@
+# 2FA Recovery Codes Are Non-Functional (Live Lockout Risk)
+
+## Summary
+
+When a user enables Two-Factor Authentication, the app generates 10 backup recovery codes and shows them in a modal telling the user to save them somewhere safe. Those codes are never stored anywhere, and the login screen's "Use Backup Recovery Code" path is a placeholder that rejects every code it is given.
+
+The result: **any user who enables 2FA and then loses their authenticator device is permanently locked out of their account**, holding a list of recovery codes that cannot work. This is live on production today.
+
+Priority: highest of the open auth items. Every new 2FA enrollment adds another user who can be locked out.
+
+## Background
+
+### Codes are generated but never persisted
+
+`app/home/account-settings/_components/AccountSettings2FA.tsx:118-124`, immediately after successful enrollment:
+
+```ts
+// Generate 10 random single-use backup recovery codes
+const generatedCodes = Array.from({ length: 10 }, () =>
+  Math.random().toString(36).substring(2, 6).toUpperCase() + "-" +
+  Math.random().toString(36).substring(2, 6).toUpperCase()
+);
+setRecoveryCodes(generatedCodes);
+setIsRecoveryOpen(true);
+```
+
+There is no database write. The codes exist only in React state and are gone when the modal closes. There is no table storing them and nothing to compare against later.
+
+Separately, `Math.random()` is not cryptographically secure and must not be used to generate authentication secrets.
+
+### Verification always fails
+
+`app/auth/2fa-challenge/_components/TwoFactorForm.tsx:56-60`:
+
+```ts
+if (isBackupMode) {
+  // Backup Recovery Code check placeholder / code verification
+  toast.error("Invalid recovery code. Please check your backup codes or try TOTP.");
+  setIsLoading(false);
+  return;
+}
+```
+
+The branch is reachable from the UI — `TwoFactorForm.tsx:119-125` renders a "Use Backup Recovery Code" toggle. So users can and will try it, and are told their correct code is invalid.
+
+### There is no self-service way out
+
+`AccountSettings2FA.tsx:138` (`handleDisable2FA`) calls `supabase.auth.mfa.unenroll()`, which requires an authenticated `aal2` session. A user who cannot pass the 2FA challenge cannot reach it. Recovery currently requires someone with database access removing the MFA factor by hand.
+
+### What is working
+
+The TOTP path itself is correct and should not be changed: `middleware.ts:128-137` implements the Supabase assurance-level check properly, and `TwoFactorForm.tsx:64` uses `challengeAndVerify` correctly.
+
+## Objectives
+
+- Stop presenting users with recovery codes that cannot work.
+- Give a user who has lost their authenticator a supported way to regain access.
+- Make sure no authentication secret is generated with `Math.random()`.
+- Change nothing about the working TOTP challenge flow.
+
+## Expected Behavior
+
+- A user who enrolls in 2FA either receives recovery codes that actually work, or is told clearly that recovery requires contacting an admin — never codes that silently do nothing.
+- Entering a valid recovery code at the 2FA challenge signs the user in and consumes that code, so it cannot be reused.
+- Entering an invalid or already-used recovery code is rejected.
+- Users already enrolled under the broken flow are not left stranded.
+
+## Acceptance Criteria
+
+- [ ] The "Use Backup Recovery Code" option either works end to end, or is removed from the UI along with the enrollment modal that hands out codes.
+- [ ] No path shows a user a recovery code that is not verifiable.
+- [ ] If codes are implemented: they are generated with a CSPRNG, stored hashed (never plaintext), verified server-side, and single-use.
+- [ ] If codes are implemented: reusing a consumed code fails.
+- [ ] A documented recovery path exists for users already enrolled before this fix.
+- [ ] The TOTP challenge flow still works — verified by enrolling and logging in with an authenticator app.
+- [ ] `Math.random()` is not used to generate any authentication value.
+
+## Solution Hint
+
+Treat these as advisory, not prescriptive.
+
+**Do the safe part first.** The fastest way to stop the harm is to remove the backup-code UI — the toggle in `TwoFactorForm.tsx:119-125` and the recovery-code modal in `AccountSettings2FA.tsx` — and replace it with a short line telling users that losing their device means contacting an admin. That is a small, low-risk change that ends the false promise immediately. Real recovery codes can follow as a second PR.
+
+**If implementing real recovery codes:** note that Supabase Auth has no built-in backup-code feature for MFA, so this has to be built. Confirm that against the current Supabase docs before starting. The rough shape:
+
+- A table (e.g. `mfa_recovery_codes`) holding `codev_id`, a **hash** of each code, `used_at`, `created_at`. RLS should deny all direct client access — only server code touches it.
+- Generate with `crypto.randomBytes` / `crypto.getRandomValues`, not `Math.random()`.
+- Show the plaintext codes exactly once at enrollment, then store only hashes.
+- Verification must happen in a server action, not in the client component. Compare the hash, check `used_at IS NULL`, mark it used, then elevate the session. Elevating without a TOTP code needs the service-role admin API — work out that step before committing to this approach, as it is the hard part.
+- Rate limit recovery attempts (see the sign-in rate limiting task — same helper should cover this).
+
+**For users already enrolled:** you will need a documented admin procedure to remove a factor for a locked-out user. Worth adding regardless of which option is chosen.
+
+## Reminders
+
+- This is live. Every day it stays, more users enroll and become lockout candidates.
+- Removing the misleading UI is a valid and useful first PR. Do not let the full implementation block the quick fix.
+- Do not touch `middleware.ts:128-137` or the `challengeAndVerify` call — that part is correct.
+- Never store recovery codes in plaintext, and never verify them client-side.
+
+## Instructions
+
+- Branch naming: `fix/2fa-recovery-codes/Jury`.
+- Split into two PRs if helpful: (1) remove the misleading UI, (2) implement real recovery codes.
+- PR should state which option was taken and, if codes were implemented, how a code is verified and consumed.

docs/tasks/Jury-FS/Sign-In-Rate-Limiting-Not-Wired-Up.md

@@ -0,0 +1,97 @@
+# Sign-In Rate Limiting Is Never Called (Plus Password Reset Cleanup)
+
+## Summary
+
+`lib/rate-limiter.ts` was added with working `checkRateLimit` / `recordRateLimitAttempt` / `resetRateLimit` functions, and imported into `app/auth/actions.ts` — but nothing ever calls them. Sign-in has no rate limiting. Two other files in the same change also import functions they never use.
+
+The password reset action in the same change fixed a real bug, but introduced a user-enumeration leak that should be closed at the same time.
+
+## Background
+
+### The rate limiter is dead code
+
+`app/auth/actions.ts:7`:
+
+```ts
+import { checkRateLimit, recordRateLimitAttempt, resetRateLimit } from "@/lib/rate-limiter";
+```
+
+That import is the only reference to the module anywhere in the app. The sign-in action never calls any of the three functions, so the 73 lines in `lib/rate-limiter.ts` have no effect. Sign-in accepts unlimited password attempts.
+
+Two more imports in the same change are also unused:
+
+- `app/home/account-settings/_components/AccountSettingsChangePassword.tsx:19` — imports `updatePassword`, never called
+- `app/home/account-settings/_components/AccountSettingsDialog.tsx:31` — imports `updateEmail`, never called
+
+Worth checking whether those two were meant to replace inline logic that is still in place.
+
+### The in-memory store will not survive production
+
+`lib/rate-limiter.ts` keeps state in a module-level `Map`. In a serverless deployment each instance has its own copy and it is wiped on cold start, so an attacker spreading attempts across instances is barely slowed. It also grows unbounded for unique keys within a window.
+
+This repo already has Redis wired up — `lib/server/redis.ts`, `lib/server/redis-cache.ts`, and `ioredis` in `package.json` — with a graceful-fallback pattern already established. That is the natural backing store.
+
+Minor: `checkRateLimit` declares a `windowMs` parameter it never uses, and `cleanupExpiredEntries()` scans the whole map on every call.
+
+### Password reset — one real fix, one regression
+
+`app/auth/password-reset/action.ts` correctly fixed a genuine bug: the redirect decision read `data.availability_status === "passed"` when the value actually lives on `application_status`. That fix is good and should stay.
+
+Two things to address:
+
+1. **User enumeration.** The action now throws `"No account found with this email address"`, which tells anyone probing the endpoint exactly which emails have accounts. Password reset should behave identically whether or not the address exists.
+2. **Origin fallback.** `const origin = headersList.get("origin") || process.env.NEXT_PUBLIC_APP_BASE_URL || "http://localhost:3000"` — if both the header and the env var are missing in production, reset links point at localhost. Better to fail loudly than to send broken links.
+
+Also confirm intent: non-passed users now redirect to `/applicant/waiting` instead of `/applicant/account-settings`. That may be deliberate, but it is a behavior change worth stating in the PR.
+
+## Objectives
+
+- Make sign-in rate limiting actually run.
+- Back it with a store that works across instances.
+- Remove or wire up the other unused imports.
+- Close the enumeration leak without losing the `application_status` fix.
+
+## Expected Behavior
+
+- Repeated failed sign-in attempts for the same identifier are blocked after a threshold, with a clear message telling the user when to try again.
+- A successful sign-in clears the counter for that identifier.
+- The limit holds regardless of which server instance handles the request.
+- Requesting a password reset returns the same response whether or not the email is registered.
+- No file imports a function it does not call.
+
+## Acceptance Criteria
+
+- [ ] `checkRateLimit` is called before the sign-in attempt, `recordRateLimitAttempt` on failure, and `resetRateLimit` on success.
+- [ ] A blocked user sees a message including how long until they can retry.
+- [ ] Rate limit state is shared across instances (Redis), with a sensible fallback if Redis is unavailable.
+- [ ] Verified by test: N failed sign-ins produce a block; waiting out the window restores access; a successful sign-in resets the counter.
+- [ ] `AccountSettingsChangePassword.tsx` and `AccountSettingsDialog.tsx` either use their imports or drop them.
+- [ ] Password reset returns an identical response for registered and unregistered emails.
+- [ ] The `application_status` fix is preserved.
+- [ ] The origin fallback no longer silently produces localhost URLs in production.
+
+## Solution Hint
+
+Treat these as advisory, not prescriptive.
+
+**Key the limit carefully.** Keying on email alone lets an attacker lock a known user out of their own account by burning attempts deliberately. Keying on IP alone is defeated by rotation and punishes shared networks. A common compromise is to track both and block on whichever trips first, with a more forgiving IP threshold.
+
+**Reuse the existing Redis setup** in `lib/server/redis.ts` rather than adding a new dependency. Follow the graceful-fallback pattern already used there — if Redis is down, sign-in should still work rather than failing closed and locking everyone out.
+
+**For enumeration**, keep the internal lookup (you still need `application_status` to pick the redirect) but return the same success response either way, and only skip the send when there is no account. Log the miss server-side rather than surfacing it.
+
+**For the origin fallback**, drop the `"http://localhost:3000"` default and throw if neither the header nor the env var is present — a loud failure in staging beats broken reset links in production.
+
+Rate limiting will also be needed for 2FA recovery-code attempts (see the recovery codes task). Build the helper so it can serve both.
+
+## Reminders
+
+- The unused imports are the whole reason this needs revisiting — the feature reads as shipped but does nothing. Verify by actually attempting repeated bad logins, not by reading the diff.
+- Keep the `availability_status` → `application_status` fix. It is correct.
+- Do not fail sign-in closed when Redis is unreachable.
+
+## Instructions
+
+- Branch naming: `fix/sign-in-rate-limiting/Jury`.
+- PR should include the chosen key strategy and thresholds, and the result of the manual lockout test.
+- Call out whether the `/applicant/waiting` redirect change was intentional.