acb92b32fa
Outcome of today's `/spec-drift-review`. Concentrated on the high-and-medium-severity items; low-severity wording left for the next per-feature change to pick up naturally. High-severity URL fixes (specs were actively misleading): - account-management — email-change verification URL was specced as `/auth/verify-email-change?token=...`; the actual route is `/auth/verify?email-change=1&token=...` (see auth.verify.tsx:8). A reader implementing against the old wording would build a link that 404s. - observability — "Both apps SHALL expose a /metrics endpoint" was half right: the planner is at /metrics, but the journal exposes /api/metrics. The infrastructure spec already had the right URLs; the observability spec disagreed with itself. Now both correct, with a one-line note explaining the per-app split. Medium-severity wording drift (Stream E aftermath): - profile-settings, account-management, connected-services — all three said "the settings page SHALL include a [...] section", which described the old single-scrollable settings page. Stream E (PR #323) split /settings into four sub-pages (/settings/{profile,account,security,connections}); rewording each spec to point at its specific sub-page. The API endpoints (/api/settings/*) and behavior are unchanged. - authentication-methods — passkey add/delete previously said "via the settings page"; now specifically /settings/security. Code drift fixed inline: - apps/journal/app/routes/auth.verify.tsx — after a successful email change, the redirect was going to `/settings#account` (an anchor on the OLD single-scrollable settings page). Stream E retired that page; the right destination now is `/settings/account`. Without this the user would land on /settings/profile (which is what /settings redirects to) instead of the page that just changed. sse-broker spec wording: - The "no buffering tweaks in the Caddy reverse_proxy block" scenario asserted the entry was "a plain `reverse_proxy journal:3000`". After PR #329 the journal block has `lb_try_duration 30s` / `lb_try_interval 250ms` — neither affects streaming, so SSE still works, but the spec's "plain" language was no longer literally true. Reworded to forbid only buffering-related directives; explicitly call out that retry-on-restart directives like lb_try_duration are fine. Navbar consolidation (journal-landing): - The shipped navbar's full shape was scattered: notifications said "navbar has a bell," explore said "navbar has an Explore entry," but no spec described the avatar dropdown, the primary-nav cluster (Feed/Routes/Activities), or the mobile drawer (Stream C / PR #324). Added a "Top navbar shape" requirement to journal-landing covering all of it — anonymous vs signed-in, desktop vs mobile, dropdown contents, drawer behavior. The per-feature specs (notifications, explore) still own their own badges/entries; this requirement just says what the whole cluster looks like. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
32 lines
2.6 KiB
Markdown
32 lines
2.6 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 settings page at `/settings/profile`
|
|
The Journal SHALL expose a Profile settings page at `/settings/profile` (one of the four sub-pages of `/settings` — the bare `/settings` URL redirects here). The page SHALL let the signed-in user 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 settings page 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
|