diff --git a/HANDOFF.md b/HANDOFF.md index f9dcf77..832c7f9 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -2,7 +2,7 @@ ## State -- `main`, worktree clean. App work is pushed through `b265d42`; TASK 69 queue update is local only. +- `main`. App code is pushed through `b265d42`; queue-only docs commits are local. - **Done:** TASK 35 scene-linked audio, TASK 55 disk hygiene, TASK 65 replay clips, TASK 37 defaults/current split. - TASK 37: SQLite keeps an immutable default snapshot beside build-stamped current rows; App Settings can restore the staged scene or all scenes, offline only. Webcam identity survives both restore paths. @@ -12,7 +12,7 @@ ## Next action -- Queue: **40·A/C/D → Move → 9·5 → 14·16/17/18 → 66 → 67 → 68 → 69 → 36**. +- Queue: **40·A/C/D → Move → 9·5 → 14·16/17/18 → 66 → 67 → 68 → 69 → 70 → 36**. - Ask creator before TASK 68 about first-run ON-AIR default; before gold pass, settle the Release single-instance mutex behavior. - TASK 34 scheduling and TASK 50 recording publish are retired; YouTube owns those surfaces. diff --git a/TASKS.md b/TASKS.md index b4d14f6..f07bce3 100644 --- a/TASKS.md +++ b/TASKS.md @@ -9,7 +9,7 @@ **Creator ruling 2026-11-09 — finish the queue before the new features, gold pass always last.** -`40·A/C/D → Move → 9·5 → 14 (remaining slices) → 66 → 67 → 68 → 69 → 36` +`40·A/C/D → Move → 9·5 → 14 (remaining slices) → 66 → 67 → 68 → 69 → 70 → 36` The rule behind the two retirements below: **do not rebuild the platform's own surface.** Scheduling, publishing, moderation and channel management are YouTube's; the app owns capture → scene → sound → @@ -31,6 +31,7 @@ output. | 67 | ☐ | **Per-event alert videos** — a clip per monetization event, falling back to the default | [`task-67`](TASKS/task-67-per-event-alert-videos.md) | | 68 | ☐ | **Editing while live** + first-run On-Air state matching the 1-2-3 screen | [`task-68`](TASKS/task-68-edit-while-live.md) | | 69 | ☐ | **Chat sample-preview toggle** — per-layer control to show/hide mock chat in the preview; real messages unaffected, never output | [`task-69`](TASKS/task-69-chat-preview-toggle.md) | +| 70 | ☐ | **Window App layer** — capture one selected running app window as a visual layer over Live's game/display capture | [`task-70`](TASKS/task-70-window-app-layer.md) | | 36 | ☐ | **Gold pass** — the v1 gate: screens/layers audit (every control does something), native-Windows verification, branding-flash decision. Always the last unit | [`task-36`](TASKS/task-36-gold-pass.md) | | 34 | ❌ | **Scheduled streams — retired 2026-11-09.** YouTube owns scheduling *and* the reminder that makes it useful; the app neither creates nor displays scheduled broadcasts, and there is no value in a copy that can fall out of sync | [`decisions`](docs/ai/decisions.md) | | 50 | ❌ | **Publish recording — retired 2026-11-09.** YouTube Studio owns upload (resumable, quota-aware, and it explains rejections). In-app publishing would also widen the OAuth consent to whole-channel video management. The recording lands in the creator's folder; the app adds "Show in folder" instead | [`decisions`](docs/ai/decisions.md) | diff --git a/TASKS/task-70-window-app-layer.md b/TASKS/task-70-window-app-layer.md new file mode 100644 index 0000000..7167051 --- /dev/null +++ b/TASKS/task-70-window-app-layer.md @@ -0,0 +1,45 @@ +# TASK 70 — Window App layer + +**Status:** ☐ Queued (creator request 2026-11-11); scheduled after TASK 69 and before the gold pass. + +## Request and locked limits + +Add a **Window App** layer that captures a specific running app window and composites it above the +Live scene's game/display Background. Example: show a terminal over a game. This is an ordinary +foreground visual layer, not the existing TASK 38 **Capture Window…** action, which replaces the +locked Background itself. + +- Available in **Live only**. +- At most **one Window App layer** may be active in the layout. +- It cannot remove or mask the target from the underlying game/display capture. If the app is already + visible in those captured pixels, it may appear twice; do not select the game/already-captured app as + the overlay target. +- Visual only; no independent per-app audio capture or routing. +- Enumerate visible top-level windows of other processes. A process with several windows may offer + several titled entries; this selects a window, not every window owned by the process. + +## Capture boundaries + +- Target HWNDs are session-scoped. Never resurrect a raw HWND after restart: Windows can recycle it to + an unrelated window. The creator must select the window again for a new session. +- If the target closes, minimizes, suspends rendering, or cannot be captured, its image may freeze, + disappear, or go black; release the dead capture rather than leaving an apparently live layer. +- Secure/protected content may be returned black or excluded by Windows. This is an OS restriction, + not something LlamaCasty can bypass. + +## Acceptance + +- Add → Window App lists eligible windows and selection adds one Live-scene layer above the Background. +- The source updates while its target window is running, independent of whether another window covers it. +- The app refuses a second Window App layer and refuses adding this source outside Live. +- Target closure/failure is surfaced and releases the capture; restarting never reuses a saved HWND. +- One Good Dog integration test drives a fake capture source/enumerator. A real Windows visual check is + required before commit. + +## Reference scan + +- Windows Graphics Capture exposes HWND-targeted items via + [`IGraphicsCaptureItemInterop::CreateForWindow`](https://learn.microsoft.com/en-us/windows/win32/api/windows.graphics.capture.interop/nf-windows.graphics.capture.interop-igraphicscaptureiteminterop-createforwindow). +- OBS's [Window Capture source](https://obsproject.com/kb/window-capture-sources) confirms the intended + foreground-source behavior; Windows documents that protected windows may be black or omitted in + [New Ways to do Screen Capture](https://blogs.windows.com/windowsdeveloper/2019/09/16/new-ways-to-do-screen-capture/).