Ullrich Schäfer 37073eafd7 Spec catchup: drift fixes, account-settings split, notifications archive

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>

2026-04-26 02:02:43 +02:00

2.5 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 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

2.5 KiB Raw Blame History