diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index a8ad4f7..3463dca 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -619,18 +619,10 @@ Deferred deliberately, in rough priority order:
   the kit's roadmap, not here.
 - **Wear OS companion** ([#27](https://codeberg.org/jlmakiola/clockula/issues/27)):
   unscoped. A watch that shows and controls the phone's timers and next alarm
-  needs a phone-to-watch channel. The usual one is Google Play Services'
-  Wearable Data Layer (`play-services-wearable`), a proprietary service that
-  `docs/PRIVACY.md` §2 ("no analytics, tracking, advertising, crash-reporting
-  SDK or third-party service of any kind") and the F-Droid build rule out. A
-  channel of our own (a Bluetooth link run by both apps) would avoid it, at the
-  cost of building the transport. Today the ringing alarm and timer
-  notifications are foreground-service notifications, which Wear OS doesn't
-  bridge, so a watch doesn't get the ring. The options, if this is picked up:
-  - **Standalone watch app**: its own timers, stopwatch and alarms on the watch,
-    with no sync. No Play Services, but it doesn't control the phone, and there
-    is no F-Droid for watches, so it would ship through Play or sideloading.
-  - **Play-only companion**: the Data Layer confined to a Play Store flavour.
-    `PRIVACY.md` §2 would then need per-flavour statements.
-  - **Bridge the ring**: a separate, non-foreground notification for the ring
-    that Wear OS can bridge. A dismiss challenge would need a decision there.
+  needs a phone-to-watch channel, and the usual one, Google Play Services'
+  Wearable Data Layer, is a proprietary service that `docs/PRIVACY.md` and the
+  F-Droid build rule out. Any channel, ours or Google's, would also send data
+  off the phone, which the privacy policy currently says never happens. So
+  scoping this starts with a privacy decision, not with code. A standalone
+  watch app with its own timers and alarms and no sync avoids the question but
+  doesn't control the phone.