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>
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
## 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
|
|
|
|
#### Scenario: Public and unlisted route pages emit social-share metadata
|
|
- **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
|