Opening an emailed verification link must run account activation and show the confirmed-email page. Continuing to login must preserve the verified email without requiring it to be retyped.
Approach
Align Flutter web URL strategy with generated path-style verification links. Return the verified account email only after transactional activation succeeds, map it through the established DTO/service/model/provider flow, and pass it transiently into an editable login form with password focus. Preserve explicit success, expired/invalid/retry states and privacy-safe journey outcomes.
Acceptance criteria
A direct path-style verification link reaches checking and then the actual backend result instead of silently showing login.
Successful activation changes the pending local account to active, consumes its token atomically and returns the verified email; failed/expired/invalid attempts expose no email.
Successful verification remains visible and offers Continue to login with the verified email prefilled, password empty and password focused.
Prefill survives the explicit in-memory navigation without serializing email into URLs/history or analytics; token changes and failures clear stale identity.
Real backend and dummy adapters preserve the established transport-to-provider architecture; meaningful success/failure/routing tests and required backend/frontend validation pass.
Scope, validation, local verification limitations and delivery links are documented.
Notes
Primary module email-verification; secondary modules product auth flow/HTTP, shared Flutter auth and consumer routing/UI. Owner tech; project SXCHNGE (16); backend/frontend labels. Use an isolated worktree from main and preserve the existing identity-facts-57 local stand work. The supplied private verification link is diagnostic input only: never commit its token, place it in task text, or send it to external services. Do not auto-login after activation or retain passwords. Existing auth journey outcome instrumentation should be reused. No new security scan is requested. Merge requires user authorization; any local rebuild must retain the existing stand configuration.
Delivery: PR #61, commits 5f3b443 and a587cbb. Required checks passed after authorized Docker restart: changed Dart formatting, Flutter analysis in app/auth package, make test-frontend (217 tests), GOFLAGS=-p=1 make test, make lint-backend, and focused activation integration. Built demo browser confirms direct success → explicit login → editable verified email/empty focused password; expired recovery also checked. Native Safari automation unavailable. Initial Docker-related failures and recovery are recorded in docs/ux/auth-journeys.md.
Fresh stable image resolution and BFF/frontend rebuild succeeded. Local integration preserves identity-facts-57 configuration. BFF/frontend/Sendico sidecar are healthy; HTTPS bundle matches the rebuilt image, invalid-token response exposes no email, and authenticated Sendico API check passes. All previously running non-test services were restored, including unsealing existing Sendico Vault. The real diagnostic token remains unused and unexpired, ready for the user to reopen. PR is ready for review and remains unmerged pending authorization.
### Goal
Opening an emailed verification link must run account activation and show the confirmed-email page. Continuing to login must preserve the verified email without requiring it to be retyped.
### Approach
Align Flutter web URL strategy with generated path-style verification links. Return the verified account email only after transactional activation succeeds, map it through the established DTO/service/model/provider flow, and pass it transiently into an editable login form with password focus. Preserve explicit success, expired/invalid/retry states and privacy-safe journey outcomes.
### Acceptance criteria
- [x] A direct path-style verification link reaches checking and then the actual backend result instead of silently showing login.
- [x] Successful activation changes the pending local account to active, consumes its token atomically and returns the verified email; failed/expired/invalid attempts expose no email.
- [x] Successful verification remains visible and offers Continue to login with the verified email prefilled, password empty and password focused.
- [x] Prefill survives the explicit in-memory navigation without serializing email into URLs/history or analytics; token changes and failures clear stale identity.
- [x] Real backend and dummy adapters preserve the established transport-to-provider architecture; meaningful success/failure/routing tests and required backend/frontend validation pass.
- [x] Scope, validation, local verification limitations and delivery links are documented.
### Notes
Primary module email-verification; secondary modules product auth flow/HTTP, shared Flutter auth and consumer routing/UI. Owner tech; project SXCHNGE (16); backend/frontend labels. Use an isolated worktree from main and preserve the existing identity-facts-57 local stand work. The supplied private verification link is diagnostic input only: never commit its token, place it in task text, or send it to external services. Do not auto-login after activation or retain passwords. Existing auth journey outcome instrumentation should be reused. No new security scan is requested. Merge requires user authorization; any local rebuild must retain the existing stand configuration.
Delivery: [PR #61](https://git.sendico.io/tech/sxchnge/pulls/61), commits `5f3b443` and `a587cbb`. Required checks passed after authorized Docker restart: changed Dart formatting, Flutter analysis in app/auth package, `make test-frontend` (217 tests), `GOFLAGS=-p=1 make test`, `make lint-backend`, and focused activation integration. Built demo browser confirms direct success → explicit login → editable verified email/empty focused password; expired recovery also checked. Native Safari automation unavailable. Initial Docker-related failures and recovery are recorded in `docs/ux/auth-journeys.md`.
Fresh stable image resolution and BFF/frontend rebuild succeeded. Local integration preserves identity-facts-57 configuration. BFF/frontend/Sendico sidecar are healthy; HTTPS bundle matches the rebuilt image, invalid-token response exposes no email, and authenticated Sendico API check passes. All previously running non-test services were restored, including unsealing existing Sendico Vault. The real diagnostic token remains unused and unexpired, ready for the user to reopen. PR is ready for review and remains unmerged pending authorization.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Opening an emailed verification link must run account activation and show the confirmed-email page. Continuing to login must preserve the verified email without requiring it to be retyped.
Approach
Align Flutter web URL strategy with generated path-style verification links. Return the verified account email only after transactional activation succeeds, map it through the established DTO/service/model/provider flow, and pass it transiently into an editable login form with password focus. Preserve explicit success, expired/invalid/retry states and privacy-safe journey outcomes.
Acceptance criteria
Notes
Primary module email-verification; secondary modules product auth flow/HTTP, shared Flutter auth and consumer routing/UI. Owner tech; project SXCHNGE (16); backend/frontend labels. Use an isolated worktree from main and preserve the existing identity-facts-57 local stand work. The supplied private verification link is diagnostic input only: never commit its token, place it in task text, or send it to external services. Do not auto-login after activation or retain passwords. Existing auth journey outcome instrumentation should be reused. No new security scan is requested. Merge requires user authorization; any local rebuild must retain the existing stand configuration.
Delivery: PR #61, commits
5f3b443anda587cbb. Required checks passed after authorized Docker restart: changed Dart formatting, Flutter analysis in app/auth package,make test-frontend(217 tests),GOFLAGS=-p=1 make test,make lint-backend, and focused activation integration. Built demo browser confirms direct success → explicit login → editable verified email/empty focused password; expired recovery also checked. Native Safari automation unavailable. Initial Docker-related failures and recovery are recorded indocs/ux/auth-journeys.md.Fresh stable image resolution and BFF/frontend rebuild succeeded. Local integration preserves identity-facts-57 configuration. BFF/frontend/Sendico sidecar are healthy; HTTPS bundle matches the rebuilt image, invalid-token response exposes no email, and authenticated Sendico API check passes. All previously running non-test services were restored, including unsealing existing Sendico Vault. The real diagnostic token remains unused and unexpired, ready for the user to reopen. PR is ready for review and remains unmerged pending authorization.