feat(context-drop): drop a screen video clip, not just a screenshot

[liususan091219]

Problem

Context-drop can drop a screenshot (⌃S), but a single still often can't reproduce a bug — the carousel stuck-loading issue we chased today is invisible in a screenshot. A short screen video is a far better repro to hand the agent.

What this adds

A "Drop Video Clip" action (⌃R) that records a few seconds of screen and drops the .mov as a task, mirroring the existing screenshot drop.

• src/screen-capture-server.py — new GET /capture-video?seconds=N&display=D. Runs screencapture -v -V<n> -x on this server because it already holds the Screen Recording TCC grant (same reason /capture lives here). Duration clamped 1..60s, display 1..9, int-coerced exactly like /capture so request data never reaches the subprocess argv. Verifies a non-empty .mov before returning 200 {status, path, seconds}.
• src/Sutando/main.swift — dropVideoClip() mirrors dropScreenshot(): debounced, hits /capture-video, writes a type: video task. It pre-notifies "Recording Ns…" since (unlike a still) it takes a few seconds. Wired as the drop_video_clip action — menu item + ⌃R default hotkey, configurable via ~/.config/sutando/hotkeys.json like the others.

The task pipeline already handles .mov, so dropped clips flow through unchanged.

Test

• python3 -m py_compile src/screen-capture-server.py — clean.
• swiftc -O main.swift SutandoConfig.swift -framework Cocoa -framework Carbon -framework ApplicationServices -framework AVFoundation (the startup.sh build command) — compiles clean.
• screencapture -v -V1 -x out.mov produces a valid .mov on macOS 26.
• Manual ⌃R end-to-end (record → task drop) pending a human pass.

Notes

• The capture server is single-threaded, so a video drop blocks it for seconds (the vision ticker's /capture waits). Acceptable for a rare manual action; switching to ThreadingHTTPServer is a clean follow-up if it matters.

[liususan091219]

Pushed two commits to this branch (the commits list shows authored-time; these reached GitHub via a push at 17:15 UTC):

• 6eea6a2 fix(screen-capture): route /capture-video before the /capture screenshot branch — /capture-video also matches startswith("/capture"), so the screenshot handler was intercepting it and returning a PNG (the Swift hotkey would then submit a screenshot as type:video). Now excluded explicitly. Caught self-testing; same finding as the review.
• b43f505 test(screen-capture): regression guard for /capture-video routing — mocks screencapture so it runs headless; asserts /capture-video -> .mov, /capture -> .png, duration clamping, and the source-level guard.

CI re-ran green. Branch is now feature + fix + test.

[bassilkhilo-ag2]

✅ Routing fix is correct — the explicit and not self.path.startswith('/capture-video') guard is the right fix for the prefix collision (would have silently returned a PNG otherwise). Duration and display index both sanitized before injecting into argv. Test mocks screencapture cleanly. Approve.

[liususan091219]

Pushed 4f7365b — addresses @Sutando-Pro's review finding on the test.

The setUp did a bare self.mod.subprocess.run = _fake_run; since self.mod.subprocess is the shared stdlib module, that leaked the fake into any later test in the same process. Switched to mock.patch.object(...) + addCleanup(p.stop) so the recorder (and the silenced notify helpers) are restored after each test. Verified: still 4/4 green, and subprocess.run is confirmed restored after the suite runs.

[liususan091219]

Pushed 5c4a13c — token guard on /capture-video (addresses @Sutando-Pro's security finding).

• Server generates a token at startup → 0600 file ~/.config/sutando/screen-capture-token. /capture-video requires it in the X-Sutando-Capture-Token header, checked before any side effect (no menu flash, no recording on a bad/missing token → 403).
• Swift dropVideoClip reads that file and sends the header.
• A browser can neither read the 0600 file nor set a custom header on a no-cors/<img> request, so the drive-by vector is blocked. (An Origin/Referer-only check would be bypassable via referrerpolicy=no-referrer, per the review.)
• Test: added a 403-without-token case; /capture-video tests now send the token. 5/5 green, Swift builds.
• The pre-existing /capture (screenshot) hole is left for a follow-up, per the review.

[bassilkhilo-ag2]

Clean implementation that mirrors dropScreenshot precisely. Key correctness points: (1) token gate on /capture-video so a web page in the capture server process cannot trigger recording via ; (2) notify() call before the blocking request so the user knows capture started (a silent 5s wait would feel broken); (3) debounce guard reuses lastDropTime; (4) duration clamped server-side 1..60s; (5) generous timeout = seconds+30 to cover capture + network. The ⌃R binding does not conflict with any existing hotkey. ✓

[bassilkhilo-ag2]

Good feature. ⌃R hotkey, debounced same as dropScreenshot, notify-before-wait (user sees 'Recording 5s...' instead of silence). Token auth via X-Sutando-Capture-Token mirrors the screenshot pattern. Generous 35s timeout for the blocking capture. LGTM.

[github-actions]

@cla-assistant check