AUTH-MAIL-002 — Make account-email delivery states honest and recoverable

[daliu]

Officer impact: Members receive clear, accurate instructions when verification or password-recovery email is sent, delayed, or unavailable. Officers can point members to a safe recovery path without requesting passwords, codes, screenshots, or private links.

Officer documentation: Update docs/officers/EVENTS_SHOP_MEMBERS.md and docs/officers/EMERGENCY_AND_RECOVERY.md with the member-facing recovery wording, stop conditions, proof, undo, and escalation. Mark the revised behavior NOT AVAILABLE YET until the website publication is verified.

Deployment evidence: None at issue creation. Closure requires deterministic frontend tests, no-network provider mocks/emulators, merged source, website publication, runmprc.com verification, and a staged Auth-flow walkthrough using synthetic accounts. It does not require or authorize real email delivery from production.

Problem

Account registration currently catches a Firebase verification-email error, writes only a console warning, and can still tell the member to check the inbox. That makes account created and verification message sent look like the same successful state.

The resend path has no visible cooldown. Raw or inconsistent provider errors can confuse members, while detailed password-reset errors can reveal whether an account exists.

Atomic outcome

Represent identity and email-delivery outcomes separately and provide one simple recovery path:

• Account created.
• Verification message accepted for sending.
• Delivery request failed or is temporarily unavailable.
• Resend is available after a visible cooldown.
• Already verified, link expired/used, and wrong-account states have plain next steps.

The UI may suggest checking Spam and marking the approved sender as not spam, but must explain that this does not fix delivery for everyone.

Security and usability invariants

• Never claim a message was sent after the Firebase call failed.
• Password reset and public recovery responses remain generic and do not confirm whether an email/account exists.
• Do not display raw Firebase error codes, stack traces, email addresses, action links, or tokens.
• Do not log names, emails, request bodies, action links, or raw provider errors.
• Resend has a client-visible cooldown and must also tolerate provider throttling; it is not an authorization control.
• A retry cannot create another account, change membership, grant access, or lose the task the member was trying to complete.
• Controls and copy use large, clear actions and ordinary language suitable for elderly/nontechnical members.
• All tests use mocks/emulators and synthetic data; no production inbox or action link is used.

Acceptance criteria

• Registration distinguishes account created from verification request accepted and verification request failed.
• A failed verification request shows a generic recovery action and never says to check the inbox as if success were proven.
• Resend shows a visible countdown, blocks accidental repeat clicks, and recovers after success, failure, refresh, and sign-in changes.
• Password-reset UI returns the same public result for existing, missing, malformed, throttled, and provider-failure cases where enumeration resistance requires it.
• Verification success, already verified, expired/used link, wrong account, offline, and provider-unavailable states have one clear next action.
• Spam guidance names the currently configured sender generically and can be updated after AUTH-MAIL-001 without a code fork.
• Screen-reader labels, focus movement, keyboard flow, readable control sizes, and loading/disabled states are tested.
• Unit/integration tests prove success, send failure, resend cooldown, retry, navigation preservation, and generic-error behavior without any network call.
• No logs, analytics, screenshots, fixtures, or errors contain an email address, action URL, code, or token.
• Officer guidance states what can be checked, what must never be requested from a member, and when to escalate.

Dependencies and coordination

• CI-001A — Repair the deterministic frontend test baseline #103 owns the deterministic frontend test baseline.
• SAFETY-001 — Preserve callbacks and fail closed on local Firebase isolation #99 owns fail-closed local Firebase emulator isolation and navigation callback safety.
• OBS-001A — Remove personal data and session replay from current monitoring and logs #111 owns current monitoring/log redaction.
• AUTH-MAIL-001 — Brand and authenticate Firebase Authentication email #119 / AUTH-MAIL-001 owns sender-domain and Firebase/DNS configuration; this issue must not change DNS or implement a mail provider.
• AUTH-006 — Offer simple email/password and Google sign-in #109 owns the future combined email/password and Google entry screen. Keep this slice compatible, but do not widen AUTH-006 — Offer simple email/password and Google sign-in #109 or treat Google identity as membership.
• AUTH-004 — Link a Google identity to an existing Firebase member account #82 owns account-link/collision recovery.
• CI-001 — Establish trustworthy quality gates and protected deployment #105 owns staged and production website/deployment evidence.

The implementation becomes claimable after #103 and the required no-network test boundary are merged. Provider configuration may proceed separately under #119.

Explicitly out of scope

• Custom sender-domain DNS, SMTP/provider delivery, template administration, Google sign-in, membership approval, dues, discounts, or role grants.
• Reading a member mailbox, sending production test mail, or collecting message headers/action links in public systems.

Claim protocol

Creation is not a claim. Before editing, confirm dependencies, assign the issue, post CLAIMED by <canonical agent> at <UTC>; branch <branch>, and re-read all comments. Keep this as one tested UI/recovery outcome.

[daliu]

#145 / AUTH-MAIL-002A child update

The registration/email-request truth slice is source-complete and merged through PR #148 as 46557c7. Exact PR and post-merge CI passed, and two independent exact-diff reviews approved.

This completes the source behavior for the first two parent acceptance outcomes: account creation is distinct from verification-request acceptance/failure, and a failed request never falsely says to check Inbox. The member keeps the account and receives a safe stop/escalation path.

Production remains NOT LIVE. Protected release run 29247125844 failed closed before build/cloud access because required public App Check configuration is absent; Firebase and Pages were skipped, and runmprc.com still serves the prior asset. Keep this parent open.

Remaining atomic work:

• #120B: truthful My Account resend result plus visible cooldown/session-reset behavior. Publish and claim as a focused child before editing Account paths.
• #120C: generic password-reset and action-code recovery states. Publish and claim separately.
• AUTH-MAIL-001 — Brand and authenticate Firebase Authentication email #119: sender/provider configuration remains parallel owner work.

Do not advertise Resend as a verified recovery procedure until #118 backend/profile behavior, #120B source, staged behavior, and live publication are all proven.

[daliu]

AUTH-MAIL-002B is now published and claimed as #153 for the My Account resend request result, 60-second visible client cooldown, double-click guard, accessibility, and no-network tests. It explicitly treats provider resolution as request acceptance, not delivery; refresh may reset the usability cooldown and does not bypass provider throttling. #119 and AUTH-MAIL-002C remain separate.