提单助手不是没挂图，是服务端不允许它挂

服务端把「Issue 创建者」当成「附件上传者」去过滤要绑定的附件。对 agent 建单场景，这个等式永远不成立。

前序结论：「attachment id 019fdc2e-… 在服务端已失效／已删除，server 静默跳过绑定」。它的唯一证据是一次 404。

$ multica attachment download 019fdc2e-cceb-765b-abc5-f5bd713471bd
The requested resource was not found.

我把这个方法用在两个已被 issue get 证明活着的附件上，得到同样的 404：

所以 404 只能推出「本 task 没被授予这个附件」。更直接的反证 —— 我用同一个 id 成功绑定：

$ multica issue create … --attachment-id 019fdc2e-cceb-765b-abc5-f5bd713471bd
→ BUG-8, attachments: [{
    "id": "019fdc2e-cceb-765b-abc5-f5bd713471bd",
    "filename": "img_v3_0214b_42ecb616-…-44831a71308g.gif",
    "created_at": "2026-08-07T20:24:42+08:00",
    "chat_session_id": "5d037921-3062-4f3b-a8ef-52760dfd2a49",
    "uploader_type": "member",
    "uploader_id":   "9e8a3719-73f1-4435-8223-71ffb6054967",
    "size_bytes": 2825604
  }]

该附件从创建至今一直存活、一直可绑定。用户「结论完全是错的」这个判断是对的。

~/Library/Caches/trae-cli/sessions/258f3c92-73cc-4b3a-b9c1-689b8ec8912f/events.jsonl

平台注入给它的 prompt（idx 8）

Attachments on this message:
- id=019fdc2e-cceb-765b-abc5-f5bd713471bd filename="img_v3_…gif" content_type=image/gif
Use `multica attachment download <id>` to fetch each file locally before referring to it.
When creating an issue that should preserve one of these attachments, pass
`--attachment-id <id>` to `multica issue create` in addition to keeping the
attachment markdown inline.

它执行的命令（idx 24 / idx 27）

# 20:25:36 第一次 —— 被去重守卫拒绝
multica issue create --title "[v0.0.3 Bug] mermaid 有 bug" \
  --description-file ./description.md --status backlog \
  --attachment-id 019fdc2e-cceb-765b-abc5-f5bd713471bd --output json
→ Active duplicate issue exists: BUG-2 …

# 20:25:41 第二次 —— 加 --allow-duplicate，成功
multica issue create --title "[v0.0.3 Bug] mermaid 有 bug" \
  --description-file ./description.md --status backlog \
  --attachment-id 019fdc2e-cceb-765b-abc5-f5bd713471bd \
  --allow-duplicate --output json
→ {"identifier":"BUG-3",
   "creator_type":"agent",
   "creator_id":"cada05b8-b1fd-48a8-8d04-450cdd7d8d9f", … }
   # 返回体里完全没有 attachments 字段

参数一字不差，没有报错，没有 hallucinate。唯一异常是返回体静默缺少 attachments。关键字段就是那行 creator_type: "agent"。

以下均取自部署中的 commit 520e45a2e（与 CLI v0.0.2 一致），仅只读查看，未改动任何代码。

4 · service 把「Issue 创建者」当「附件上传者」 ← 缺陷点

server/internal/service/issue.go:294

func (s *IssueService) linkAttachments(ctx context.Context, issue db.Issue, ids []pgtype.UUID) []db.Attachment {
    if len(ids) == 0 { return nil }
    if err := s.Queries.LinkAttachmentsToIssue(ctx, db.LinkAttachmentsToIssueParams{
        IssueID:      issue.ID,
        WorkspaceID:  issue.WorkspaceID,
        UploaderType: issue.CreatorType,   // ← 把「Issue 创建者」当成「附件上传者」
        UploaderID:   issue.CreatorID,     // ←
        AttachmentIds: ids,
    }); err != nil {
        slog.Error("failed to link attachments to issue", …)   // 只记日志，不影响返回
        return nil
    }
    …
}

函数注释本身就写明这是「best-effort post-commit step」—— 设计上就是失败也不告诉调用方。

5 · SQL 的硬条件

server/pkg/db/queries/attachment.sql:340

-- name: LinkAttachmentsToIssue :exec
UPDATE attachment
SET issue_id = sqlc.arg(issue_id),
    expires_at = NULL
