trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Park mobile-activity-recording + mobile-nearby-sync under docs/ideas

Browse source 
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>
This commit is contained in:
Ullrich Schäfer 2026-04-19 08:23:44 +02:00
parent 29cbcef844
commit 621d91e14f
No known key found for this signature in database
GPG key ID: A32FF691A0F752D9
8 changed files with 82 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

2
openspec/changes/mobile-activity-recording/.openspec.yaml
View file

@ -1,2 +0,0 @@
schema: spec-driven
created: 2026-04-12

22
openspec/changes/mobile-activity-recording/proposal.md
View file

@ -1,22 +0,0 @@
## Why
The mobile app (when built) will show routes and allow editing, but won't record activities. Users want to track their rides/hikes with GPS, see live stats, and save recordings as Journal activities. This is a separate feature that depends on the mobile app foundation being in place first.
## What Changes
- GPS track recording via expo-location (foreground + background)
- Live stats overlay (distance, duration, speed, elevation gain)
- Save recorded track as GPX → Journal activity linked to the active route
- HealthKit (iOS) / Health Connect (Android) export
- Discard/pause/resume recording flow
## Capabilities
### New Capabilities
- `mobile-activity-recording`: GPS recording, live stats, save as activity, health platform export
## Impact
- Depends on `mobile-app` change being implemented first
- New dependencies: expo-location, expo-health
- Background location permissions needed (App Store privacy review)

45
openspec/changes/mobile-activity-recording/specs/mobile-activity-recording/spec.md
View file

@ -1,45 +0,0 @@
## ADDED Requirements
### Requirement: GPS track recording
The system SHALL record GPS tracks using the device's location services, supporting foreground and background recording.
#### Scenario: Start recording
- **WHEN** the user taps "Start Recording" from a route's map view
- **THEN** GPS tracking begins, the live stats overlay is shown, and track points are stored locally
#### Scenario: Background recording
- **WHEN** the user switches to another app or locks the screen during recording
- **THEN** GPS tracking continues in the background and track points are still recorded
#### Scenario: Stop recording
- **WHEN** the user taps "Stop Recording"
- **THEN** recording ends, track points are converted to GPX, and the user is prompted to save
### Requirement: Live stats display
The system SHALL show real-time statistics during an active recording.
#### Scenario: Stats overlay
- **WHEN** a recording is in progress
- **THEN** the screen displays: elapsed duration, distance covered, current speed, and elevation gain
### Requirement: Save as Journal activity
The system SHALL save completed recordings as activities on the user's Journal, linked to the active route.
#### Scenario: Save recording
- **WHEN** the user confirms saving after stopping a recording
- **THEN** the GPX track is uploaded to the Journal API as a new activity linked to the route, with distance, duration, and startedAt
#### Scenario: Discard recording
- **WHEN** the user discards a recording
- **THEN** the track data is deleted locally and no activity is created
### Requirement: HealthKit and Health Connect export
The system SHALL export recorded activities to Apple HealthKit (iOS) and Health Connect (Android).
#### Scenario: Export to health platform
- **WHEN** the user saves a recording and has granted health permissions
- **THEN** the activity (distance, duration, route, elevation) is written to HealthKit or Health Connect
#### Scenario: Health permissions not granted
- **WHEN** the user has not granted health permissions
- **THEN** the activity is saved to Journal without health export, and the user can grant permissions later from Profile

2
openspec/changes/mobile-nearby-sync/.openspec.yaml
View file

@ -1,2 +0,0 @@
schema: spec-driven
created: 2026-04-12

30
openspec/changes/mobile-nearby-sync/proposal.md
View file

@ -1,30 +0,0 @@
## Why
When bikepacking or hiking in a group, one person may update the route at the last café with WiFi. Once the group is in the middle of nowhere with no signal, the others are stuck with the old route. There's no way to share route updates between nearby devices without internet.
## What Changes
- **BLE route sync**: Devices discover each other via Bluetooth LE and transfer route data (waypoints + GPX geometry) directly. Uses react-native-ble-plx for cross-platform iOS ↔ Android compatibility.
- **QR waypoint sharing** (v1, simpler): Generate a QR code with compressed waypoint coordinates. The receiver scans it and gets the waypoints immediately — full route geometry recomputes when signal returns.
- **Sync protocol**: A lightweight protocol over BLE that handles discovery ("who nearby has this route?"), versioning ("is your copy newer than mine?"), and transfer (chunked GPX data).
## Capabilities
### New Capabilities
- `mobile-nearby-sync`: BLE-based route sync between nearby devices, QR waypoint sharing fallback
## Non-Goals
- Real-time collaborative editing over BLE (too complex — this is one-shot sync)
- Syncing activities or other data (routes only for v1)
- Mesh networking (direct device-to-device only, no relay through third devices)
## Impact
- Depends on `mobile-app` change being implemented first
- New dependency: react-native-ble-plx (requires Expo dev build)
- BLE background advertising needs careful battery management
- iOS requires Bluetooth usage description in Info.plist
- Android requires BLUETOOTH_SCAN, BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE permissions
## Future ideas
- TXQR (animated QR codes via camera) as an alternative transfer method — ~13KB/s demonstrated, no pairing needed, but requires porting the fountain code protocol to TypeScript

23
openspec/changes/mobile-nearby-sync/specs/mobile-nearby-sync/spec.md
View file

@ -1,23 +0,0 @@
## ADDED Requirements
### Requirement: BLE nearby route sync
The mobile app SHALL discover nearby devices via Bluetooth LE and transfer route data (waypoints + GPX geometry) directly between devices without internet connectivity.
#### Scenario: BLE device discovery
- **WHEN** a user enables nearby sync on the route detail screen
- **THEN** the app advertises via BLE and discovers other nearby devices that have the same route open
#### Scenario: Route transfer
- **WHEN** a nearby device with a newer version of the route is discovered
- **THEN** the user is prompted to accept the update and the route data is transferred via chunked BLE messages
#### Scenario: Version check before sync
- **WHEN** two devices discover each other via BLE
- **THEN** they exchange route version numbers and only the device with the older version is offered the update
### Requirement: QR waypoint sharing
The mobile app SHALL support sharing waypoint coordinates via QR code as a fallback when BLE is unavailable or impractical.
#### Scenario: QR waypoint sharing
- **WHEN** a user taps "Share via QR" on a route
- **THEN** a QR code is generated containing compressed waypoint coordinates that another device can scan to receive the waypoints