device-voice-h5/openspec/changes/update-post-bind-wechat-login-recheck/design.md

Context

The project moved mandatory phone-binding enforcement to homepage entry, and then added a one-time homepage bypass after bind success to avoid an immediate redirect loop. A later draft proposed automatically re-running POST /api/c/v1/auth/wechat-login after bind success. The required direction is now simpler than both of those approaches: after mandatory bind success, route the user back to the login page, explain that they need to log in again, preserve the identifier they already entered, and let them manually restart login.

The login page already has behavior that can trigger login automatically from some restored inputs or URL parameters. The new flow therefore needs to preserve the identifier for convenience without accidentally auto-submitting login on the user's behalf.

Goals / Non-Goals

• Goals:
  • Return mandatory bind-success users to the login page
  • Show a clear re-login prompt after bind success
  • Preserve the previously entered identifier in the login input
  • Require the user to manually tap login again
• Non-Goals:
  • Do not add a new backend endpoint
  • Do not auto-run POST /api/c/v1/auth/wechat-login after bind success
  • Do not change the ordinary bind flow that starts from homepage actions

Decisions

• Decision: Mandatory bind completion SHALL route to pages/login/login instead of continuing directly to pages/index/index.
• Decision: The system SHALL show a one-time prompt that binding succeeded and the user must log in again.
• Decision: The previously entered identifier SHALL be preserved through the bind-success redirect and restored into the login input.
• Decision: Restoring the identifier SHALL NOT auto-submit login or auto-trigger the OAuth flow; the user must explicitly tap login.

Alternatives Considered

• Keep the one-time homepage bypass: rejected because the post-bind continuation no longer needs to jump directly into the homepage.
• Automatically re-run POST /api/c/v1/auth/wechat-login: rejected because the requested flow is to require an explicit user-driven re-login.
• Pass the identifier through a login-page path that auto-starts login: rejected because the user explicitly wants the identifier preserved without automatic login.

Risks / Trade-offs

• The client must distinguish between restoring an identifier for display and restoring one for automatic login initiation.
• The re-login prompt must be one-time or clearly scoped so it does not keep reappearing on unrelated later visits to the login page.

Migration Plan

1. Remove the automatic post-bind wechat-login continuation plan from the active draft.
2. Route mandatory bind success back to pages/login/login.
3. Preserve the identifier so the login input remains prefilled.
4. Show the re-login prompt and require a manual login tap.

Open Questions

• Which client-side storage path is the best fit for preserving the identifier while avoiding accidental auto-login behavior on the login page?