Ullrich Schäfer acb92b32fa Spec drift catch-up: URLs, settings split, navbar shape

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>

2026-04-26 21:19:02 +02:00

2.6 KiB

Raw Blame History

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

2.6 KiB Raw Blame History