trails/openspec/changes/public-content-visibility/specs/activity-feed/spec.md at fc4485f6efed00d431a9f64c5f330c12755244bf

Ullrich Schäfer dcbd703f47

Propose social MVP: public-content-visibility + demo-activity-bot

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>

2026-04-19 08:49:59 +02:00

2.8 KiB

Raw Blame History

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

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

2.8 KiB Raw Blame History