Admin portal visible defects

• Status: #882 was already fixed on dev before this project started (verified, not re-fixed); #881 fixed on feat/admin-and-merchant-portals, awaiting merge + deploy. Updated 2026-08-24.
• Issue: #882: bug(admin): false 'Set Up Separate Admin Password' banner for every admin once the #875 credential migration runs
• Launch plan: none found. Neither #882 nor #881 appears in ALPHA.md, though both are visible in a demo.
• Test plan: docs/engineering/testing/runs/admin-portal-visible-defects/README.md

What is this?

Two defects an admin sees with their own eyes in the portal.

• The false banner. Every admin gets a "Set Up Separate Admin Password" prompt once the credential migration runs, including admins who already have one.
• The always-zero counts. Dashboard profile-completion counts are structurally zero, because the plaintext fields the count reads were encrypted away and nothing repointed the query.

What is the current state?

#882 was already fixed, ahead of this project.

• AdminMigrationBanner.jsx already reads hasAdminPassword from GET /auth/admin/status (checkAdminPasswordStatus), not from a client Firestore read of adminProfiles.adminPasswordHash. That fix shipped in the #875 follow-up commit (4c6204a8, merged via #876 on 2026-08-16), before this session or this branch existed.
• Confirmed two ways this session: read the source, and confirmed the deployed admin.dev.ourlantern.app JS bundle contains zero occurrences of adminPasswordHash and does contain the admin/status call. See the test plan, scenario 3.
• Not yet confirmed live in a browser (no banner rendered for a real signed-in admin): blocked on missing local test credentials, see "What's still open" below.

#881 is fixed on this branch, not yet deployed.

• services/api/auth/src/routes/adminUsers.js's /stats handler now counts a profile complete off encryptedInterests/encryptedMood (what profileService.js actually writes) instead of the plaintext interests/mood fields it deletes on every save.
• Verified three ways, all local, none deployed: the Firestore emulator (new test in adminUsersRead.integration.test.js, 21/21 passing), a hand-count against real lantern-app-dev data, and (strongest) the actual unmodified adminUsers.js route mounted on a local Express app and hit against real dev Firestore. Old logic finds 1 complete profile among 22 role=user docs, new logic finds 2, confirming the fix recovers a real user the old logic missed. See the test plan, scenarios 1-3.
• Committed as 312b2694 on feat/admin-and-merchant-portals, pushed.

What else is related?

• #881: bug(admin): dashboard profile-completion counts are structurally always zero (plaintext fields were encrypted away)
• #875: security: sensitive fields colocated with readable data, so admin clients pull credentials and sealed-identity material into the browser, the work whose migration triggers the banner.

Sequencing that binds this project: #882 lands BEFORE the migration runs.

• migrate-credentials.mjs must not be run with --apply against any environment until the banner fix is in, or every admin sees the false prompt. Since #882's fix is confirmed already live on dev, this constraint is satisfied, but the migration itself is still out of scope for this project and was not run.

What's still open?

A real browser click-through is blocked on missing local credentials, not on the code.

• ~/.lantern-agent-probe.env and ~/.lantern-test-accounts.env (the admin login + App Check debug token the browser-test skill calls for) do not exist on this VM/session. A plain curl against the live /auth/admin/status endpoint with no App Check token confirms the block (APP_CHECK_REQUIRED).
• This affects both remaining scenarios in the test plan: #882's banner-absent render, and #881's dashboard-shows-nonzero-count render (the second also needs #881 deployed first).

#881's dashboard check is the standing post-deploy item.

• Once this session's PR merges and the auth-api Cloud Run service redeploys, re-run the dashboard check against deployed dev and record it in the test plan's scenario 5.