Components
Account controls
Email, password and permanent account deletion are distinct settings operations.
On this page
Purpose and placement
Email, password and permanent account deletion are distinct settings operations.
Anatomy
- Email panel
- New/confirm password fields
- Per-operation messages
- Separate danger zone
Contract
| Input or boundary | Behavior |
|---|---|
| PATCH /api/account with email | |
| Password | Client minimum eight characters and matching confirmation |
| Delete | Native confirmation, DELETE, then signOut |
States and feedback
- Ready
- Saving email/password
- Mismatch / short password
- Success message
- Deleting
Interaction and composition
Keep password fields independent from display identity. Validate before starting provider work. Show the deletion consequence before the native confirmation and never perform it during screenshot preparation.
Responsive behavior
Full panels stack; the danger zone remains visually separate.
Accessibility contract
Most field labels are visual rather than associated. Destructive action is named with visible text; password feedback uses ordinary paragraphs instead of announced errors.
Known implementation gaps
Capture account data is fictional and success is mocked. Recovery controls and explicit error colors/semantics are limited.
Source references
| Repository file | Responsibility |
|---|---|
| app/settings/account/page.tsx | Account UI |
| app/api/account/route.ts | Account authorization and validation |
Examples from the app
Actual Startboard source UI with isolated fictional records; both native themes at 2× resolution or higher. No live integrations or account writes. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-08 · Revision 08fa2595a668 · Documentation v1.0.0