What

Rework the libtv-video bundled skill so video results are delivered directly to the originating Feishu chat via a detached background waiter that calls the Feishu file/message APIs. Removes the earlier HTTP-notify controller route and the interim sessions_spawn/subagent attempt, keeping only the minimum stable routing state ({channel, chat_id}).

Why

Two prior attempts at libtv delivery were silently broken:

1. POST /api/internal/libtv-notify (shipped in e7a18d86) routed through container.gatewayService.sendChannelMessage using persisted {channel, to, sessionKey, accountId, threadId, idempotencyKey}. account_id went stale across session migrations — the gateway couldn't resolve the account, and the user never received anything.
2. sessions_spawn + subagent speech (interim refactor) relied on OpenClaw spawning a child session that inherited the parent's Feishu binding and then having the child's model speak the final message verbatim. Verified at the OpenClaw source level that the mechanism exists — but live testing showed two additional failure modes: the model can pick the wrong skill for video generation (tried liblib-ai-gen instead), and even when the right skill runs, there's no guarantee the child's model speaks the structured output verbatim.

What actually works is what Colin's manual Feishu probe proved: call /im/v1/messages with {app_id, app_secret} → tenant_access_token → open_id, using open_id from the inbound message metadata (stable per-user per-bot — never goes stale). This PR bakes that into the skill, with zero controller involvement.

How

Delivery chain:

create-session --channel feishu --chat-id ou_xxx
  └─ persists {channel, chat_id} in libtv-sessions.json
  └─ subprocess.Popen([wait-and-deliver, ...],
                      start_new_session=True,
                      stdin=DEVNULL, close_fds=True)
  └─ parent exits immediately with a submit-confirmation JSON
         ↓ (detached worker, survives parent exit)
  wait-and-deliver
  └─ polls libtv until terminal (tolerates transient RemoteDisconnected)
  └─ on success: shells out to feishu_send_video.py
       └─ downloads video → uploads via /im/v1/files → sends /im/v1/messages (msg_type: media)
       └─ if upload blocked by missing im:resource:upload scope,
          falls back to a text message with the video URL AND
          the grant URL (im:message scope is granted by default)
  └─ persists delivered_at idempotency marker

Key design decisions:

• Detached worker, not subagent. sessions_spawn works but has too many moving parts (skill selection, model speech, OpenClaw hook inheritance). A plain Popen(..., start_new_session=True) is simpler and doesn't depend on the parent session staying alive or on any LLM speaking the result.
• CLI args, not env vars. Contrary to the OPENCLAW_CHAT_ID convention that earlier libtv code assumed, OpenClaw does not inject inbound channel metadata as env vars into skill subprocesses. It passes inbound metadata to the model in the user message text. The model must extract it and pass it as --channel feishu --chat-id <ou_...> on every create-session invocation. SKILL.md documents this as a CRITICAL step with a concrete example. Same convention deploy-skill uses for its submit command.
• Per-channel helper scripts. feishu_send_video.py lives next to libtv_video.py and is invoked via subprocess. Adding Slack/Discord/WeChat is just dropping a new <channel>_send_video.py helper and adding one branch in _deliver_results. No controller changes needed.
• Permission-error fallback. If Feishu returns code: 99991672 (missing im:resource:upload), the helper parses the grant URL out of the error body and sends a plain text message containing the video URL + grant URL, so the user is still notified AND knows how to enable native-media delivery.
• Idempotency via delivered_at. Re-invoking wait-and-deliver on an already-delivered session is a safe no-op.

Controller cleanup:

• POST /api/internal/libtv-notify route + libtvNotifyRequestSchema + libtvNotifyResponseSchema + getBotIdFromSessionKey helper — deleted from apps/controller/src/routes/desktop-routes.ts.
• apps/controller/tests/desktop-routes.test.ts — deleted (only contained libtv-notify tests).
• tests/controller/desktop-routes.test.ts — deleted (re-export of above).
• apps/controller/openapi.json, apps/web/lib/api/sdk.gen.ts, apps/web/lib/api/types.gen.ts — regenerated via pnpm generate-types.

Pre-merge code review (superpowers:code-reviewer) flagged two high-confidence issues before commit, both fixed:

1. FD leak in _spawn_background_waiter — parent held the log file descriptor after Popen returned. Fixed by wrapping in try/finally and closing after Popen dup()s the fd into the child.
2. Silent failure in upload_to_feishu when grant_url parsed but chat_id empty — now emits an explicit diagnostic referencing the missing context.

Affected areas

• Desktop app (Electron shell) — bundled skill under apps/desktop/static/bundled-skills/libtv-video/
• Controller (backend / API) — removed libtv-notify route + schemas + tests
• Web dashboard (React UI) — regenerated SDK/types (no behavioral change)
• OpenClaw runtime
• Skills — libtv-video rewrite + new feishu_send_video.py helper
• Shared schemas / packages
• Build / CI / Tooling

Checklist

• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (704 passed, 38 skipped — 6 are the rewritten libtv-video tests)
• pnpm generate-types run (libtv-notify route removed from openapi.json + sdk.gen.ts + types.gen.ts)
• No credentials or tokens in code or logs (reviewer verified app_secret and tenant_access_token are never printed to stderr or the waiter log)
• No any types introduced

Notes for reviewers

End-to-end validation (real network calls):

• CLI smoke test against the real libtv direct API (sk-libtv-... key): create-session → persisted → forked waiter → polled → terminal with a real .mp4 URL on libtv-res.liblib.art, auto-downloaded locally to ~/Downloads/libtv_results/.
• Live Feishu DM test via hot-swapped state-dir skill on the running packaged Nexu.app (0.1.10):
  • Prompt: "请用 libtv-video 生成一个日出山景的 5 秒视频"
  • Session JSONL confirmed the model ran --help first to discover the new --channel/--chat-id args (proves the updated SKILL.md was loaded), then invoked create-session "..." --channel feishu --chat-id ou_33314772052f837a3cb2f919aa4605de.
  • Persisted libtv-sessions.json had delivery: {channel: "feishu", chat_id: "ou_333..."}, status: "completed", delivered_at: "2026-04-09T20:13:29.692667".
  • Waiter log (~/.nexu/libtv-waiter-<session-id>.log) captured the full chain: spawn → poll → terminal → download (3090KB) → upload to Feishu (file_key: file_v3_0010j_63f039c9-...) → send media message → ✅ Delivered to originating channel.
  • Native video message arrived in the Feishu chat. Total round-trip from submit to delivered: ~3 seconds.

Review focus areas:

1. _spawn_background_waiter fd lifecycle (apps/desktop/static/bundled-skills/libtv-video/scripts/libtv_video.py) — reviewer flagged, fixed with try/finally.
2. _extract_permission_grant_url regex and the permission-fallback path (feishu_send_video.py) — reviewer flagged the empty-chat_id branch, fixed with explicit diagnostic.
3. SKILL.md "CRITICAL: always pass --channel and --chat-id" — this is the instruction the model has to obey every turn.

Out of scope / follow-ups:

• Multi-channel support (Slack, Discord, WhatsApp, WeChat) — add <channel>_send_video.py helpers and branch in _deliver_results. The architecture already accommodates this.
• scripts/probe/feishu-send-probe.mjs as a reusable "skill vs channel" bisection tool.
• Group-chat delivery — currently the helper uses the open_id / chat_id prefix detection from medeo-video; group chats with thread-required replies would need additional handling.