cc-web/.planning/runtime-image-send/task_plan.md

任务计划：修复排队与运行中图片发送

目标

让图片附件能够随排队消息发送，并能够通过 Codex App 的 turn/steer 在运行中插入；附件在会话记录、失败回退和界面状态中保持一致，且不破坏现有纯文本路径。

当前阶段

阶段 8：检查会话状态并安全重启服务。

阶段

阶段 1：核对当前附件生命周期与现有改动边界

• 梳理上传附件从前端到后端解析、持久化和 Codex App 输入的路径。
• 核对工作树中重叠文件的既有改动，避免覆盖其他会话内容。
• 状态： complete

阶段 2：补充排队图片和运行中插入图片的失败回归测试

• 覆盖队列保存并发送附件。
• 覆盖运行中 turn/steer 接收 localImage。
• 覆盖 stale turn 回退为新 turn 时保留附件。
• 状态： complete

阶段 3：运行目标回归确认测试失败

• 只运行相关回归，确认测试能捕获当前缺陷。
• 状态： complete

阶段 4：实现前端队列和运行中插入附件传递

• 队列项保存附件快照并在出队时传给普通发送路径。
• 运行中插入消息携带附件并正确清空 composer。
• 状态： complete

阶段 5：实现后端 turn/steer 附件解析持久化与回退

• 复用现有附件解析与安全校验。
• 持久化运行中插入消息的附件元数据。
• turn/steer 和 stale turn 新轮回退均传递 localImage。
• 状态： complete

阶段 6：运行目标回归和静态检查

• 运行相关回归、语法检查和项目级快速验证。
• 状态： complete

阶段 7：审查差异并修正问题

• 检查规范、跨层一致性、附件生命周期和用户既有改动保护。
• 修正审查发现并重新验证。
• 状态： complete

阶段 8：检查会话状态并安全重启服务

• 查询除当前对话外的运行中会话。
• 仅在无其他运行中会话时重启 ccweb 并做健康检查。
• 状态： in_progress

关键问题

1. 队列延迟期间附件记录是否仍能被后端安全解析？
2. turn/steer 失败转新 turn 时如何避免附件丢失或重复持久化？
3. 当前回归框架如何断言 localImage 已进入 app-server 请求？

决策记录

决策	原因
使用现有附件上传记录和 codexAppInputFromMessage	避免引入第二套附件格式与安全边界
不切换共享 .planning/.active_plan 与 .trellis/.current-task	当前工作树存在其他活跃任务，避免跨会话干扰
先补失败回归再实现	同时覆盖队列、steer 与 stale fallback 三条容易丢附件的路径
队列允许纯图片并显示附件摘要	与普通消息能力一致，同时让用户可验证图片仍在队列中
删除未发送队列项时清理其上传附件	避免无主附件占用存储直到 TTL 到期
新增 runtime-image-send 定向回归目标	在 60 秒预算内覆盖前端契约、成功 steer 与 stale fallback
steer 最多等待 2 秒获取 ready turn	前端 running 状态可能早于 app-server 返回 turnId，短等待避免图片/文本插入竞态误失败
steer 持久化前重新加载 session	避免启动 turn 仍持有的旧 session 快照覆盖刚插入的用户附件消息

错误记录

错误	次数	处理
.codex/agents/trellis-implement.toml 与 trellis-check.toml 不存在	1	项目仅将这些代理定义为可选；改用标准协作子代理并在提示中显式注入任务、规范和边界

范围边界

• 只支持现有图片附件类型，不扩展任意文件附件。
• 不改变纯文本排队、slash 指令和笔记模式的既有语义。
• 不覆盖工作树中与本任务无关的主题、样式和其他功能改动。