trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trails/docs/ideas/mobile-activity-recording
History
Ullrich Schäfer 621d91e14f
Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 
Both are blocked on the mobile-app foundation and on a user base that
actually records activities or needs offline peer sync. With 3 users
and 0 activities on prod today, these are engineering for a
hypothetical population.

Move the artifact sets out of openspec/changes/ (so openspec list
stays clean) and under docs/ideas/ where self-host-overpass already
lives. Each gets a short README documenting:

- current parked status
- revive triggers (when should we look at this again?)
- key constraints not to rediscover (background-GPS privacy review;
  BLE dev-build requirement; QR-only subset as a cheaper path)

Reviving is `git mv docs/ideas/<name> openspec/changes/<name>` and
running /opsx:apply, same pattern as self-host-overpass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 08:23:44 +02:00
..
specs/mobile-activity-recording Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
.openspec.yaml Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
proposal.md Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
README.md Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00

README.md

mobile-activity-recording (parked)

OpenSpec change for recording GPS activities on-device in the mobile app (ride/hike tracking, live stats, save as Journal activity, HealthKit / Health Connect export). Moved here from openspec/changes/ so it does not clutter the active change list; revive by moving the directory back under openspec/changes/ when ready to implement.

Status

Parked. Blocked on mobile-app (the foundation change) landing first, and on there being enough Journal users actually logging activities to justify the native-recording complexity. At the current user count (3) and activity count (0), shipping this would be writing code for nobody.

When to revive

Revisit once any of these is true:

  • The mobile app is live and users are asking to record from the phone instead of importing from Wahoo/Garmin/Komoot later
  • The web Journal has a meaningful stream of imported activities, so the feature lands into an existing behaviour rather than inventing one
  • A specific user request justifies the iOS/Android background-location privacy review (App Store's bar for background GPS is high)

Key constraints to remember

  • Background GPS requires explicit user consent + justification on iOS and Android. App Store privacy review will scrutinise this.
  • Dependencies: expo-location for the track, plus expo-health (or equivalent) for HealthKit / Health Connect integration.
  • Battery: continuous GPS at high accuracy is a power-hungry path; recording UI needs clear on/off state and resumption.

What's in the folder

  • proposal.md — why / what / impact
  • specs/ — delta specs (would land against a new mobile-activity-recording capability)