trails/openspec/specs/public-profiles/spec.md
Ullrich Schäfer ba6f09171d Archive public-content-visibility
Final tasks ticked post-merge:
- 10.2: verified on prod that journal.routes + journal.activities still
  default to 'private' NOT NULL, with the only public rows being the
  15-each demo-bot seeded content
- 10.3: demo-activity-bot already inserts with visibility='public'
  directly in demo-bot.server.ts

Syncs the three delta specs into main:
  + activity-feed: 2 added, 1 modified
  + public-profiles: new spec (1 added)
  + route-management: 2 added, 1 modified

Moves change to openspec/changes/archive/2026-04-24-public-content-visibility.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-24 21:57:21 +02:00

1.7 KiB

public-profiles Specification

Purpose

TBD - created by archiving change public-content-visibility. Update Purpose after archive.

Requirements

Requirement: Public profile page

The Journal SHALL serve a public profile page at /users/:username that lists the user's public routes and activities in reverse chronological order, viewable without authentication.

Scenario: Logged-out visitor views a profile with public content

  • WHEN an unauthenticated visitor navigates to /users/:username for a user with at least one public route or activity
  • THEN the page renders that user's display name (falling back to username), the @username@domain handle, and a reverse-chronological list of their public routes and public activities
  • AND items marked unlisted or private do NOT appear in the list

Scenario: Profile 404 when there is no public content

  • WHEN a visitor navigates to /users/:username for a user whose content is all private or unlisted, or for a username that does not exist
  • THEN the server responds with HTTP 404
  • AND the response does NOT distinguish the two cases, so existence of a private-only account is not leaked

Scenario: Owner sees their own profile

  • WHEN a user navigates to their own /users/:username while logged in
  • THEN the page renders exactly the same as for a logged-out visitor, plus a small owner-only control strip linking to settings

Scenario: Profile page emits social-share metadata

  • WHEN any visitor loads a populated /users/:username
  • THEN the page emits Open Graph tags (og:title, og:site_name, og:type="profile") so links shared on social platforms render a meaningful preview