DEV Community

咻咻咻
咻咻咻

Posted on

Fail closed on captive Wi-Fi portals, Bluetooth pairing, and turn-by-turn navigation

When narrative content drives a physical actuator, three interrupt paths look like "just restore state" until they are not: a captive portal / Wi-Fi sign-in / no-internet interstitial mid-session, a Bluetooth pairing request / pairing PIN / accessory-connect confirmation, and turn-by-turn navigation / Maps guidance. Each needs a default that fails closed — toward idle, toward re-arm only after a named beat, toward interrupt-clear ≠ motor authority.

on captive_portal_or_wifi_signin_opened():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on portal_dismissed_or_finished():
        # network-login UI gone ≠ motor envelope restored
        await user_resume(); await next_named_beat(); arm()

on bluetooth_pairing_request_or_pin_opened():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on pairing_ui_dismissed_or_completed():
        # pairing dialog cleared ≠ motor authority
        await user_resume(); await next_named_beat(); arm()

on turn_by_turn_navigation_or_guidance_opened():
    ramp_to(IDLE, at=next_beat_boundary)
    armed = false
    on guidance_ended():
        # navigation UI gone ≠ previous intensity restored
        await user_resume(); await next_named_beat(); arm()
Enter fullscreen mode Exit fullscreen mode

The captive-portal rule is easy to mix up with a VPN / Private Relay path change, Airplane Mode, and an in-app browser. VPN / Private Relay is a path change on an already-authorized network. Airplane Mode is a radio cut. An in-app browser is a web view the controlling app opened. A captive portal is a network-login sheet. Finishing it clears that sheet; it must not restore motor authority.

The Bluetooth pairing-request rule sits next to — but is not — a Bluetooth audio-route change, an AirDrop receive, a watch companion remote, or USB tethering. Audio-route change is an already-paired headset connecting, disconnecting, or flipping to speaker. AirDrop is a receive path. A watch remote is a companion control. USB tethering is a hotspot or cable share. A pairing request is a pairing dialog. Dismiss only clears that dialog; it must not restore motor authority.

The turn-by-turn rule is an ongoing navigation-guidance surface, not CarPlay / Android Auto, not a voice-assistant takeover, not Notification Center, and not a Live Activity / Dynamic Island. CarPlay is projection. A voice assistant takes over the session. Notification Center is a shade of alerts. Live Activity is a phone-side glance. Turn-by-turn is guidance. Ending it only clears that guidance; it must not restore motor authority.

Buyers can test all three without code: join a guest or hotel Wi-Fi mid-session and see whether finishing the sign-in page restarts intensity, trigger a Bluetooth pairing request then dismiss it, and start Maps turn-by-turn then end the guidance. These map to questions like "how do AI stories control physical devices" and "Lovense alternative with AI stories."

This is the model CRAVE AI uses for story-controlled play on official devices: AI story-controlled vibrator. Principle write-up: narrative-to-device sync. Devices: AI sex toys.

Disclosure: I work on CRAVE AI. Adults-only product; no explicit content here.

Top comments (0)