feat: 添加视觉设计语言系统并重构认证页面UI
- 新增 visual_design_language.md 设计规范文档 - 新增 auth 设计 tokens (authBackground, authCard, authInput, feedback 系列等) - 重构登录/注册/验证码/重置密码页面为新设计系统 - 新增 AuthHeroHeader, AuthSurfaceCard, AuthSection, AuthField, PasswordField 组件 - 重构 AppBanner 和 Toast 支持多类型配置 (info/success/warning/error) - 后端 AgentScope: 重整 schemas/prompts/tools 作用域, 新增协议文档 - 更新 AGENTS.md 集成视觉设计语言约束
This commit is contained in:
qzl
@@ -0,0 +1,318 @@
|
||||
# Auth Pages And Feedback System Redesign
|
||||
|
||||
## Goal
|
||||
|
||||
Redesign the mobile authentication experience so the login, register, and reset-password flows feel like a polished assistant product instead of a flat form flow, while preserving existing business logic, routing, validation, and feedback behavior semantics.
|
||||
|
||||
## Scope
|
||||
|
||||
- Rebuild the UI for `login`, `register`, and `reset-password`
|
||||
- Preserve existing auth logic, cubits, navigation, and API calls
|
||||
- Redesign the fixed-length code input experience for verification code and invite code
|
||||
- Redesign the feedback system into two coordinated layers:
|
||||
- global floating toast messages
|
||||
- in-component contextual messages
|
||||
- Keep all work inside the existing Flutter design system and shared widget architecture
|
||||
|
||||
## Constraints
|
||||
|
||||
- Must follow `apps/AGENTS.md`
|
||||
- Must follow `apps/rules/visual_design_language.md`
|
||||
- Must use tokens from `apps/lib/core/theme/design_tokens.dart`
|
||||
- Must not introduce a parallel feedback system outside the approved Toast and inline message architecture
|
||||
- Must not change auth protocols, routing semantics, or submission logic
|
||||
|
||||
## Current Problems
|
||||
|
||||
### Visual Problems
|
||||
|
||||
- The screens read as flat white pages with blue buttons, which matches a prohibited anti-pattern in the visual design language.
|
||||
- The main CTA button uses color as its only emphasis mechanism, so it feels plastic and low-fidelity.
|
||||
- The three auth screens share only superficial consistency, not a strong surface system.
|
||||
- The reset-password screen presents all steps at once, causing poor rhythm and weak hierarchy.
|
||||
- The verification code layout feels cramped and improvised because the code cells and send button compete on the same row.
|
||||
|
||||
### Feedback Problems
|
||||
|
||||
- Global toast messages are visually generic and lack product identity.
|
||||
- Component-level messaging is under-specified and inconsistently expressed.
|
||||
- Result messages and contextual validation messages are not clearly separated in responsibility.
|
||||
|
||||
## Design Direction
|
||||
|
||||
The approved direction is a floating-card auth system with a soft blue atmospheric background, a clear brand anchor, and a calm layered surface hierarchy.
|
||||
|
||||
The target feeling is:
|
||||
|
||||
- premium
|
||||
- calm
|
||||
- trustworthy
|
||||
- assistant-oriented
|
||||
- softly tactile
|
||||
- mobile-native
|
||||
|
||||
The redesign should feel like a cohesive product surface, not a stack of form containers.
|
||||
|
||||
## Surface Model
|
||||
|
||||
Each auth screen uses the same four-layer structure.
|
||||
|
||||
### 1. Background Surface
|
||||
|
||||
The screen background is not a plain blank fill. It should feel like a soft spatial field with subtle blue-gray atmosphere. This establishes the assistant mood before the user interacts with any form element.
|
||||
|
||||
### 2. Brand Anchor Surface
|
||||
|
||||
The top area contains the logo and brand title. On login and register, this remains the visual identity anchor. On reset password, the title becomes more task-driven, but the page still inherits the same spatial language and product mood.
|
||||
|
||||
### 3. Primary Floating Card
|
||||
|
||||
The form lives in a single, elevated primary card with softened corners, restrained shadows, and calm separation from the background. This card should feel intentional and product-grade rather than like a white panel.
|
||||
|
||||
### 4. Secondary Assistive Layer
|
||||
|
||||
Links, helper text, step hints, resend actions, and supplemental explanations belong to a lower-emphasis support layer. These elements should feel connected to the primary card without visually competing with it.
|
||||
|
||||
## Shared Auth Composition
|
||||
|
||||
All three auth screens should use a unified composition pattern.
|
||||
|
||||
- Top brand or task heading area
|
||||
- Main floating card for the active task
|
||||
- Internal grouped sections inside the card
|
||||
- Lightweight transition area for secondary actions
|
||||
|
||||
This creates cross-screen consistency while allowing each flow to have different emphasis.
|
||||
|
||||
## Screen Designs
|
||||
|
||||
### Login Screen
|
||||
|
||||
The login screen should be the most restrained and focused of the three.
|
||||
|
||||
Structure:
|
||||
|
||||
- logo and brand title at top
|
||||
- one compact floating form card
|
||||
- email field
|
||||
- password field
|
||||
- primary login CTA
|
||||
- low-emphasis forgot-password action inside the card
|
||||
- lightweight bottom switch action to register
|
||||
|
||||
Intent:
|
||||
|
||||
- reduce visual noise
|
||||
- make the login action feel confident and central
|
||||
- keep account switching and recovery available without stealing focus
|
||||
|
||||
### Register Screen
|
||||
|
||||
The register screen should feel richer than login, but still composed.
|
||||
|
||||
Structure:
|
||||
|
||||
- same brand anchor as login
|
||||
- taller primary card
|
||||
- grouped section for core account information
|
||||
- grouped section for invite code as an optional enhancement
|
||||
- subtle progress indicator treated as part of the card rhythm, not as a crude progress bar
|
||||
- primary CTA for moving to verification
|
||||
- lightweight switch action to login
|
||||
|
||||
Invite code treatment:
|
||||
|
||||
- remains a fixed-length segmented input
|
||||
- visually grouped as an optional section, not mixed into the main required inputs
|
||||
- supported by a nearby low-emphasis explanation block
|
||||
|
||||
### Reset Password Screen
|
||||
|
||||
The reset-password screen should shift from a flat all-fields form into a guided two-stage flow.
|
||||
|
||||
Structure:
|
||||
|
||||
- task heading at top
|
||||
- primary floating card
|
||||
- stage one: email input plus send-code action
|
||||
- after successful code send, reveal stage two inside the same card
|
||||
- stage two: segmented verification code input, resend action, new password, confirm password, submit CTA
|
||||
- lightweight return-to-login switch action below
|
||||
|
||||
Intent:
|
||||
|
||||
- create procedural clarity
|
||||
- avoid forcing all fields onto the screen at once
|
||||
- make the verification code area feel deliberate and product-grade
|
||||
|
||||
## Fixed-Length Segmented Input Design
|
||||
|
||||
The user explicitly prefers fixed-length segmented input for both verification code and invite code. This input pattern will be preserved.
|
||||
|
||||
However, it will be redesigned to feel like a premium grouped input rather than a row of raw boxes.
|
||||
|
||||
Design principles:
|
||||
|
||||
- the individual cells must read as one continuous input group
|
||||
- current focus should be visible at both cell level and group level
|
||||
- spacing should be balanced and calm
|
||||
- filled state should feel confident and readable
|
||||
- disabled and error states should be obvious without becoming harsh
|
||||
|
||||
Required states:
|
||||
|
||||
- default
|
||||
- focused group
|
||||
- active cell
|
||||
- filled
|
||||
- error
|
||||
- disabled
|
||||
|
||||
Usage rules:
|
||||
|
||||
- verification code remains segmented
|
||||
- invite code remains segmented
|
||||
- resend action is no longer visually fused to the segmented input row
|
||||
|
||||
## Button Design
|
||||
|
||||
The CTA button must stop reading as a flat blue block.
|
||||
|
||||
New button intent:
|
||||
|
||||
- deeper and calmer brand blue
|
||||
- stronger tactile weight
|
||||
- premium capsule shape
|
||||
- light depth through tonal layering and restrained shadow
|
||||
- pressed and disabled states that clearly change material weight
|
||||
|
||||
Button hierarchy:
|
||||
|
||||
- primary button: for submission and key forward progress
|
||||
- secondary button: for bounded alternative actions
|
||||
- text-link action: for lightweight transitions and low-risk actions
|
||||
|
||||
Color strategy:
|
||||
|
||||
- blue remains the anchor, but is used with restraint
|
||||
- the strongest emphasis goes to the main CTA only
|
||||
- supporting actions should not look equally loud
|
||||
|
||||
## Input Field Design
|
||||
|
||||
Text fields should move from generic bordered rectangles to soft embedded surfaces.
|
||||
|
||||
Desired qualities:
|
||||
|
||||
- calmer default appearance
|
||||
- stronger focus clarity
|
||||
- reduced raw border noise
|
||||
- consistent radius and spacing rhythm
|
||||
- visually integrated label, input, and helper message states
|
||||
|
||||
## Feedback System Redesign
|
||||
|
||||
The feedback system is split into two coordinated layers.
|
||||
|
||||
### 1. Global Floating Toast
|
||||
|
||||
Global toast is a lightweight floating feedback card presented in the safe area near the top of the screen.
|
||||
|
||||
Use global toast for:
|
||||
|
||||
- cross-component success feedback
|
||||
- async result notifications
|
||||
- cross-step flow results
|
||||
- errors that are not tied to a single visible field
|
||||
|
||||
Do not use global toast for:
|
||||
|
||||
- simple inline validation
|
||||
- field-level format guidance
|
||||
- contextual explanations that belong near the active input area
|
||||
|
||||
Visual direction:
|
||||
|
||||
- floating product card, not a system notification strip
|
||||
- soft surface and rounded shape
|
||||
- restrained state tinting
|
||||
- icon plus title/message hierarchy if needed
|
||||
- gentle slide/fade motion
|
||||
|
||||
### 2. In-Component Contextual Message
|
||||
|
||||
Contextual messages live inside the component or form group they explain.
|
||||
|
||||
Use contextual messages for:
|
||||
|
||||
- validation near fields
|
||||
- warnings tied to current form state
|
||||
- helper guidance for invite code or verification flow
|
||||
- inline explanation of what the user should fix next
|
||||
|
||||
Visual direction:
|
||||
|
||||
- integrated into the card hierarchy
|
||||
- lighter than a toast
|
||||
- close to the related field or group
|
||||
- consistent state styling across info, warning, and error
|
||||
|
||||
### Responsibility Boundary
|
||||
|
||||
- global toast = result-oriented, temporary, cross-context feedback
|
||||
- inline message = contextual, explanatory, local feedback
|
||||
|
||||
This separation prevents toast overuse and makes forms feel calmer.
|
||||
|
||||
## Motion Language
|
||||
|
||||
Motion should be soft and minimal.
|
||||
|
||||
Use motion for:
|
||||
|
||||
- toast entrance and dismissal
|
||||
- reset-password stage reveal
|
||||
- button press feedback
|
||||
- segmented input focus continuity
|
||||
|
||||
Avoid:
|
||||
|
||||
- springy or playful motion
|
||||
- overlapping dramatic transitions
|
||||
- flashy state animations
|
||||
|
||||
## Shared Component Impact
|
||||
|
||||
The redesign likely requires updates or additions to shared widgets rather than one-off page styling.
|
||||
|
||||
Expected shared component work:
|
||||
|
||||
- refine `AppButton`
|
||||
- refine or replace current toast visuals
|
||||
- refine `AppBanner` or introduce a shared inline message presentation built on the same semantics
|
||||
- redesign `FixedLengthCodeInput`
|
||||
- add a reusable auth surface wrapper if needed
|
||||
|
||||
## Verification Strategy
|
||||
|
||||
Because this work is UI-heavy, verification should focus on correctness, consistency, and safe reuse.
|
||||
|
||||
Primary verification targets:
|
||||
|
||||
- `flutter analyze`
|
||||
- impacted auth tests
|
||||
- targeted widget tests only where reusable interactive widgets become materially more complex
|
||||
- manual visual review of the three auth screens and feedback states
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The redesign is successful when all of the following are true:
|
||||
|
||||
- the three auth screens feel like one coherent product system
|
||||
- the UI no longer resembles a plain white form page with blue buttons
|
||||
- the main CTA has better perceived material quality
|
||||
- reset password has a clearer and more attractive two-stage flow
|
||||
- segmented code input remains intact but feels premium
|
||||
- global toasts and inline messages have clear responsibility boundaries
|
||||
- the feedback system feels native to the product rather than bolted on
|
||||
- the result plausibly matches the visual language standard for a polished assistant app
|
||||
@@ -0,0 +1,337 @@
|
||||
# Auth Pages Redesign Implementation Plan
|
||||
|
||||
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
|
||||
|
||||
**Goal:** Redesign the Flutter auth pages and feedback system so login, register, reset-password, segmented code input, and toast/inline feedback all match the project visual design language while preserving existing logic.
|
||||
|
||||
**Architecture:** Keep auth business logic, cubits, navigation, and repository behavior unchanged. Move the redesign into shared design tokens and shared widgets first, then rebuild each auth screen on top of those primitives so the result is reusable and consistent.
|
||||
|
||||
**Tech Stack:** Flutter, flutter_bloc, go_router, existing design tokens and shared widgets under `apps/lib/`
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Audit reusable auth and feedback primitives
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/core/theme/design_tokens.dart`
|
||||
- Modify: `apps/lib/shared/widgets/app_button.dart`
|
||||
- Modify: `apps/lib/shared/widgets/fixed_length_code_input.dart`
|
||||
- Modify: `apps/lib/shared/widgets/toast/toast.dart`
|
||||
- Modify: `apps/lib/shared/widgets/banner/app_banner.dart`
|
||||
- Test: `apps/test/` relevant existing widget or feature tests if impacted
|
||||
|
||||
**Step 1: Identify missing token semantics before UI changes**
|
||||
|
||||
Review current colors, spacing, radius, and surface semantics. List any missing token roles needed for:
|
||||
- atmospheric auth background
|
||||
- floating card border/shadow layering
|
||||
- premium CTA surface states
|
||||
- segmented input states
|
||||
- toast and inline message states
|
||||
|
||||
**Step 2: Add only the minimal new tokens needed**
|
||||
|
||||
Update `apps/lib/core/theme/design_tokens.dart` with shared semantic tokens rather than page-local constants.
|
||||
|
||||
Expected areas:
|
||||
- auth background surface tones
|
||||
- auth card border/highlight tones
|
||||
- stronger button tonal roles
|
||||
- inline message backgrounds/borders/text roles
|
||||
- toast surface roles if existing status tokens are insufficient
|
||||
|
||||
**Step 3: Run a quick compile-oriented check mentally against all planned components**
|
||||
|
||||
Confirm the new tokens are generic enough for shared reuse and not named after individual screens.
|
||||
|
||||
**Step 4: Commit checkpoint note**
|
||||
|
||||
Do not create a git commit unless explicitly requested by the user.
|
||||
|
||||
### Task 2: Redesign shared CTA and link interaction surfaces
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/shared/widgets/app_button.dart`
|
||||
- Modify: `apps/lib/shared/widgets/link_button.dart`
|
||||
- Test: existing auth tests if button usage affects behavior
|
||||
|
||||
**Step 1: Write the failing test if widget behavior changes materially**
|
||||
|
||||
If the redesign introduces new behavior beyond styling, add a targeted widget test. If changes remain visual-only, document that no new test is added per lightweight UI testing policy.
|
||||
|
||||
**Step 2: Refactor `AppButton` into a stronger material hierarchy**
|
||||
|
||||
Implement:
|
||||
- calmer premium CTA surface
|
||||
- better disabled state separation
|
||||
- consistent capsule-like shape
|
||||
- optional secondary/outlined appearance if already used
|
||||
|
||||
Keep public API stable unless a small safe extension is clearly needed.
|
||||
|
||||
**Step 3: Refine `LinkButton` hit area and visual tone**
|
||||
|
||||
Implement:
|
||||
- clearer touch target
|
||||
- lighter emphasis than CTA
|
||||
- better pressed and disabled feel
|
||||
|
||||
**Step 4: Run impacted checks**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: no new analyzer issues from button or link widget changes.
|
||||
|
||||
### Task 3: Redesign segmented input as a premium grouped control
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/shared/widgets/fixed_length_code_input.dart`
|
||||
- Test: add or update a widget test only if interaction logic changes materially
|
||||
|
||||
**Step 1: Write the failing test for any changed interaction behavior**
|
||||
|
||||
If focus progression, formatting, or semantic behavior changes, add a widget test that captures the intended interaction. If only visuals change, document why no new test is added.
|
||||
|
||||
**Step 2: Rebuild the visual structure of the segmented input**
|
||||
|
||||
Implement:
|
||||
- clearer grouped container feel
|
||||
- balanced cell rhythm
|
||||
- group-level focus cue plus active-cell cue
|
||||
- stronger filled state
|
||||
- polished error and disabled states
|
||||
|
||||
**Step 3: Preserve existing logical behavior**
|
||||
|
||||
Keep:
|
||||
- fixed length handling
|
||||
- allowed character filtering
|
||||
- uppercase support
|
||||
- autofill compatibility
|
||||
|
||||
**Step 4: Run focused verification**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: no new issues from segmented input refactor.
|
||||
|
||||
### Task 4: Rebuild global toast and inline message visuals
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/shared/widgets/toast/toast.dart`
|
||||
- Modify: `apps/lib/shared/widgets/banner/app_banner.dart`
|
||||
- Modify: `apps/lib/shared/widgets/toast/toast_type.dart` if needed
|
||||
- Modify: `apps/lib/shared/widgets/toast/toast_type_config.dart`
|
||||
- Test: add widget tests only if feedback behavior semantics change
|
||||
|
||||
**Step 1: Inspect current toast config implementation**
|
||||
|
||||
Review `toast_type_config.dart` and align the redesign with shared semantic tokens.
|
||||
|
||||
**Step 2: Redesign global toast as a floating product card**
|
||||
|
||||
Implement:
|
||||
- safe-area aware floating card
|
||||
- refined tint, border, icon, and text hierarchy
|
||||
- restrained shadow and motion
|
||||
- stable dismissal behavior
|
||||
|
||||
**Step 3: Redesign inline message presentation**
|
||||
|
||||
Implement:
|
||||
- lighter component-level message styling
|
||||
- consistent relationship to current form group
|
||||
- clear differentiation from toast while sharing status semantics
|
||||
|
||||
**Step 4: Preserve system rules**
|
||||
|
||||
Keep:
|
||||
- `Toast.show(...)` for transient global feedback
|
||||
- `AppBanner` for persistent inline feedback
|
||||
- no raw `ScaffoldMessenger`
|
||||
|
||||
**Step 5: Run focused verification**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: no analyzer issues.
|
||||
|
||||
### Task 5: Add a reusable auth surface composition primitive
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/features/auth/ui/widgets/auth_page_scaffold.dart`
|
||||
- Create or Modify: `apps/lib/features/auth/ui/widgets/` shared auth surface widgets as needed
|
||||
|
||||
**Step 1: Evaluate whether the existing scaffold can express the new surface hierarchy**
|
||||
|
||||
Check whether `AuthPageScaffold` can support:
|
||||
- atmospheric background treatment
|
||||
- safe-area balanced centering
|
||||
- top brand anchor spacing
|
||||
- floating card composition
|
||||
|
||||
**Step 2: Implement the minimal reusable auth layout primitives**
|
||||
|
||||
Possible additions:
|
||||
- auth hero header
|
||||
- auth floating card shell
|
||||
- grouped section wrapper
|
||||
|
||||
Only create what is reused by at least two auth screens.
|
||||
|
||||
**Step 3: Keep layout semantics explicit**
|
||||
|
||||
Ensure every `Row` and `Column` has explicit `crossAxisAlignment` and layout intent remains traceable.
|
||||
|
||||
### Task 6: Rebuild the login page UI on top of the shared primitives
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/features/auth/ui/screens/login_screen.dart`
|
||||
|
||||
**Step 1: Preserve all existing logic paths**
|
||||
|
||||
Do not change:
|
||||
- cubit usage
|
||||
- submit flow
|
||||
- auth bloc event dispatch
|
||||
- navigation targets
|
||||
|
||||
**Step 2: Replace the existing layout with the new design**
|
||||
|
||||
Implement:
|
||||
- brand anchor header
|
||||
- compact floating login card
|
||||
- refined email and password groups
|
||||
- CTA-first hierarchy
|
||||
- lightweight forgot-password action
|
||||
- low-emphasis register switch
|
||||
|
||||
**Step 3: Reconnect inline feedback to the new grouping**
|
||||
|
||||
Place validation and error banners where they support the form rhythm rather than interrupt it.
|
||||
|
||||
**Step 4: Run impacted checks**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: login screen compiles cleanly.
|
||||
|
||||
### Task 7: Rebuild the register page UI with grouped invite code treatment
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/features/auth/ui/screens/register_screen.dart`
|
||||
|
||||
**Step 1: Preserve all existing logic paths**
|
||||
|
||||
Do not change:
|
||||
- cubit usage
|
||||
- invite code normalization
|
||||
- validation behavior
|
||||
- route transition to verification page
|
||||
- silent code send behavior
|
||||
|
||||
**Step 2: Rebuild required and optional sections**
|
||||
|
||||
Implement:
|
||||
- shared brand anchor header
|
||||
- taller floating card
|
||||
- grouped account info section
|
||||
- separate optional invite code section
|
||||
- refined progress indicator treatment
|
||||
- improved footer switch action
|
||||
|
||||
**Step 3: Keep segmented invite code input**
|
||||
|
||||
Use the redesigned shared segmented input without changing its fixed-length semantics.
|
||||
|
||||
**Step 4: Run impacted checks**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: register screen compiles cleanly.
|
||||
|
||||
### Task 8: Rebuild the reset-password page as a guided two-stage flow
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/lib/features/auth/ui/screens/reset_password_screen.dart`
|
||||
|
||||
**Step 1: Preserve all existing logic and feedback semantics**
|
||||
|
||||
Do not change:
|
||||
- cubit interactions
|
||||
- send code and resend behavior
|
||||
- submit behavior
|
||||
- success redirect
|
||||
- toast semantics
|
||||
|
||||
**Step 2: Recompose the screen into staged groups**
|
||||
|
||||
Implement:
|
||||
- task-focused header
|
||||
- stage one email + send code group
|
||||
- stage two reveal for code and password reset controls after send success
|
||||
- separate resend action from the code row while preserving usability
|
||||
|
||||
**Step 3: Reconnect segmented verification code input and inline messaging**
|
||||
|
||||
Make the code group feel premium and central without overcrowding the card.
|
||||
|
||||
**Step 4: Run impacted checks**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: reset-password screen compiles cleanly.
|
||||
|
||||
### Task 9: Run verification and inspect affected tests
|
||||
|
||||
**Files:**
|
||||
- Test: impacted auth tests and any new widget tests added
|
||||
|
||||
**Step 1: Run analyzer**
|
||||
|
||||
Run: `flutter analyze`
|
||||
|
||||
Expected: PASS with no new issues.
|
||||
|
||||
**Step 2: Run impacted auth tests**
|
||||
|
||||
Run an auth-focused test subset appropriate to the changed files, for example:
|
||||
|
||||
```bash
|
||||
flutter test apps/test/features/auth
|
||||
```
|
||||
|
||||
Adjust the exact command to the repository's Flutter test layout if needed.
|
||||
|
||||
Expected: existing auth tests remain green; any new targeted widget tests pass.
|
||||
|
||||
**Step 3: Manual visual review checklist**
|
||||
|
||||
Verify:
|
||||
- login looks calm and premium
|
||||
- register invite code section feels optional but intentional
|
||||
- reset-password stage flow is clear
|
||||
- segmented code input feels grouped and polished
|
||||
- toast feels like a product surface
|
||||
- inline messages feel local and non-intrusive
|
||||
|
||||
### Task 10: Final review and handoff
|
||||
|
||||
**Files:**
|
||||
- Modify: any touched files from previous tasks if final polish is needed
|
||||
|
||||
**Step 1: Check for consistency drift**
|
||||
|
||||
Ensure the three auth pages, toast, inline messages, buttons, and segmented input all feel like one system.
|
||||
|
||||
**Step 2: Confirm no scope creep changed logic unexpectedly**
|
||||
|
||||
Re-check that routing, auth behavior, and validation rules remain intact.
|
||||
|
||||
**Step 3: Prepare concise handoff summary**
|
||||
|
||||
Include:
|
||||
- files changed
|
||||
- verification commands run
|
||||
- test results
|
||||
- any follow-up visual refinements still worth considering
|
||||
Reference in New Issue
Block a user