/decisions canary · 2026-05-09 · click-back rail test

Does sms:ray@raydata.co route to iMessage?

Testing whether iOS / macOS Messages handler accepts an email-based AppleID as a recipient. Result determines whether option 1 (pure URL scheme, no infra) or option 3 (Worker-fires-iMessage) is the click-back rail.

Tap one of the three options below from iPhone, then again from Mac. The expected behavior: Messages app opens with a pre-filled body, addressed to ray@raydata.co. If it does, send it. The iMessage will arrive at the Ray session and confirm the rail closes.

Tap one

Option A Works cleanly. Messages opened, recipient pre-filled, body pre-filled. Option B Messages opened but something was off (recipient blank, body missing, routed to SMS instead of iMessage, etc.). Option C Did nothing / errored / link not handled. (Pull this back to iMessage by hand and tell me what happened.)
What to test

iPhone first (Safari) — tap each option, observe what happens, send the one that works. Then Mac (Safari or Chrome) — same. The body field has clear discriminators (A / B / C) so the inbound iMessage tells me which platform succeeded.

If this works

Lock the rail. Next decision artifact is the GEO unblock-and-test call (Brief 1 + Brief 2 from last night's deep-research). Real options, real consequences, real click-back.

If it doesn't

Fall through to Worker-fires-iMessage: same buttons, but they POST to a Cloudflare Worker that fires an iMessage from RDCO infra to ray@raydata.co. Loop still closes through the existing inbound channel. More moving parts, same UX.