Feishu group bot does not pass ZIP attachments to bound agents

[Asherggg]

Problem

When a user sends or references a product image ZIP file in a Feishu group chat and triggers a bound bot/agent workflow, the agent receives the text task but cannot access the actual ZIP file.

Steps to reproduce

1. Send or reference a product image ZIP file in a Feishu group chat where a Multica bot is bound.
2. In the same conversation, trigger the bot to run the main-image processing workflow.
3. Inspect the agent output and its temporary working directory.

Actual result

• The agent is triggered successfully and the task is marked as completed, with no runtime error.
• The referenced attachment only appears in the agent context as [File].
• The agent does not receive a usable filename, attachment URL, attachment identifier, or local file.
• No ZIP file exists in the task working directory, so the agent cannot extract, validate, or repackage the image assets.
• Two related runs on 2026-07-24 both reported that the current message did not carry or reference an accessible file.

Expected result

Attachments from both the triggering Feishu group message and any referenced/replied-to Feishu message should be synchronized as Multica Chat attachments for the agent task.

At minimum, the task should receive:

• a readable local ZIP file in the working directory,
• the original filename,
• and attachment reference metadata that lets the agent trace the input.

Impact

This blocks Feishu group based ZIP workflows for bound agents. Users must upload the ZIP through Multica Web Chat instead, so the Feishu group integration cannot complete the expected end-to-end flow.

Suggested investigation

Please check the mapping and download path from Feishu group messages, referenced messages, and file attachments into Multica Chat attachments. The task trigger should make the ZIP available as a normal task attachment to the agent.

[Bohan-J]

Linking this to #5580, which just merged: it adds the inbound Feishu/Lark media pipeline (scoped message-resource download → object storage → attachment bound to the user chat message).

Deliberately keeping this open — your case is not fixed by it. That PR covers standalone image, media/video, and rich-text post-embedded img/media spans. A ZIP arrives as msg_type file, and mediaResourcesFromMessage returns nil for file and audio, so a ZIP will still surface as a bare [File] placeholder with no attachment — exactly what you reported.

The good news is that the remaining work is now small. Everything the download needs already exists: the authenticated resource endpoint, streaming upload with a size cap, in-transaction attachment binding, and an intent ledger plus reconciler that cleans up objects which never get bound. Adding file (and audio) is mostly extending that type switch plus tests — it no longer needs any new infrastructure.

Two things from your report that are worth keeping in scope when it's picked up:

• You asked for attachments from referenced messages too, not just the triggering one. The merged pipeline only resolves media on the triggering inbound message, so quoted/forwarded references would be additional work beyond the type switch.
• You expect a usable filename and a local file in the task working directory. The merged path binds a chat attachment; whether the daemon materializes it into the run's working directory is a separate leg worth verifying rather than assuming.

Not promising a timeline, but the blocking infrastructure is in place, and contributions are welcome — #5768 has some context from a contributor who had implemented file/audio handling before the merge.