docs: the always-Private lock is a decision, and it unlocks at v1

Asked twice about a decision that has been settled since 2026-09-01, so this
is a documentation failure rather than a question worth answering a third
time.

The note was already there and it was accurate. It still didn't work, which is
the whole lesson: every sentence in it was descriptive. It said why the lock
exists and where the unlock lives, and not one sentence told the reader what to
DO when it looks like a defect. I read it, recognised it, and asked anyway —
because recognition is not instruction. It also pointed at TASK 36 for the
unlock while the creator's actual answer is v1, so it was confidently wrong on
top of being non-directive, which is worse than saying nothing.

Rewritten as a prohibition carrying its own trigger: verdict in imperative
voice, then the observations that make it look broken (privacy=private in the
diag line, the PRIVATE badge, recordFromStart/DVR on, no delete call in the
codebase) so recognition fires the instruction instead of prompting a question,
then the retired delete question with its verified answer.

Also: it belongs to v1, not TASK 36, and UpdateBroadcastMetadataAsync:112 is a
retrofit path, not the product change.

MyMistakes.md gets the transferable part, because the fix is not "write it
down" — it is "write decisions as prohibitions, not rationale, and treat a
repeated correction as a broken note rather than an impatient user".
TASKS.md gets it under 1.0 gates so it is a tracked deliverable, not prose.

ai.md

@@ -1717,6 +1717,28 @@ These are the hard facts behind every decision. Full list in `TASKS.md`.
   to subscribers and serve as post-mortem review tapes; bulk-delete pre-GA. The unlock is a
   deliberate final-pass item in **TASK 36 (gold pass)**, wired with the dialog selection — never
   opportunistic. The PRIVATE badge keeps showing when the stream is actually private.
+- **⛔⛔ STOP. The always-Private lock is a DECISION, not a bug, not drift, not an open question.
+  (Creator ruling, restated 2026-10-04 after being asked about it AGAIN.)**
+  `privacyStatus = "private"` hardcoded in `YouTubeStreamService.CreateBroadcast` is
+  **exactly right as written. Do not change it, do not "unlock" it, and — this is the part I keep
+  getting wrong — do not raise it as a question, an observation, a suggestion, or a
+  "heads-up".** The creator has now answered this more than once.
+  - **What it becomes:** the hardcoded lock is replaced by a real, user-selectable
+    visibility option in the Go-Live dialog — **at v1, not before.** Not at 1.0-candidate, not
+    at GA prep, not opportunistically during any other unit.
+  - **Why it exists:** pre-v1 test streams would otherwise publish VODs of a product still
+    breaking, in public, to subscribers. Private keeps those tapes usable for post-mortem review
+    while staying invisible to the channel's audience.
+  - **Do not let these look like symptoms of the one they resemble.** All are working as designed:
+    `privacy=private` in the broadcast diag line; the PRIVATE badge; `recordFromStart`/DVR ON;
+    and the absence of any delete call in the codebase (there is no delete feature, by design at
+    this stage — "can we delete the test VODs" is a *retired* question, answered 2026-10-04:
+    `videos.delete` accepts `youtube.force-ssl` which we already hold, private is a visibility
+    setting not a deletion lock, and anyway a broadcast that never reaches `live` never becomes a
+    VOD at all).
+  - **`CreateBroadcast:112` is not the unlock** — `UpdateBroadcastMetadataAsync` can already set
+    visibility post-hoc, but that is the retrofit path, not the product change. The product change
+    is the dialog option at v1.
 - **Full broadcast form (TASK 9 item 7) — RESCOPED 2026-09-01** — the core editable fields ship (since 2026-08-24) as the always-visible **Text drawer**: title, description, tags, visibility, made-for-kids, live-editable; scheduling ships as **TASK 34** (drawer ☑ Scheduled + adoption at Start). The old **Advanced tab is permanently out of product** (the 10% margin — see TASKS.md → "Out of product"): latency locked `low`, DVR/record-from-start locked on, embed/projection/CC/region fixed at sane defaults, invisible — every exposed field is a support ticket. `categoryId` is removed from `CreateBroadcast` (not a `liveBroadcast` field, silently ignored). Monetization enablement (if ever needed) rides the reward-events chain via `liveBroadcasts.update`, not a form field. Go-live order (TASK 9, shipped 2026-08-16):
   `BeginGoLive` → `PrepareAndStartLiveAsync` — ensure the reusable stream (`GetOrCreateReusableStreamAsync`,
   cache it), create the broadcast bound to it (`CreateBroadcast(..., stream.Id)` → `boundStreamId`),