WHERE workspace_id  = sqlc.arg(workspace_id)
  AND issue_id IS NULL                        -- 条件 A：必须尚未绑定任何 issue
  AND uploader_type = sqlc.arg(uploader_type) -- 条件 B：上传者类型 == Issue 创建者类型
  AND uploader_id   = sqlc.arg(uploader_id)   -- 条件 C：上传者 id   == Issue 创建者 id
  AND id = ANY(sqlc.arg(attachment_ids)::uuid[]);

全部以成员身份在 workspace 470e8a4a-… 执行。探测 issue 一律 --status cancelled、无 assignee，不上看板、不触发任何 agent。

实验 3+4 顺带确认了条件 A 的真实语义：附件一旦绑定到某个 issue，后续 --attachment-id 传同一个 id 会被静默丢弃。一个附件只能绑一个 issue。

这是用户的核心疑问。答案是两条路径的 SQL 条件完全不同 —— 评论侧根本没有 uploader 过滤。

server/pkg/db/queries/attachment.sql:174

-- name: LinkAttachmentsToComment :exec
UPDATE attachment
SET comment_id = $1, expires_at = NULL
WHERE issue_id = $2
  AND comment_id IS NULL
  AND id = ANY($3::uuid[]);
-- 注意：没有 uploader_type / uploader_id 条件

而且 comment add --attachment <本地路径> 是先上传一个新文件（uploader = 调用方自己），再绑定 —— 天然满足所有条件。

所以对 agent 而言，唯一可靠的挂图方式是先 multica attachment download <id> 落到 workdir，再用 --attachment <本地路径>（BUG-4 就是这么成功的）。而平台 prompt 却明确指示它用 --attachment-id。

1. 所有 agent 建单挂对话附件的场景全部静默丢图。不限于提单助手 —— 任何 agent task，只要按 prompt 指示用 --attachment-id 挂人类上传的附件，100% 失败且无感知。这解释了 BUG-2 的同类现象（同模板、同 agent）。
2. quick-create 流程同样中招（代码层推断，未做线上复现）。daemon.go:4588 把人类上传的附件 id 经 MULTICA_QUICK_CREATE_ATTACHMENT_IDS 交给 agent，cmd_issue.go:1149 自动并入 attachment_ids，但 issue 由 agent 创建 → 同一个 uploader 不匹配 → 静默丢弃。该 env 的测试（daemon_test.go:4737）只断言「env 被正确传递」，没有断言「附件最终绑上了」。
3. issue update --attachment-id 对 agent 一样失效（issue.go:2668-2687，同一个 query）。
4. 没有任何错误信号。三层都在吞：SQL 命中 0 行不算错、linkAttachments 只 slog.Error、handler 不校验请求的 id 是否真的绑上了。agent 因此必然汇报成功 —— 这不是模型幻觉，是接口没有给出可观测的失败。

供产品／研发决策，本次未实施任何修复。按优先级：

1. 让绑定授权认「同一 task / 同一 chat session 的上下文」，而不是只认 uploader 相等。 agent 在 task fea75f5c 里创建 issue，附件 019fdc2e 属于该 task 的 chat session 5d037921 —— 这是合法授权关系。给 LinkAttachmentsToIssue 增加一条「附件的 chat_session_id/task_id 属于当前 task」的放行分支，既修好 agent 场景，又不放开「猜 UUID 偷别人附件」（原安全测试仍然通过，因为陌生成员的 staged 附件不在你的 task 里）。
2. 把绑定结果回传给调用方，不要静默。LinkAttachmentsToIssue 改成 :execrows，或返回实际绑定的 id 列表。chat 侧已有现成先例：chat.go:700 的 BoundAttachmentIDs 明确区分「请求的」和「实际绑上的」。CLI 在 attachment_ids 非空而 attachments 为空时应当 warn 到 stderr。
3. 短期兜底：改 prompt。把 prompt.go:398 的指示改成「先 multica attachment download <id>，再用 --attachment <本地路径>」—— 这条路径实测可用，无需动服务端。

• 没有改动任何代码。/Users/park0er/Coding/AgenticAds/Rollica 只做只读的 git show / grep，无 checkout、无提交。
• 没有改动 BUG-1 ~ BUG-7，没有改动提单助手 agent 配置，没有动它那次会话的 workdir 和 trae session 目录。
• 新建了 3 个探测 issue：BUG-8 / BUG-9 / BUG-10，均为 cancelled、无 assignee、不触发任何 agent。