user-system/docs/evidence/ops/2026-03-27/e2e/EMAIL_ACTIVATION_CLOSURE_20260327-171211.md

PRD 1.1 Email Activation Closure Evidence

Date: 2026-03-27 Scope: self-service email registration -> activation email delivery -> activation page -> successful login

Closure Summary

• Added a real public frontend activation route: /activate-account.
• Activation emails now point to the frontend activation page instead of the raw backend API endpoint.
• Added public resend-activation entry points from:
  • /activate-account
  • /login
  • /register success state for inactive email accounts
• Fixed a real frontend regression uncovered during closure:
  • the activation page could consume one-time activation tokens twice under React StrictMode development execution and remain stuck on loading.
  • the page now guards against duplicate activation requests while still allowing the successful request to commit UI state.

Validation Executed

$env:GOCACHE='D:\project\.gocache'
$env:GOMODCACHE='D:\project\.gomodcache'
go test ./... -count=1
go build ./cmd/server

cd D:\project\frontend\admin
npm.cmd run lint
npm.cmd run test:run
npm.cmd run build
powershell -ExecutionPolicy Bypass -File .\scripts\run-playwright-auth-e2e.ps1

Supported Browser E2E Result

The updated run-playwright-auth-e2e.ps1 starts:

• isolated backend
• isolated frontend
• isolated SQLite database
• isolated local SMTP capture service
• isolated CDP browser session

The real browser suite passed the following scenarios:

• public-registration
• email-activation
• login-surface
• auth-workflow
• responsive-login
• desktop-mobile-navigation

The new email-activation scenario verified:

1. create a self-service account with email
2. receive a real SMTP-delivered activation email through the local SMTP capture service
3. extract the activation link generated by the backend
4. open the frontend activation page in the real browser
5. complete backend activation successfully
6. return to login and sign in with the newly activated account

Real Boundary

• This closes the product loop and supported-browser validation loop.
• It does not prove live external SMTP provider deliverability or third-party mailbox delivery behavior.
• External production evidence for real SMTP providers remains a separate environment-governance topic and should not be conflated with this closure.