All 37 tasks complete. Synced delta specs to main: - New: openspec/specs/account-settings/ - Updated: openspec/specs/journal-auth/ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
83 lines
3.4 KiB
Markdown
83 lines
3.4 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Settings page access
|
|
The Journal SHALL provide an account settings page at `/settings` accessible to authenticated users.
|
|
|
|
#### Scenario: Authenticated access
|
|
- **WHEN** a logged-in user navigates to `/settings`
|
|
- **THEN** the settings page is displayed with profile, security, and account sections
|
|
|
|
#### Scenario: Unauthenticated access
|
|
- **WHEN** an unauthenticated user navigates to `/settings`
|
|
- **THEN** they are redirected to `/auth/login`
|
|
|
|
### Requirement: Profile editing
|
|
The settings page SHALL allow users to edit their display name and bio.
|
|
|
|
#### Scenario: Update display name
|
|
- **WHEN** a user changes their display name and submits
|
|
- **THEN** the display name is updated and reflected on their public profile
|
|
|
|
#### Scenario: Update bio
|
|
- **WHEN** a user enters a bio (max 160 characters) and submits
|
|
- **THEN** the bio is saved and visible on their public profile
|
|
|
|
#### Scenario: Empty fields
|
|
- **WHEN** a user clears their display name
|
|
- **THEN** their username is used as the display name fallback
|
|
|
|
### Requirement: Passkey management
|
|
The settings page SHALL list all registered passkeys and allow adding or deleting them.
|
|
|
|
#### Scenario: View passkeys
|
|
- **WHEN** a user visits the security section
|
|
- **THEN** they see a list of their passkeys with device type, transport label, and registration date
|
|
|
|
#### Scenario: Add passkey
|
|
- **WHEN** a user clicks "Add passkey" on a browser that supports WebAuthn
|
|
- **THEN** the browser passkey creation prompt appears and the new passkey is added to the list
|
|
|
|
#### Scenario: Add passkey unsupported browser
|
|
- **WHEN** a user visits the security section on a browser without WebAuthn
|
|
- **THEN** the "Add passkey" button is disabled with a message explaining the browser limitation
|
|
|
|
#### Scenario: Delete passkey
|
|
- **WHEN** a user clicks delete on a passkey and confirms
|
|
- **THEN** the passkey is removed and can no longer be used for login
|
|
|
|
#### Scenario: Delete last passkey
|
|
- **WHEN** a user deletes their only passkey
|
|
- **THEN** a warning is shown that they will need to use magic links to sign in, and the deletion proceeds after confirmation
|
|
|
|
### Requirement: Email change
|
|
The settings page SHALL allow users to change their email address with verification.
|
|
|
|
#### Scenario: Initiate email change
|
|
- **WHEN** a user enters a new email and submits
|
|
- **THEN** a verification link is sent to the new email address
|
|
|
|
#### Scenario: Verify new email
|
|
- **WHEN** the user clicks the verification link
|
|
- **THEN** their email is updated to the new address
|
|
|
|
#### Scenario: Duplicate email
|
|
- **WHEN** a user enters an email already in use by another account
|
|
- **THEN** an error is shown indicating the email is taken
|
|
|
|
### Requirement: Account deletion
|
|
The settings page SHALL allow users to permanently delete their account.
|
|
|
|
#### Scenario: Delete account
|
|
- **WHEN** a user clicks "Delete account" and types their username to confirm
|
|
- **THEN** their account and all associated data are permanently deleted and they are logged out
|
|
|
|
#### Scenario: Cancel deletion
|
|
- **WHEN** a user opens the delete confirmation but does not confirm
|
|
- **THEN** no data is deleted and they remain on the settings page
|
|
|
|
### Requirement: Settings navigation
|
|
The Journal navigation SHALL include a link to the settings page for authenticated users.
|
|
|
|
#### Scenario: Settings link visible
|
|
- **WHEN** a logged-in user views the navigation
|
|
- **THEN** a "Settings" link is present that navigates to `/settings`
|