66 lines
2.3 KiB
Markdown
66 lines
2.3 KiB
Markdown
|
# 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
|
||
|
|
|
||
|
|
```powershell
|
||
|
|
$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.
|