ba6f09171d
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>
26 lines
1.7 KiB
Markdown
26 lines
1.7 KiB
Markdown
# 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
|
|
|