diff --git a/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md b/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md
index 07f774cf..a4aa7818 100644
--- a/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md
+++ b/docs/content/docs/reference/PLAYER-SOURCE-BEHAVIOUR.md
@@ -24,6 +24,10 @@ need a station **ContentItem carrying a `Location`** (see
 `stations.ResolveContentItem`, which sets `type="stationurl"`). There is
 nothing for the speaker to resume from the source name alone.
 
+All three are confirmed on hardware: `RADIO_BROWSER` and
+`LOCAL_INTERNET_RADIO` by the stub described below, `TUNEIN` by its resume
+path playing the station as intended.
+
 `STORED_MUSIC` is a third case: one entry per media server, its
 `sourceAccount` being a server UDN. Selecting it identifies no track or
 container.
@@ -74,8 +78,9 @@ URL's `bmx.BuildOrionLocation`, but it also carries CLI URL playback, and any
 future audio-injecting feature would have to remember to stay clear of it.
 Opening Play URL does not depend on classifying what is in Recents.
 
-`ALEXA` is advertised `READY` too and is left alone, because whether a bare
-select resumes anything for it has not been verified.
+`ALEXA` is advertised `READY` too and is deliberately left alone: it cannot be
+tested on the hardware available, and guessing at its behaviour risks breaking
+a source that works today. The backstop below covers it instead.
 
 ### The backstop
 
diff --git a/pkg/service/soundtouchweb/static/js/components/Sources.js b/pkg/service/soundtouchweb/static/js/components/Sources.js
index 9c4bb468..595a7618 100644
--- a/pkg/service/soundtouchweb/static/js/components/Sources.js
+++ b/pkg/service/soundtouchweb/static/js/components/Sources.js
@@ -24,11 +24,15 @@ const SOURCE_READBACK_DELAYS_MS = [2000, 5000, 10000];
 // playing. The speaker then reports that stub indefinitely, so the player
 // shows a source the speaker is not actually playing.
 //
-// Verified against real hardware for RADIO_BROWSER and LOCAL_INTERNET_RADIO:
-// both produce the byte-identical stub. TUNEIN is listed because
-// ResolveContentItem treats it identically to RADIO_BROWSER (both need a
-// Location). ALEXA is also advertised READY but is NOT listed: whether a bare
-// select resumes anything for it is unverified, so it keeps today's behaviour.
+// Verified against real hardware: RADIO_BROWSER and LOCAL_INTERNET_RADIO both
+// produce the byte-identical stub, and resuming TUNEIN from its Recents plays
+// the station as intended.
+//
+// ALEXA is advertised READY as well but is deliberately NOT listed. It cannot
+// be tested on the hardware available, so listing it would mean guessing at
+// its behaviour, and guessing wrong would break a source that works today.
+// The stub check in isStubNowPlaying covers it instead: if a bare select does
+// strand it, that is reported as a failure rather than confirmed.
 //
 // `page` is the browser to open for the source: the page in this app that
 // produces content for it. `resume` says whether clicking may first replay