spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

[E2E P3] Registration & verification flow (email code + Twilio SMS hook) #318

New Issue
Open
opened 2026-07-01 21:17:31 +00:00 by spikerj · 4 comments
spikerj commented 2026-07-01 21:17:31 +00:00
Owner
Copy Link
Copy Source

Phase P3 of epic #307.

Blocker to land first — the SMS verification test hook (backend): the pre-registration flow verifies phone via Twilio Verify, and the code is never stored locally. Options (pick one; env is live-is-test so the safety gate is deferred but the hook must still be flag-gated):

  1. Thread the existing SendVerificationCodeCommand.CustomCode through pre-registration behind a flag (e.g. PreRegistration:E2E:Enabled + fixed E2E_SMS_CODE). Recommended.
  2. E2E-profile fake ITwilioVerifyService accepting a fixed code.
  3. Test-only endpoint to mark PhoneVerified for a pre-registration id.

Email verification is automatable today: read emailVerificationCode/emailVerificationToken from Mongo PreRegistrations by unique test email (or hit the GET verify link).

Tasks:

  • Land the SMS hook (backend)
  • Playwright: full 4-step registration-stepper happy path (basic info → SMS consent → password/terms → verification codes → complete)
  • Validation/error paths (username/email taken, under-18, bad codes, resend)
  • Reusable "fresh verified user" fixture (creates + completes a disposable account; storage-state login)
  • Test-data hygiene: unique emails (e2e+<ts>@…), cleanup or GDPR-delete after runs
Phase P3 of epic #307. **Blocker to land first — the SMS verification test hook** (backend): the pre-registration flow verifies phone via Twilio Verify, and the code is never stored locally. Options (pick one; env is live-is-test so the safety gate is deferred but the hook must still be flag-gated): 1. Thread the existing `SendVerificationCodeCommand.CustomCode` through pre-registration behind a flag (e.g. `PreRegistration:E2E:Enabled` + fixed `E2E_SMS_CODE`). **Recommended.** 2. E2E-profile fake `ITwilioVerifyService` accepting a fixed code. 3. Test-only endpoint to mark `PhoneVerified` for a pre-registration id. **Email verification is automatable today**: read `emailVerificationCode`/`emailVerificationToken` from Mongo `PreRegistrations` by unique test email (or hit the GET verify link). Tasks: - [ ] Land the SMS hook (backend) - [ ] Playwright: full 4-step registration-stepper happy path (basic info → SMS consent → password/terms → verification codes → complete) - [ ] Validation/error paths (username/email taken, under-18, bad codes, resend) - [ ] Reusable "fresh verified user" fixture (creates + completes a disposable account; storage-state login) - [ ] Test-data hygiene: unique emails (`e2e+<ts>@…`), cleanup or GDPR-delete after runs
spikerj added the enhancement label 2026-07-01 21:17:31 +00:00
spikerj commented 2026-07-03 23:48:30 +00:00
Author
Owner
Copy Link
Copy Source

SMS hook implemented — spikersoft-backend PR #60 (option 1)

customCode threaded through ITwilioVerifyService → RemoteTwilioVerifyService → the existing SendVerificationCodeCommand.CustomCode → Twilio Verify custom-code feature. All three pre-registration send sites wired (initiate / verify-email / resend); the phone-check path is untouched (still a real Twilio round-trip).

Guardrails beyond the ticket sketch: in addition to PreRegistration:E2E:Enabled + a 4–10-digit SmsCode, the fixed code applies only to emails matching PreRegistration:E2E:EmailPattern (default e2e+*@spikersoft.com) — so while armed on the live env, real registrants still get generated codes. Armed sends log at Warning for Seq visibility. Guardrail test matrix included; full unit suite green.

To activate after merge (ops):

  1. Enable the custom-code feature on the Twilio Verify service (Twilio console/support) if not already on.
  2. Set PreRegistration__E2E__Enabled=true + PreRegistration__E2E__SmsCode=<secret> env vars on the API deployment (and the same secret as E2E_SMS_CODE for the Playwright suite).

Next on this ticket once merged+armed: the Playwright registration-stepper happy path, validation/error paths, and the reusable "fresh verified user" fixture (which also unblocks P4 without a manually seeded account).

