mirror of
https://github.com/Ark0N/Codeman.git
synced 2026-10-02 13:39:41 +02:00
Codeman maintainer
cbc54fc98d
A clip an agent wrote inside the workspace played with a working scrub bar, while the same file in /tmp was refused as an unsupported type. The workspace preview classified media with its own inline extension sets and the attachment allowlist had no media at all, so the two paths disagreed about what a video is. - VIDEO_ATTACHMENT_EXTENSIONS and AUDIO_ATTACHMENT_EXTENSIONS now live in attachment-registry.ts and are imported by file-content's classification, so both paths answer the same. mp4/webm/mov/m4v/ogv and mp3/wav/ogg/oga/m4a/aac/flac/opus join the attachment allowlist. - Real MIME types for those extensions. Without one the raw route falls back to application/octet-stream, which a <video> refuses to decode: the player renders and then does nothing. - getAttachmentType() gained the video and audio members of AttachmentDetectedType. Attachment cards have no per-type CSS and their thumbnail falls back to the type label, since the thumbnailer has no media branch and answers 204 rather than spawning a converter. - The preview overlay's by-id branch renders <video>/<audio> with the same markup as the workspace branch, playsinline included. Serving was already range-aware, so seeking works. The image-watcher keeps its own narrow detection list (png/pdf/docx/pptx), so this does not start popping cards for every video an agent writes. Text types that are not md or txt (.json, .log, code files) remain out of the allowlist by choice and still report what is previewable instead. Verified on an isolated instance: an external mp4 and mp3 both play, seek, and report the right duration, matching the in-workspace clip exactly, and a click on an external mp4 in the terminal opens the player with no attachment card. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>