trails/openspec/CAPABILITIES.md
Ullrich Schäfer f1cae13605
openspec: archive the detail catch-up changes, sync specs
Archive the three implemented + merged changes (activity-sport-type,
activity-stats, journal-elevation-profile): their deltas are promoted into
openspec/specs/, the changes move to changes/archive/2026-06-12-*, and the
three new capabilities are added to the CAPABILITIES index.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-12 15:58:17 +02:00

7.5 KiB

Capabilities Index

Top-level index of every spec under openspec/specs/, grouped by area. Each spec describes a capability the platform exposes (or supports internally). Use this as the entry point when navigating the spec library — the alphabetical directory listing is fine for grep, but groupings make it easier to spot drift, overlap, and coverage gaps.

When adding a new spec, slot it into the most relevant group below and update this index in the same change. When merging or splitting specs, update both the directory and this index in the same change.

Identity & access

  • journal-auth — cookie session, terms-of-service consent gate (initial accept + re-accept on version bump).
  • authentication-methods — passkeys (WebAuthn), magic links, 6-digit codes, the method toggle on register/login forms.
  • security-hardening — cross-cutting hardening (CSP, headers, rate-limit-adjacent concerns).
  • rate-limiting — per-route rate-limit policy.

Profile & settings

  • profile-settings — display name, bio, profile-visibility editing UX.
  • account-management — email change with re-verification, account deletion (irreversible, cascades).
  • connected-services — third-party integrations (Wahoo today; Strava, Garmin later) connected from settings.
  • public-profiles/users/:username page (full vs. locked stub), open-graph metadata.

Social

  • social-follows — follow API, follower/following collections (with locked-account access rules), Pending request lifecycle, /feed.
  • activity-feed — the /feed aggregation behavior (note: also referenced from social-follows; this spec covers feed-specific concerns).
  • explore/explore page: paginated local user directory (public profiles only) ordered by recent public activity, plus an "Active recently" sub-section. Reachable to both signed-in users and anonymous visitors.

Notifications & realtime

  • notificationsnotifications table, four event types (follow_request_received / follow_request_approved / follow_received / activity_published), generation hooks, fan-out, /notifications page with cursor pagination, mark-read APIs, 90-day retention.
  • sse-broker/api/events endpoint, in-process pub/sub registry, client EventSource hook, Caddy passthrough. Transport-only; specific event payloads are owned by the capability that emits them (notifications today).

Routes (Planner core)

Routing engine

  • brouter-integration — BRouter container + routing-host election + the API the client expects.

Map / overlays

Imports & exports

  • gpx-import — GPX file parsing and route ingestion.
  • wahoo-import — Wahoo activity sync rules.
  • wahoo-route-push — pushing routes to Wahoo (POST on first push, PUT on re-push, stable external_id, push-status UI).

Journal landing & content

  • journal-landing — anonymous landing + signed-in personal dashboard.
  • activity-sport-type — sport/activity-type enum on activities (set on create or normalized on import), shown as a badge + feed verb, federated as a Note PropertyValue.
  • activity-stats — the canonical headline metric set + reusable stat row (sport-aware avg pace/speed, moving-vs-elapsed time) across feed, detail, and profile.
  • journal-elevation-profile — read-only elevation profile chart + chart↔map "active distance" hover/click sync on the route & activity detail pages.
  • legal-disclaimers — Terms / Privacy / Imprint pages.
  • transactional-emails — magic-link, welcome, etc. email templates.
  • demo-activity-bot — synthetic-content bot (Bruno by default) seeded for demo instances; configurable persona, retention, and seed region.

Infrastructure & ops

Conventions

  • Spec filenames use kebab-case capability names (profile-settings, social-follows, sse-broker).
  • Cross-spec references should link to the other spec's path rather than duplicate requirements (see public-profiles linking to social-follows for the followers/following list access rule, and account-management linking to journal-auth for the Terms gate).
  • New behavior lands through openspec/changes/<name>/ with a delta in specs/<capability>/spec.md. The delta is promoted to the top-level spec when the change is archived (via /opsx:archive).
  • Drift catch-up — i.e. updating a spec to match shipped code without changing behavior — can be edited directly without a change, since there's no behavioral payload to propose. Always update CAPABILITIES.md in the same edit if a spec is added, removed, or renamed.