Alarms: the 5/MG strap-alarm warning points to 'Settings, Experimental', but the switch is Test Centre → Protocol probes (and a 5.0 fire is now reported) #2464

What

On a WHOOP 5/MG, the Alarms screen tells the wearer the strap alarm needs a setting that no longer exists where it says, under a name it no longer has.

// Strand/Screens/SmartAlarmView.swift:281
Text("Your WHOOP 5/MG won't arm this until Experimental mode is on (Settings, Experimental). …")

The flag the arm actually checks is PuffinExperiment.isEnabled (noopPuffinExperiments, Strand/BLE/BLEManager.swift:5231-5236). Its toggle is now:

More → Test Centre → "5/MG PROTOCOL DIAGNOSTICS" → "Protocol probes" (Strand/Screens/TestCentreView.swift:259, shown only when the selected model is 5/MG, :170).

Three separate things stop a wearer from getting there:

1. Wrong location. There is no "Experimental" setting in Settings that controls this. The old Settings card (fiveMGCard, Strand/Screens/SettingsView.swift:2076) is no longer rendered — its own blurb says its controls "now live in Test Centre", a sentence nobody sees because the card is not shown.
2. Different name. The warning says "Experimental mode"; the toggle is "Protocol probes".
3. The toggle does not say it arms the alarm. Its description is "Sends experimental protocol queries and records the replies in the strap log." Nothing on it mentions alarms, so a wearer looking at it has no reason to think it is the one.

Observed on iPhone, 11.8.0 (400), WHOOP 5.0: with most experimental options enabled, the strap alarm never vibrated — the phone's backup notification did. The wearer could not find the setting from the warning's directions.

New evidence: a strap-driven wake on a WHOOP 5.0

After turning on Protocol probes from the location above, the same wearer's strap alarm vibrated at the set time. This is a WHOOP 5.0; the capture posted on #864 (2026-08-25) was a 5/MG (WS50_r00, FW 50.41.1.0). Firmware for this 5.0 was not recorded, and no strap log was captured for this fire — stated so the claim is not read as more than it is: an on-wrist buzz at the armed time, reported by the wearer.

Taken with the MG capture, that is two independent reports of the rev-4 alarm firing on 5-series hardware, while the code and UI still describe it as never observed:

// Strand/BLE/BLEManager.swift:5218-5221
/// … a strap-driven wake fire has NOT been captured on our side (no STRAP_DRIVEN_ALARM_EXECUTED
/// event observed yet) — do not present the 5/MG alarm as guaranteed until one is.

Suggested fix

• Point the warning at the real control, ideally as a direct link into Test Centre rather than a path in prose.
• Say what the toggle gates. Add to "Protocol probes" that it also arms the strap's firmware alarm on 5/MG.
• Revisit the gate itself. With fires reported on both an MG and a 5.0, it may be worth separating the alarm from the protocol probes — the probes also send experimental queries on every connect, which a wearer who only wants their alarm has no reason to accept. That is a maintainer decision; the first two items stand on their own.
• The comment above armStrapAlarm, and the "still unconfirmed on 5/MG" copy shown to Experimental-on wearers (SmartAlarmView.swift:285-289), no longer match the evidence.

Platform parity

The code comment at SmartAlarmView.swift:277-278 says the wording mirrors Android's SmartAlarmScreen StrapAlarmCard exactly, so Android likely carries the same pointer; not checked on an Android device.

Related

Part of a broader pattern of settings that change what a wearer gets but are hard to find or don't say what they affect — filed separately.