docs(queue): six veggies, then the new work; scheduling and publishing retired
Creator ruling 2026-11-09: finish the queue before the new features, gold pass always last. **Retired (platform's surface, not ours):** - 34 scheduled streams — YouTube owns scheduling *and* the reminder that makes it worth anything. - 50 publish recording — Studio owns upload (resumable, quota-aware, explains rejections), and an in-app uploader would widen the OAuth consent to whole-channel video management for one convenience. The app adds "Show in folder" instead. **New tasks:** 65 replay clips (the creator-side buffer YouTube does not give you), 66 timed ticker messages, 67 per-event alert videos, 68 edit-while-live + first-run On-Air. **TASK 65 spec** is the interesting one: 15 s is a clip (10/15/20, default 15); the ring holds encrypted *encoded* fragments in RAM — raw 1080p frames would be ~7.4 GB for 15 s — so there is no steady disk write and no crash debris; F10 saves; the replay layer plays once then hides in Live and loops the last 1–3 elsewhere; silent by default; three kept; the layer is excluded from its own clip (hall of mirrors). **TASK 14 gains Branch 3:** mic input gain ahead of the gate (table boom mics fall under it), webcam blank hotkey, opacity/geometry parity with a collapsed Geometry disclosure, Show-in-folder. **Decisions recorded:** the replay-buffer reversal (it was retired in 2022-era reasoning as "different product"; the case for it won), the platform-surface rule, and voice triggering deferred — always- listening in a streaming app hears the game, so the content is its own false-positive source. Queue refactored to 56 lines by archiving completed rows and the superseded surge plan; HANDOFF at 40.
This commit is contained in:
+17
-3
@@ -219,6 +219,20 @@ Do not build these; each was explicitly ruled out.
|
||||
(<https://stackoverflow.com/questions/44346893/>), so no client-side moderation machinery is built on them.
|
||||
- Virtual camera output — a different product and a device-driver swamp; our output is one
|
||||
YouTube stream.
|
||||
- Replay buffer, stream clipping, multi-destination restreaming, an in-app bug reporter, and an
|
||||
advanced broadcast-form tab (latency/DVR/embed/projection/CC/region are fixed at sane defaults;
|
||||
every exposed field is a support ticket).
|
||||
- Multi-destination restreaming, an in-app bug reporter, and an advanced broadcast-form tab
|
||||
(latency/DVR/embed/projection/CC/region are fixed at sane defaults; every exposed field is a support
|
||||
ticket).
|
||||
- **Replay buffer — REVERSED 2026-11-09 (TASK 65).** It was out on "different product" grounds; the
|
||||
creator's case won: YouTube gives viewers clips but gives the creator no last-15-seconds buffer, so
|
||||
this is the app's surface, not the platform's. Scoped tightly: 10/15/20 s, RAM ring of encoded
|
||||
fragments (raw frames would be ~7.4 GB), three kept, silent by default.
|
||||
- **Do not rebuild the platform's own surface (2026-11-09).** Scheduling and publishing are retired for
|
||||
this reason: YouTube owns scheduled broadcasts *and* the reminder that gives them value, and Studio
|
||||
owns upload (resumable, quota-aware, explains rejections) — reimplementing either would be a worse
|
||||
copy that can fall out of sync. The app's edges are capture → scene → sound → output; everything past
|
||||
the file belongs to YouTube. Publishing would also widen the OAuth consent to whole-channel video
|
||||
management for one convenience.
|
||||
- **Voice triggering — deferred 2026-11-09.** Not a recognition-quality problem: an always-listening
|
||||
trigger in a streaming app hears the *game*, so the content is the false-positive source, and the
|
||||
consent cost is worse than the upload scope we refused. Windows Voice Access or a Stream Deck can
|
||||
send the keystroke; the app keeps F10.
|
||||
|
||||
Reference in New Issue
Block a user