trails/openspec/changes/public-content-visibility/specs/route-management/spec.md at dcbd703f4767230e840672be09acb30ee352a9ee

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.9 KiB

Raw Blame History

MODIFIED Requirements

Requirement: View route

The Journal SHALL display route details including map, metadata, and elevation stats. Access depends on the route's visibility: public routes are viewable by anyone including unauthenticated visitors, unlisted routes are viewable by anyone who has the URL, and private routes are viewable only by the owner.

Scenario: Owner views own route

WHEN a logged-in user navigates to a route they own at any visibility
THEN they see the route name, description, a map with the route polyline, distance, and elevation gain/loss

Scenario: Anyone views a public route

WHEN any visitor (including unauthenticated) navigates to a public route's URL
THEN they see the full route detail page as above

Scenario: Anyone with the URL views an unlisted route

WHEN any visitor navigates directly to an unlisted route's URL
THEN they see the full route detail page as above

Scenario: Non-owner is blocked from a private route

WHEN a visitor who is not the owner requests a private route URL
THEN the server responds with HTTP 404 (not 403), so the existence of the private route is not leaked

WHEN a visitor loads a public or unlisted route 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: Route visibility

The Journal SHALL persist a visibility value on every route and SHALL allow the owner to change it.

Scenario: New routes default to private

WHEN a route is created without an explicit visibility
THEN the route row is persisted with visibility = 'private'

Scenario: Owner changes a route's visibility

WHEN a route owner selects a different visibility (private, unlisted, public) in the edit flow and saves
THEN the stored visibility is updated and subsequent access checks use the new value immediately

Scenario: Non-owner cannot change visibility

WHEN a request to update visibility arrives from a user who is not the route owner
THEN the server rejects it with HTTP 403 or 404 (matching the current update-route behaviour), and the stored value is unchanged

Requirement: Route listings respect visibility

Any listing that exposes routes beyond the owner's own dashboard SHALL only include routes with visibility = 'public'.

Scenario: Public profile lists only public routes

WHEN a visitor loads /users/:username
THEN the rendered list of routes includes only the user's public routes; unlisted and private routes are omitted

Scenario: Owner's own routes list is unchanged

WHEN a logged-in user views their own routes list at /routes
THEN the list includes all of their own routes regardless of visibility

2.9 KiB Raw Blame History