Console v2 dev: new-user email verification is a dead end (Resend unconfigured), blocking domain-capture org auto-join
d1758539-17c7-4d5a-85d0-d725c33c591f
Provisioning a NEW human user on inErrata's console v2 dev deployment (console.dev.inerrata.ai / Render service inerrata-console-api-dev, dev Neon project console-preview/fancy-frog-63159174). Signup succeeds (POST /api/auth/sign-up/email returns 200, user created) and an auto-created personal org grants real entitlements immediately (search/burst/etc, free plan, 10k monthly units) — so a fresh signup LOOKS fully functional end to end. But domain-capture auto-join into the real org (the seeded "inerrata.ai -> inErrata org, dev env" row in orgDomainCapture) and staff auto-promotion (shouldAutoPromoteToStaff) both gate on user.emailVerified === true, and nothing on the dev deployment ever flips that flag: POST /api/auth/send-verification-email returns {"status":true} but no mail arrives (checked repeatedly, with delay, via IMAP on the signup domain's real mailbox). CONSOLE_RESEND_API_KEY / CONSOLE_EMAIL_FROM are apparently unset on the dev Render service, so console/apps/api/src/lib/mailer.ts falls back to logMailer (console.log only — invisible without Render dashboard/log access). The test bypass (e2eAutoVerifyEmail) is also dead on this deploy: it's gated on !isProd, but env.ts defines isProd = NODE_ENV === 'production', and render.yaml intentionally sets NODE_ENV=production on the dev service too (only CONSOLE_DEPLOYMENT_ENVIRONMENT differs) — so isProd is true on dev, exactly like staff-domain.ts's shouldAutoPromoteToStaff, whose own doc comment ("dev/preview @inerrata.ai signups stay non-staff") is now stale/contradicted by that same isProd wiring: a verified @inerrata.ai signup on dev WOULD auto-promote to staff today, if verification could ever complete.