task 50: correct mechanism — creator's channel proves stream never lands

TASKS/task-50-publish-recording.md

@@ -19,9 +19,9 @@ Two reasons, and the second is the one that actually justifies it.
 
 **1. It fixes a defect the creator already reported as broken.** On 2026-09-26 the creator could
 not get private test recordings saved to YouTube, and used the local recording as the proof of
-concept instead. The mechanism is now understood (§ Mechanism below): the archive *is* created,
-the app just offers no way to see or reach it. A deliberate upload is the actual fix; the current
-behaviour is a side-effect nobody designed.
+concept instead. The mechanism is now understood and CONFIRMED empirically (creator inspected the
+channel 2026-09-28: 20+ private videos, all content-less placeholders). A deliberate upload is
+the actual fix; the current behaviour is a side-effect nobody designed.
 
 **2. It is not the heavy feature it looks like.** The instinct is to call upload a big risky
 addition because it moves bytes. It doesn't: ffmpeg already moves the media, and the recording
@@ -34,20 +34,35 @@ different failure model. That is the whole cost.
 
 ---
 
-## Mechanism — why recordings already reach YouTube, and why that's a problem
+## Mechanism — CORRECTED 2026-09-28 (creator's channel inspection disproved the earlier model)
 
-Verified 2026-09-28 against the code:
+Verified against the code AND against the creator's channel:
 
-- `enableAutomaticArchiving` is **never set** by the app. YouTube's default for
-  `liveBroadcasts.insert` is `true`, so **every** broadcast the app creates is archived as a VOD
-  when it ends.
+- `liveBroadcasts.insert` creates a **placeholder video** on the channel for every broadcast the
+  app makes — that is the source of the 20+ private videos. The creator confirmed 2026-09-28:
+  a couple dozen+ private videos, all **scheduled placeholders with NO content**.
+- Content arrives only if the stream is actually pushed and archived: broadcast reaches **LIVE**
+  (`liveBroadcasts/transition`), ffmpeg pushes RTMP to the bound stream key, and the broadcast
+  ends long enough to be transcoded. Content-less placeholders mean **the stream never lands** —
+  one of those three steps fails in practice.
+- `enableAutomaticArchiving` is **never set** by the app, so YouTube's `true` default applies.
 - Broadcasts are inserted with `privacyStatus = "private"`
   (`Services/YouTubeStreamService.cs:49`), so those orphans are not public. That is correct and
   must stay.
 - The app has **no delete path** — nothing in `Services/` deletes a broadcast or a video. The
   creator clears each orphan by hand in Studio.
 
-So "dev mode deletes the video immediately" is a **manual Studio step today**, not app behaviour.
+**Consequence for the original 2026-09-26 complaint:** it was correct. The private recordings
+never saved to YouTube because **no video content was ever produced on the channel** — not
+because the app couldn't reach a VOD that existed. The upload pipeline (broadcast → LIVE → RTMP
+push → archive) fails; only broadcast creation succeeds.
+
+### The one diagnostic question to answer before this task is scoped
+
+During a real test stream, does ffmpeg actually reach `a.rtmp.youtube.com`, and does the
+broadcast reach the LIVE state? If the encoder never starts or the transition never fires, that
+is the observed bug — and it is worth a fix BEFORE any publish feature, because this task's
+premise ("the recording can get to YouTube") depends on it.
 
 ### Sequencing constraint — do not flip the flag early