dcbd703f47
Two stacked OpenSpec change proposals for a demoable social layer,
with scope deliberately minimal ("enough to send a URL and have it
open to real-looking content without signup"):
1. public-content-visibility
- Adds visibility enum {private, unlisted, public} on routes +
activities, defaulting to private for every existing row.
- Detail pages (/routes/:id, /activities/:id) become accessible to
logged-out visitors when content is public or unlisted; private
→ 404 (not 403) to avoid existence leaks.
- Broadens /users/:username into a public profile listing only
public routes + activities; 404s when there's no public content
to prevent account enumeration.
- Open Graph / Twitter Card meta on public detail + profile pages.
- Visibility selector in the owner's edit flow.
- Out of scope: follow/follower, cross-user feed, reactions,
federation.
2. demo-activity-bot (depends on #1)
- A single bot user, Bruno the trail dog, seeded on worker startup
when DEMO_BOT_ENABLED=true. Reserved username, sentinel email,
no credentials.
- pg-boss recurring job fires every 90 min, decides-to-walk with
p=0.12 during 07:00-21:00 local, yielding ~2-3 walks/day at
organic times.
- Each walk: random start + end within inner-Berlin bbox, trekking
only (dogs don't ride bikes), 2-12 km crow. BRouter plans the
route; the route GPX is also attached as the activity's trace.
- Everything inserted with visibility=public, synthetic=true.
- Daily prune deletes synthetic rows > DEMO_BOT_RETENTION_DAYS old
(default 14). Hard cap of 40 items/14d protects against runaway
growth.
- Small "🐕 demo account" badge on /users/bruno for honesty.
Both changes are artifacts only — no code lands with this PR. Apply
in order after merge: public-content-visibility first, then
demo-activity-bot.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
48 lines
2.8 KiB
Markdown
48 lines
2.8 KiB
Markdown
## MODIFIED Requirements
|
|
|
|
### Requirement: Activity detail page
|
|
The Journal SHALL display an activity detail page with map, stats, and description. Access depends on the activity's `visibility`: `public` activities are viewable by anyone including unauthenticated visitors, `unlisted` activities are viewable by anyone who has the URL, and `private` activities are viewable only by the owner.
|
|
|
|
#### Scenario: Owner views own activity
|
|
- **WHEN** a logged-in user navigates to an activity they own at any visibility
|
|
- **THEN** they see the activity name, description, a map with the GPS trace, distance, duration, and elevation stats
|
|
|
|
#### Scenario: Anyone views a public activity
|
|
- **WHEN** any visitor (including unauthenticated) navigates to a `public` activity's URL
|
|
- **THEN** they see the full activity detail page as above
|
|
|
|
#### Scenario: Anyone with the URL views an unlisted activity
|
|
- **WHEN** any visitor navigates directly to an `unlisted` activity's URL
|
|
- **THEN** they see the full activity detail page as above
|
|
|
|
#### Scenario: Non-owner is blocked from a private activity
|
|
- **WHEN** a visitor who is not the owner requests a `private` activity URL
|
|
- **THEN** the server responds with HTTP 404 (not 403), so the existence of the private activity is not leaked
|
|
|
|
#### Scenario: Public and unlisted activity pages emit social-share metadata
|
|
- **WHEN** a visitor loads a `public` or `unlisted` activity detail page
|
|
- **THEN** the response emits Open Graph and Twitter Card meta tags (`og:title`, `og:description`, `og:type="article"`, `og:site_name`, `twitter:card="summary"`)
|
|
|
|
## ADDED Requirements
|
|
|
|
### Requirement: Activity visibility
|
|
The Journal SHALL persist a `visibility` value on every activity and SHALL allow the owner to change it.
|
|
|
|
#### Scenario: New activities default to private
|
|
- **WHEN** an activity is created without an explicit visibility
|
|
- **THEN** the activity row is persisted with `visibility = 'private'`
|
|
|
|
#### Scenario: Owner changes an activity's visibility
|
|
- **WHEN** an activity owner selects a different visibility (`private`, `unlisted`, `public`) and saves
|
|
- **THEN** the stored visibility is updated and subsequent access checks use the new value immediately
|
|
|
|
### Requirement: Activity listings respect visibility
|
|
The Journal's own-activities feed SHALL show the owner everything regardless of visibility, while any cross-user listing SHALL only include activities with `visibility = 'public'`.
|
|
|
|
#### Scenario: Own activity feed is unchanged
|
|
- **WHEN** a logged-in user views their own activity feed
|
|
- **THEN** the feed includes all of their own activities regardless of visibility
|
|
|
|
#### Scenario: Public profile lists only public activities
|
|
- **WHEN** a visitor loads `/users/:username`
|
|
- **THEN** the rendered list of activities includes only the user's `public` activities; `unlisted` and `private` activities are omitted
|