37073eafd7
Drift (specs aligned to shipped code): - social-follows: locked-account access rule for /users/:u/followers and /users/:u/following (owner + accepted-follower see; non-followers of private get 404). Adds the follow→notification lifecycle requirement. Fills the placeholder Purpose. - public-profiles: counts degrade to plain text (not anchors) for viewers who can't see the lists. Cross-references social-follows. Fills the placeholder Purpose. - journal-auth slimmed to cookie session + Terms gate. Auth methods moved out (see authentication-methods). Splits: - account-settings (14-line stub) deleted, content split into: - profile-settings (display name, bio, profile_visibility) - account-management (email change with verification, account deletion) - connected-services (Wahoo + future external integrations) - authentication-methods split out of journal-auth: passkeys (register/login/add/delete), magic links, 6-digit codes (login + register), method toggle on register/login forms, dev-console fallback. New specs: - sse-broker: /api/events, in-process broker, useUnreadNotifications hook, Caddy passthrough, multi-process forward-compat contract. Archived: notifications change → openspec/changes/archive/2026-04-26-notifications. Promoted the four delta spec files into top-level specs: - specs/notifications/ (new capability) - specs/activity-feed/ (added: public activity fan-out) - specs/journal-landing/ (added: Notifications navbar entry) - specs/social-follows/ (added: follow→notification lifecycle) Added openspec/CAPABILITIES.md grouped index covering all 40 specs with a Conventions section explaining cross-references, naming, and the catch-up-vs-change rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
32 lines
2.5 KiB
Markdown
32 lines
2.5 KiB
Markdown
# profile-settings Specification
|
|
|
|
## Purpose
|
|
The user-facing profile editing surface — display name, bio, and `profile_visibility` — exposed through the Journal's settings page. The locked-account semantics that `profile_visibility` controls live in `public-profiles` and `social-follows`; this spec only covers the editing UX and API.
|
|
|
|
## Requirements
|
|
|
|
### Requirement: Profile section on the settings page
|
|
The settings page SHALL include a "Profile" section where the signed-in user can edit their display name, bio, and profile visibility, and save the changes through `POST /api/settings/profile`. Save SHALL be optimistic via a fetcher; success SHALL be confirmed with a visible "Profile saved." line and the form SHALL re-render with the persisted values.
|
|
|
|
#### Scenario: Edit display name and bio
|
|
- **WHEN** a signed-in user changes the display name and/or bio fields and clicks Save
|
|
- **THEN** the API persists the new values on `users.display_name` / `users.bio` and the page renders "Profile saved." and the new values
|
|
|
|
#### Scenario: Validation error renders inline
|
|
- **WHEN** the API rejects the submission (e.g. display name too long)
|
|
- **THEN** the form renders the error inline and the values are not persisted
|
|
|
|
### Requirement: Profile visibility toggle
|
|
The Profile section SHALL include a `profileVisibility` radio group with `public` and `private` options. New accounts default to `private` (locked-account model). Changing the value and saving SHALL update `users.profile_visibility` and take effect on the next page render across the site (counts, profile-route gating, follow-button state).
|
|
|
|
#### Scenario: Toggle to private
|
|
- **WHEN** a public-profile user selects "private" and saves
|
|
- **THEN** `users.profile_visibility` is set to `private`; subsequent visitors to the profile see the locked stub per `public-profiles`; existing accepted follows are unaffected; new follow requests land Pending
|
|
|
|
#### Scenario: Toggle to public
|
|
- **WHEN** a private-profile user selects "public" and saves
|
|
- **THEN** `users.profile_visibility` is set to `public`; future incoming follows auto-accept; previously-Pending follows remain Pending until explicitly approved or rejected
|
|
|
|
#### Scenario: Radio is targeted by name + value, not label text
|
|
- **WHEN** end-to-end tests interact with the visibility radio
|
|
- **THEN** the test selector is `input[type=radio][name=profileVisibility][value=public|private]`, because the help-text label of one radio mentions the other's word and a label-based selector would collide
|