[DoodleBears]

Refs #1023 · Task claim · Provider dsh-im#31 · Agent-Task: codex/local/01a13902-0d72-7872-ac0f-440e152155d5

Why the change

Show a checked Lark parent video in its existing Channel request bubble so a Human can explicitly prepare and manually play the original without changing Bot attention or source authority.

Special things to note

• Merge risk: two-way door — revert the video projection/player and development Provider pin, retaining Source Events and acquired Attachments; medium blast radius — shared Messaging intake, Channel media serving and Client wire parsing, where stale association or unauthorized cached access is the main risk. Review exact parent/cover association, capability negotiation, independent authorization paths and cancellation. No schema migration, permission expansion, publication or deployment.
• Draft and partial Bridge tracer: Lark audio and video playback in Channel bubbles #1023 tracer. Native Lark playback/download, installed-product E2E, matched light/dark screenshots/recording and first-slice Human QA are pending. Audio/direct native media are not delivered. Product Provider provenance remains unchanged; only the development launcher selects the exact Provider candidate.
• Provider: 779 tests passed, five existing Windows POSIX-fixture skips; build/package check passed. Core media: all 17 passed serially, and the final video Client file passed 12 tests. Broader runs retained an existing image-case timeout (89/90 passed) and an existing attachment wrong-source/cleanup timeout (46/47 passed); the broader local suite is not green. Focused Client/mobile, CLI/packaging, live Host refusal, typecheck and build evidence is separated in the checkpoint. No positive native/media success is inferred from unit tests or API status.

Change outline

native Human mentioned text request → exact quoted Lark media parent
  → checked Provider descriptors + known duration + optional native cover
  → canonical Source Event and existing Channel placement
  → same bubble: original download + Prepare video
  → current Human/source/identity/reception-path checks
  → bounded existing AttachmentStore acquisition
  → original MP4 bytes + independently acquired cover
  → browser decode, then manual play/pause/seek

 existing attachment HTTP route(channel, source, attachment)
+ representation=playback accepts checked native video with sniffed MP4 bytes
+ channel-media-download --representation playback exercises the same owner
 original download remains separate and refuses overwrite

 ChannelMessage.bridgeMedia
+ video: { attachmentId, durationMs?, posterAttachmentId? }
+ items.kind: video
 no resource keys in the Channel projection

The player reuses DSH primitives, existing file download and video layout. Preparation is explicit and shares the three-request/25 MiB/30-second bounds. No autoplay, runtime transcoding, generated cover or model transcript is introduced. Missing, refused or undecodable cover does not block video; unsupported video format and transfer/source failures remain visible with original download available. Unmount and authority changes cancel acquisition and revoke URLs. Mobile accepts the wire shape as an original-file action and suppresses eager cover preview. The existing Bot Inbox source inspector also excludes the Lark video and cover from its automatic preview loop; it keeps explicit original-download actions, and the related 23-test Inbox/video run passed, including unchanged WeChat behavior. Final-head full verification passed for 5e9f2a9f067aea06f629bfa1c72bbabd178e338d: all three test shards, lint/format/typecheck/build, docs and isolated DSH smoke succeeded. Real-model scenarios are skipped. npm candidate preparation also passed; it is not publication or native media acceptance.

Visual and native qualification blocker

The Human supplied two genuine native videos through the Lark client. The latest parent was quoted with a real Bot mention through the built-in browser. The candidate retained the canonical Source Event with the exact native parent, 6000 ms duration, video/unknown primary and image/unknown native cover; IDs were checked against the platform parent. Official DeepSeek Flash DM succeeded. However, the native identity endpoint returned HTTP 429 / 99991403, "This month's API call quota has been exceeded" (token authentication still returned 200/code 0). The result Outbox failed provider-unavailable with zero send attempts and no receipt. Managed-file and Attachment-binding counts stayed zero. No playback, download or installed-product media success is claimed. The exact task-owned receiver was unbound and stopped; QA2 is released. The remaining native gates require restoration of the Lark API quota.

An additional isolated source-Provider installation preflight verified the exact f889a5808a342bb9b4abf586f115e57cb44b2b6b runtime: 421 files, SHA-256 02a4b38aaca218091e52bfa8a8b91be4c98f5d41458356ca9ecd0ee928633819, DSH 0.2.0-rc.2, authenticated API healthy, zero configured Lark Apps. Only that task-owned empty Host was stopped afterward. This verifies source installation and registration, not a fresh product-artifact/native media E2E.

Runnable review path after browser reconnection: verify the Human account and QA2 group, prepare an exclusive cutoff guard, upload one uniquely marked native video via Image & video, quote it with a genuine Bot mention, and correlate Source/Admission/Outbox facts. Open its Inbox source inspector before preparing the Channel player and verify zero video/cover acquisition; test its explicit original download separately. Compare original hashes, then test manual decoded playback, cover, refresh/restart and stop/unbind lifecycle. Capture the same source and viewport in light/dark before/after and record the interaction. The checkpoint keeps these gates open. A private HTML explainer binds Core head 5e9f2a9f067aea06f629bfa1c72bbabd178e338d and Provider head f889a5808a342bb9b4abf586f115e57cb44b2b6b; its complete content was scanned and desktop/narrow layouts inspected through a headless browser. It is not hosted or reviewer-accessible evidence.

[coderabbitai]

Caution

Review failed

The pull request is closed.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn