trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Archive account-settings change, sync specs

Browse source 
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>
This commit is contained in:
Ullrich Schäfer 2026-03-29 22:41:51 +02:00
parent 0150c40631
commit 7e253caf64
No known key found for this signature in database
GPG key ID: A32FF691A0F752D9
9 changed files with 161 additions and 179 deletions
Download patch file Download diff file Expand all files Collapse all files

83
openspec/specs/account-settings/spec.md Normal file
View file

@ -0,0 +1,83 @@
## 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`

131
openspec/specs/journal-auth/spec.md
View file

@ -1,130 +1,29 @@
## ADDED Requirements
### Requirement: Passkey registration
The Journal SHALL allow new users to register using a passkey (WebAuthn) when the browser supports it. No password is required.
#### Scenario: Successful passkey registration
- **WHEN** a user enters an email and username and creates a passkey via the browser prompt
- **THEN** a new user account is created, the passkey credential is stored, and the user is logged in
#### Scenario: Duplicate email
- **WHEN** a user submits an email that is already registered
- **THEN** the system displays an error indicating the email is already in use
#### Scenario: Duplicate username
- **WHEN** a user submits a username that is already taken
- **THEN** the system displays an error indicating the username is not available
### Requirement: Magic link registration (fallback)
The Journal SHALL allow new users to register via magic link when the browser does not support passkeys. The user can add a passkey later from a supported browser.
#### Scenario: Register without passkey support
- **WHEN** a user's browser does not support WebAuthn
- **THEN** the registration page shows a "Register with Magic Link" button instead of the passkey button
#### Scenario: Successful magic link registration
- **WHEN** a user submits email and username via magic link registration
- **THEN** a new user account is created without a credential, a verification email is sent, and the user is redirected to verify their email
#### Scenario: Magic link verify redirects to add-passkey
- **WHEN** a user clicks the verification link from magic link registration
- **THEN** they are logged in and redirected to the home page with the add-passkey prompt
### Requirement: Passkey login
The Journal SHALL allow returning users to log in using a stored passkey when the browser supports WebAuthn.
#### Scenario: Successful passkey login
- **WHEN** a user clicks "Sign in" and selects a passkey from the browser prompt
- **THEN** the user is authenticated and redirected to their activity feed
#### Scenario: No passkey available
- **WHEN** a user has no passkey on the current device
- **THEN** the system offers magic link login as a fallback
#### Scenario: Browser without WebAuthn support
- **WHEN** a user's browser does not support WebAuthn
- **THEN** the login page shows only the magic link option with no passkey button
### Requirement: Magic link login (fallback)
The Journal SHALL allow users to log in via a magic link sent to their email. This serves as a fallback for devices without passkey support or for logging in on a new device.
#### Scenario: Request magic link
- **WHEN** a user enters their email and clicks "Send magic link"
- **THEN** an email with a single-use login link is sent to their address
#### Scenario: Valid magic link
- **WHEN** a user clicks a valid, non-expired magic link
- **THEN** the user is logged in and the link is invalidated
#### Scenario: Expired magic link
- **WHEN** a user clicks a magic link older than 15 minutes
- **THEN** the system displays an error and prompts them to request a new link
#### Scenario: Rate limiting
- **WHEN** a user requests more than 5 magic links in 10 minutes
- **THEN** subsequent requests are rejected with a rate limit message
## MODIFIED Requirements
### Requirement: Add passkey from new device
The Journal SHALL allow logged-in users to register additional passkeys for new devices.
The Journal SHALL allow logged-in users to register additional passkeys from the account settings page or via the post-login prompt.
#### Scenario: Add passkey after magic link login
- **WHEN** a user logs in via magic link on a device that supports WebAuthn
- **THEN** the system prompts them to register a passkey for that device
#### Scenario: Add passkey from settings
- **WHEN** a user clicks "Add passkey" in the security section of account settings
- **THEN** the browser passkey creation prompt appears and the new passkey is stored
#### Scenario: Add passkey prompt on unsupported browser
- **WHEN** a user logs in via magic link on a device that does not support WebAuthn
- **THEN** the system shows the add-passkey prompt with a message that the browser does not support passkeys
### Requirement: Passkey status display
The Journal home page SHALL show the user how many passkeys they have registered.
## ADDED Requirements
#### Scenario: User with passkeys
- **WHEN** a logged-in user visits the home page and has one or more passkeys
- **THEN** the page displays the passkey count (e.g., "2 passkeys registered")
### Requirement: Delete passkey
The Journal SHALL allow users to delete individual passkeys from account settings.
### Requirement: User profile page
Each user SHALL have a public profile page displaying their username and routes.
#### Scenario: Delete passkey
- **WHEN** a user deletes a passkey from account settings
- **THEN** the credential is removed from the database and can no longer be used for authentication
#### Scenario: View own profile
- **WHEN** a logged-in user navigates to their profile
- **THEN** they see their username, bio, and a list of their routes
#### Scenario: View other user's profile
- **WHEN** a user navigates to another user's profile URL
- **THEN** they see that user's username, bio, and public routes
### Requirement: Federated identity structure
User accounts SHALL follow the federated identity pattern (`@user@instance`) to prepare for ActivityPub federation in Phase 2.
#### Scenario: Username format
- **WHEN** a user registers with username "alice" on trails.cool
- **THEN** their full identity is stored as `@alice@trails.cool`
### Requirement: Session management
The Journal SHALL maintain authenticated sessions using secure HTTP-only cookies.
#### Scenario: Session persistence
- **WHEN** a logged-in user closes and reopens their browser
- **THEN** they remain logged in if the session has not expired
#### Scenario: Logout
- **WHEN** a user clicks "Log out"
- **THEN** their session is invalidated and they are redirected to the login page
### Requirement: No passwords
The Journal SHALL NOT support password-based authentication. All authentication is via passkeys or magic links.
#### Scenario: No password field
- **WHEN** a user views the registration or login page
- **THEN** there is no password field
### Requirement: Magic link login
The magic link login flow SHALL deliver the link via email in production instead of logging to console.
#### Scenario: Production email delivery
- **WHEN** a user requests a magic link in production
- **THEN** the link is emailed to the user (not just logged to console)
#### Scenario: Dev mode unchanged
- **WHEN** a user requests a magic link in development
- **THEN** the link is returned directly for auto-redirect (existing behavior preserved)
#### Scenario: Delete last passkey warning
- **WHEN** a user attempts to delete their only remaining passkey
- **THEN** a warning is shown explaining they will need to use magic links, and deletion proceeds after confirmation