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>

docs/ideas/mobile-activity-recording/.openspec.yaml

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

docs/ideas/mobile-activity-recording/README.md

@@ -0,0 +1,39 @@
+# 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)

docs/ideas/mobile-activity-recording/proposal.md

@@ -0,0 +1,22 @@
+## 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)

docs/ideas/mobile-activity-recording/specs/mobile-activity-recording/spec.md

@@ -0,0 +1,45 @@
+## 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

docs/ideas/mobile-nearby-sync/.openspec.yaml

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

docs/ideas/mobile-nearby-sync/README.md

@@ -0,0 +1,43 @@
+# mobile-nearby-sync (parked)
+
+OpenSpec change for sharing routes between nearby devices without internet
+(BLE-based peer sync + QR-code waypoint fallback) in the mobile app.
+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` landing first, and on there being
+enough users actually hiking/bikepacking together to justify the BLE
+complexity. At the current user count (3) this is engineering for a
+hypothetical group trip.
+
+## When to revive
+
+Revisit once **any** of these is true:
+
+- The mobile app is live and users start reporting "we were in a dead zone
+  and couldn't update the route"
+- A group / tour organiser asks specifically for peer-to-peer route sync
+- QR-code waypoint sharing alone (the simpler half of this spec) would
+  cover the need — worth shipping that first as a narrower change
+
+## Key constraints to remember
+
+- **Requires an Expo dev build** — `react-native-ble-plx` isn't available
+  in Expo Go.
+- **iOS + Android BLE APIs differ significantly**; expect platform-specific
+  bugs. Background BLE advertising has battery and OS-lifecycle caveats
+  (iOS suspends advertising when backgrounded after a grace period).
+- **Permissions sprawl**: iOS `NSBluetoothAlwaysUsageDescription`, Android
+  `BLUETOOTH_SCAN` + `BLUETOOTH_CONNECT` + `BLUETOOTH_ADVERTISE`, plus
+  location on older Android.
+- **QR waypoint sharing is an order of magnitude simpler** than BLE and
+  covers a big chunk of the use case — consider extracting that as a
+  separate, earlier change if the need becomes real.
+
+## What's in the folder
+
+- `proposal.md` — why / what / non-goals / impact / future ideas (TXQR)
+- `specs/` — delta specs (would land against a new `mobile-nearby-sync` capability)

docs/ideas/mobile-nearby-sync/proposal.md

@@ -0,0 +1,30 @@
+## 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

docs/ideas/mobile-nearby-sync/specs/mobile-nearby-sync/spec.md

@@ -0,0 +1,23 @@
+## 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