### SMS hook implemented — spikersoft-backend PR #60 (option 1) `customCode` threaded through `ITwilioVerifyService` → `RemoteTwilioVerifyService` → the existing `SendVerificationCodeCommand.CustomCode` → Twilio Verify custom-code feature. All three pre-registration send sites wired (initiate / verify-email / resend); the phone-check path is untouched (still a real Twilio round-trip). Guardrails beyond the ticket sketch: in addition to `PreRegistration:E2E:Enabled` + a 4–10-digit `SmsCode`, the fixed code applies **only to emails matching `PreRegistration:E2E:EmailPattern`** (default `e2e+*@spikersoft.com`) — so while armed on the live env, real registrants still get generated codes. Armed sends log at Warning for Seq visibility. Guardrail test matrix included; full unit suite green. **To activate after merge** (ops): 1. Enable the custom-code feature on the Twilio Verify service (Twilio console/support) if not already on. 2. Set `PreRegistration__E2E__Enabled=true` + `PreRegistration__E2E__SmsCode=<secret>` env vars on the API deployment (and the same secret as `E2E_SMS_CODE` for the Playwright suite). Next on this ticket once merged+armed: the Playwright registration-stepper happy path, validation/error paths, and the reusable "fresh verified user" fixture (which also unblocks P4 without a manually seeded account).
spikerj commented 2026-07-04 00:12:22 +00:00
Author
Owner
Copy Link
Copy Source

✅ SMS hook merged (spikersoft-backend PR #60) — first checkbox done; merging deploys it, so the hook exists on the API but stays inert until armed (PreRegistration__E2E__Enabled=true + PreRegistration__E2E__SmsCode=<secret> env vars, plus the Twilio Verify custom-code feature check).

Ticket stays open for the Playwright side: registration-stepper happy path, validation/error paths, fresh-verified-user fixture, and test-data hygiene. Starting with the paths that don't need the hook armed (client-side validation, no backend mutations).

✅ SMS hook merged (spikersoft-backend PR #60) — first checkbox done; merging deploys it, so the hook exists on the API but stays **inert until armed** (`PreRegistration__E2E__Enabled=true` + `PreRegistration__E2E__SmsCode=<secret>` env vars, plus the Twilio Verify custom-code feature check). Ticket stays open for the Playwright side: registration-stepper happy path, validation/error paths, fresh-verified-user fixture, and test-data hygiene. Starting with the paths that don't need the hook armed (client-side validation, no backend mutations).
spikerj commented 2026-07-04 00:23:59 +00:00
Author
Owner
Copy Link
Copy Source

Validation-path specs open: spikersoft-angular PR #111 — step-1 open/cancel, disabled-Next, username/email format errors, and the under-18 age gate, all mutation-free (safe on every PR run). Full anonymous project now 60 passed / 2 skipped.

Finding while writing them: the datepicker [max] (18 years ago) is the primary age gate — handleNext()'s isUnder18 branch can't be reached by normal typing; left in place as defense-in-depth but worth knowing it's untestable UI.

Remaining on this ticket (needs the merged #60 hook armed + runner access to read the email code): happy-path stepper run, bad-code/resend paths, fresh-verified-user fixture, and data hygiene. Two env prerequisites for that slice: (1) PreRegistration__E2E__Enabled + SmsCode on the API deployment, (2) a way for the suite to read emailVerificationCode — either Mongo access from the runner (VPN-internal mongo-router) or we add a sibling flag-gated echo of the code, worth deciding before I build it.

Validation-path specs open: spikersoft-angular PR #111 — step-1 open/cancel, disabled-Next, username/email format errors, and the under-18 age gate, all mutation-free (safe on every PR run). Full anonymous project now 60 passed / 2 skipped. Finding while writing them: the datepicker `[max]` (18 years ago) is the *primary* age gate — `handleNext()`'s `isUnder18` branch can't be reached by normal typing; left in place as defense-in-depth but worth knowing it's untestable UI. Remaining on this ticket (needs the merged #60 hook **armed** + runner access to read the email code): happy-path stepper run, bad-code/resend paths, fresh-verified-user fixture, and data hygiene. Two env prerequisites for that slice: (1) `PreRegistration__E2E__Enabled` + `SmsCode` on the API deployment, (2) a way for the suite to read `emailVerificationCode` — either Mongo access from the runner (VPN-internal `mongo-router`) or we add a sibling flag-gated echo of the code, worth deciding before I build it.
spikerj commented 2026-07-22 02:55:31 +00:00
Author
Owner
Copy Link
Copy Source

Board-sweep status (2026-07-22): blocker delivered (backend PR #60 flag-gated E2E SMS hook + angular PR #111 step-1 validation specs). REMAINING: the full registration round-trip spec.

Board-sweep status (2026-07-22): blocker delivered (backend PR #60 flag-gated E2E SMS hook + angular PR #111 step-1 validation specs). REMAINING: the full registration round-trip spec.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#318