Account experience
Work record: application source inspected 3 October 2026.
The sign-in and onboarding screens are connected to account operations in the application code. A visitor can choose email or Google, establish access to an account and complete the nickname step required for participation.
The implemented journey
| Step | Behavior found in the source |
|---|---|
| Choose a sign-in method | The sign-in screen offers email-code and Google flows. |
| Prove access | The code screen supports entering a code, requesting a resend and changing the email; the provider flow handles Google's return. |
| Complete a new account | A signed-in account needing a nickname is routed to onboarding. The nickname screen handles an unavailable name and a successful creation result. |
| Return to the product | An account with completed onboarding returns to the product; session refresh, logout and profile access have product-service operations. |
The account explanation describes identity linking, private email, public nickname and the limits of recovery. Those rules matter when one person uses both sign-in methods.
How to discuss or demonstrate it
Use this sequence when the team presents the account flow in a configured environment:
- Start signed out and choose email. Follow the code step with a permitted test address, then complete the nickname step for a new account.
- Return to the product and inspect the signed-in account state. Log out, then sign in again to check that the same account is recovered.
- Walk through the Google path separately, including a case where another email proof is required before linking an existing account.
This is a walkthrough of the implemented design, not a report that the live sequence has been demonstrated. Record the environment, date and actual result when that demonstration happens. The current source record supplies no live demo link or delivery-to-inbox proof.
What this work does not establish
A working account foundation does not by itself deliver reviews, moderation, reward balances or contribution privileges. The nickname-change policy is part of the account design; this record only verifies the initial onboarding surface, not a monthly nickname-change screen.
Contribution scope belongs in the community review brief. The first-platform brief asks which complete reader and staff journey should follow the account foundation.