Hi Robert,

Before I start Module 1 implementation, I need clarity on the following edge cases. These are all scenarios where the frontend behavior depends entirely on what the backend returns, so I need your confirmed response shapes and error codes for each.

1. Social vs email account collision

• A user signs up via Google (say [email protected]), then later tries to login using email/password with the same [email protected] — does the backend return an error like "Account exists via Google, please use social login"? Or do we silently link the accounts? What exact error code/message should I expect?
• Reverse scenario: User registers with email/password, then tries Google OAuth with the same email — do we auto-link, block, or prompt the user to link accounts?
• User logs in with Google first, then tries Apple Sign-In but both providers have the same email — same question, what's the behavior?

2. Forgot password for social-only accounts

• If a user signed up only via Google/Apple (no password was ever set), and they hit "Forgot Password" with that email — does POST /api/auth/forgot-password return success silently (for security, to not reveal account type), return an error like "No password set for this account, use social login", or send an email saying "You signed up with Google"?
• I need to know so I can show the correct UI feedback.

3. Apple Sign-In — hidden email

• Apple allows users to hide their real email and use a relay address (e.g. [email protected]). How does the backend handle this? Is the relay email stored as the primary email? If the same user later tries Google login with their real email, are these treated as two separate accounts?
• Also, Apple only sends the user's name on the first authorization. If our POST /api/auth/social call fails that first time and the user retries, the name won't be included again. Does the backend handle a social login request with a missing name field gracefully?

4. Login error differentiation

I need distinct error codes for each of these scenarios so I can show the right inline message:

• Wrong password (account exists, password incorrect)
• Account not found (email not registered)
• Account locked/suspended/banned
• Account not verified (if email verification is required before first login)
• Too many login attempts (rate limited)
• Social-only account attempting email/password login

What are the exact error response shapes for each? Following the pattern { error: { code, message, fields? } } from our API contract?

5. Rate limiting & brute force

• After how many failed login attempts is the account temporarily locked? What's the cooldown duration?
• Is rate limiting per IP, per email, or per device?
• Does POST /api/auth/forgot-password have rate limiting? (to prevent spam abuse) If so, what's the limit and what error code do I get?
• When rate limited, does the response include a retry_after field so I can show a countdown?

6. Email case sensitivity & format

• Is email treated as case-insensitive? ([email protected] vs [email protected] — same account?)
• Any backend-side email normalization I should be aware of, or should frontend normalize before sending?

7. Token & session behavior at login

• What is the access_token expiry time and refresh_token expiry time?
• If a user logs in on Device A, then logs in on Device B — is Device A's session invalidated (single session) or do both remain active (multi-session)?
• If the refresh token itself is expired and the user opens the app, I'm assuming I redirect to login — is there a specific error code from POST /api/auth/refresh that confirms "refresh token expired" vs. "refresh token revoked"?

8. Register → login handoff

• After POST /api/auth/register succeeds, does the response include access_token + refresh_token directly (auto-login), or does the user need to go through login separately?
• If email verification is required, does register return a specific status like { status: 'verification_pending' } so I know to show a "Check your email" screen instead of navigating to Home?

9. Forgot password flow details

• After POST /api/auth/forgot-password, what's the exact success response? I'm planning to show "If an account exists, we've sent a reset link" — does the backend always return 200 regardless of whether the email exists? (standard security practice)
• How long is the reset token valid?
• Can the reset link be used more than once?
• After successful password reset via POST /api/auth/reset-password, does the response auto-login (return tokens) or redirect to login?

10. Social login — token validation failures

• If the Google/Apple idToken sent to POST /api/auth/social is expired or invalid, what error code do I get?
• If the provider is down or unreachable from the backend side, is there a distinct error so I can show "Google login temporarily unavailable" vs. "Invalid credentials"?

Please share your responses or let's set up a quick call to align. I want to finalize these before I start coding so I don't build placeholder logic that needs rework.

Thanks,
Hari