voyager

今日锚点 #5870 是这条线从“workspace 能买 seat、pool 能付款”继续向前的一步：它把 seat-count mutation 从本地 PATCH 改成 Stripe hosted confirmation，并把 #5842 的 webhook-driven pool funding 改为消…

这条业务线解决的不是“在个人套餐里增加一个 Team”。真正的问题是：工作区为席位持有人买了能力之后，成员在这个 workspace 里做的工作应该由谁付款；个人余额、workspace pool、操作发生地和退款对象必须能在同一条数据流里被区分

这条业务线解决的不是“在套餐列表里增加一个 Team”，而是把“谁付费、谁可以使用、哪一个 workspace 承担额度、一次扣费发生在哪里”拆成可落地的边界

这条业务线解决的是一个平台 API 特有的可交付性问题：浏览器会话在 Agent turn 因 step/token budget 停住后，可以由用户按 Continue；无人值守的 Platform Agent Task 只有“创建任务”和“轮询状态”两个外部动作，没有人会替它按按钮。旧路径因此可能把已经写入文…

这条业务线解决的是“导出同一种设计时，为什么不同入口有不同的超限、失败、内存和重试语义”。在本次演进前，多页 PNG、选区图片和 PDF 分别存在同步路由或独立 Worker handler；一部分格式已经进入 Cloudflare Workflow，另一部分仍在 Next.js/Worker 请求生命周期内完成…

这条业务线解决的不是“如何把 prompt 写得更长”，而是图片生成调用之间哪些信息能可靠地跨调用传递。每次 image_generation 只看到本次 prompt 和 refs，不会自动看到上一轮对话、用户上传文件或 brand kit。形状、字体、精确布局和角色轮廓一旦只被改写成文字，就会在每次独立生成中…

这条业务线解决的是一个跨运行时的用户流程：用户把图片上传到 Agent chat，然后要求生成参考图、去背、编辑，或把图片放到画布上。聊天附件最初只是 chat-scoped 的 R2 对象，图片任务和 Design 节点却都要求 durable workspace asset id；Design 节点最终保存的…

这条业务线处理的是 Agent 聊天在 Durable Object（DO）或其唤醒路径发生暂态故障时，如何同时保护三件事：持久对话不能因断线被误删；服务端故障要以可恢复的协议返回；客户端不能把一个已经 wedged 的 chat 变成持续唤醒 DO、重复打 Sentry 的重连风暴

这条业务线解决的是 Agent 在聊天中处理图片时的“输入资产不是普通 workspace asset”问题，同时把一次图片任务变成可恢复、可去重、可正确反馈的运行时流程

这条业务线处理的不是某一个具体聊天功能，而是 Agent 对话在 Durable Object（DO）出现生命周期或平台暂态故障时，如何保持“数据不被误删、冷对象能被读、可重试失败不会直接变成不可解释的 500”。用户可见的入口有两条