[wanglongan587]

Summary

资源和页面消费：真实资源薄投影、对话绑定、操作/历史客户端；工作流/任务旧引用仅只读兼容。

#214 记录/时间 → #215 最终状态/查询
                         ├→ #217 调度/操作
                         └→ #221 历史/结果
                              → #224 页面消费

本轮同步 #221 的复合游标历史契约、合入最新 main（b3b875d7），并补齐页面轮询容错与操作回执交互：

• 轮询失败保留已加载状态：资源、配置列表与运行历史在后台轮询报错时保留既有数据并叠加错误提示，避免清空下拉、卸载已打开面板或在存在未释放运行时误放开“立即运行”。
• 操作错误映射与记录定位：补齐 execution_busy、execution_target_unavailable、invalid_execution_request、execution_unsupported 中文提示，消费错误响应中的 params.occurrenceId 自动选中已写入记录，并在终态拒绝时释放本地 requestId；无 executionRef 的取消不再发起冗余结果查询；observed 优先读取列表同 id 新状态。
• 样式与模型清理：修复 .sp-history-list button[aria-pressed="true"] 选中高亮，移除旧演示遗留的未引用样式与 Run 死字段，同步对齐 e2e/task-schedules.spec.ts 用例与截图命名。

本 PR 依赖与审查范围： 消费 #217 和 #221 的操作/历史契约，代码可并行审查。

Evidence

• 本次 head bdf38fe6fe2534e42469036bbfee02cf9444ed90。CI：https://github.com/ora-space/cloud/actions/runs/41164811031 （server / frontend / e2e 全绿）。
• 本地通过 npm run api:check:schedules、npm run lint、tsc -b --noEmit、Vitest 定时任务测试（16/16）、vite build 及 PostgreSQL go test -race -count=1 ./internal/server。
• 下图为当前五份 PR 组合在本地预览环境的运行历史页面截图（含修复后的选中行高亮与时间倒序记录）。

Merge Danger

Door: two-way

Blast Radius: v2

v2，不涉及 specs。

Refs ora-space/circus#796

[ObsisMc]

审查 head b218b8a1b34f10bc8ada254a15187c92cf087a32（merge-base main bad9e4d7）。

核对

• 改动都在 frontend-v2/ 和 v2-server/ 下，都是交付物（代码、测试、OpenAPI、README、orval 配置），描述写了「v2，不涉及 specs」。
• v2-server/schedule-actions.openapi.json、schedule-history.openapi.json 和 #217（1252db82）、#221（fe50af80）head 上的文件内容一致；orval.schedule-runtime.config.ts 指向正确的契约，CI 的 api:check:schedules 会重新生成三个客户端，漂移有保障。
• 之前移除的参数解析、自定义 resolver、引用目标写入契约、SourceTask 和工作流 mock 都没有回来；旧工作流/任务目标在前端只读，服务端写入返回 503。
• 历史排序：按 recorded_at DESC, id DESC 展示，b218b8a1 用 BigInt 纳秒保住亚秒顺序，再按小写 UUID 字符串比较，和 PostgreSQL uuid 顺序一致；多页合并按 id 去重，nextCursor || undefined 正确结束分页，"加载更多"和 3s 轮询不会重复或漏项。
• 表单提交的字段和服务端校验一致（无项目必须选目录里的模型；有项目时 executorId 的 modelId 要和模型一致）。
• head 上 CI 全绿。本次只做了静态审查，没有在本地跑测试和 e2e。

非阻塞建议

1. （建议合并前改）一次轮询失败就清空已加载的数据。page.tsx:42（资源）、page.tsx:52（配置）、schedule-detail.tsx:25（历史）都写成 isError ? 空 : data。TanStack Query 在 refetch 失败时会保留旧 data，这里却丢掉了，再加上 retry: false 和 30s/3s/窗口聚焦的轮询，一次失败就会：
   • 资源下拉变空、保存提示项目或模型不可用；
   • 打开的详情变成"任务当前无法读取"，面板卸载、状态丢失；
   • 历史 rows 变空，occupied（schedule-detail.tsx:34）变 false，运行还在进行时"立即运行"就可以点了，服务端随后会多记一条 previous_unfinished 的跳过记录。
     历史错误提示写的是"既有记录未被清除"，和实际行为也对不上。建议有 data 时继续展示旧数据，只额外显示错误。
2. runtime.ts:18 的错误文案缺 #217 会返回的 execution_busy（409）、invalid_execution_request、execution_unsupported（400），会落到"运行请求失败，请重试同一请求"；后两个是 400，重试同一请求不会成功。错误响应里的 params.occurrenceId 也没有用上，界面不会选中已经记下的那条记录。
3. 历史列表按钮改用 aria-pressed 后不再有 active class，但 schedules.css:157 只给 .sp-history-list button.active 加了背景，选中行没有高亮了。改成 [aria-pressed="true"] 即可。
4. schedule-detail.tsx:28 的 observed 取 rows[0] 和 exact.data 中计划时间较晚的一条；exact 查询在记录出现在 rows 后就停用，exact.data 不再更新。手动运行之后紧接着有一条定时记录时，列表可能一直显示手动运行的旧状态。可以改成优先用 rows 里同 id 的那份。
5. 取消成功后调用 output.refetch()，TanStack v5 的 refetch() 不看 enabled: false，没有 executionRef 时会发一个无用的结果请求。
6. 删除来源选择器、工作流列表和演示 store 后，schedules.css 里留下了无人引用的样式：sp-source-*、sp-workflow-list、sp-workflow-option、sp-demo-options、sp-target-title、sp-flow-inputs。Run 类型里的 projectName、output、target 现在总是空或复制值，也可以去掉。
7. orval.schedules.config.ts 的 clean: true 作用在 src/features/schedules/api/ 上，单独跑这份配置会删掉 api/actions 和 api/history。组合脚本会紧接着重新生成，只在单独运行时有影响。

结论：没有阻塞问题，契约和 #217、#221 一致，可以在两者之后合并；第 1 条建议合并前处理，是否等改完由 owner 决定。

[ObsisMc]

复审 head fb1ca14d32d7092873df688b7d1518c41983da58。相对上次 Approve 的 b218b8a1，多了两个提交：

• 4a4d9886 merge main（cloud#237）。我在本地重做了这次合并，只有 v2-server/README.md 冲突，其余文件和自动合并一致；README 保留了本 PR 的资源接口和"职责与旧引用兼容"两节，也保留了 main 的新内容。这个提交上 CI 失败了：main 装配真实 runtime 后会暴露 Fixture 模型，旧的 e2e 断言不再成立。
• fb1ca14d 按装配后的环境改了两份 e2e：建任务时选 Fixture 模型，"立即运行"改为可用；无 Node 资产时执行器列表为空，选 Demo 项目加 Fixture 后显示"暂无匹配的执行器"。改法和现在的真实行为一致。

CI 全绿，可合并性 CLEAN。

小问题：task-schedules.spec.ts 的用例名（unavailable target kinds…）和截图名 resources-unavailable-mobile.png 还是"资源不可用"的说法，但模型现在是可用的，可以顺手改名。上次的 7 条非阻塞建议仍然有效，第 1 条（轮询失败清空已加载数据）建议合并前处理。

结论：没有阻塞问题，可以在 #217、#221 之后合并；合并由 owner 决定。

[ObsisMc]

复审 head bdf38fe6fe2534e42469036bbfee02cf9444ed90。相对上次 Approve 的 fb1ca14d，新增的 298487a0 和 bdf38fe6 两个提交处理了我上次的建议，我都核对过：

1. 轮询失败保留旧数据：资源、配置、历史三处都改成"有 data 就继续展示，错误另行提示"。表单在资源刷新失败但已有目录时仍然可用；历史保留后，occupied 不会因为一次失败变成 false，"立即运行"不会被误放开。
2. 错误码：补齐了 execution_busy、execution_target_unavailable、invalid_execution_request、execution_unsupported 的文案。错误响应里的 occurrenceId 会被选中。400、execution_busy、execution_target_unavailable 这类终态拒绝会清掉存着的 requestId，下次运行用新键；按钮也不再显示"重试运行请求"。和 #217 新的 409 映射一致。
3. observed：只有 exact 的记录还不在 rows 里时才用它，否则用 rows 里同 id 的最新数据。
4. 取消后刷新结果：只在有 executionRef 时才调用 output.refetch()。
5. 清理：选中高亮改用 [aria-pressed="true"]；删掉了遗留样式、Run 的废弃字段和 sampleTasks/sampleOutput；e2e 用例名和截图名已对齐。page.test.tsx 补了轮询失败保留数据和错误码定位的测试。

CI 全绿。

结论：可以在 #217、#221 之后合并，合并由 owner 决定。

[ObsisMc]

复审 head ddd11d4e（上次 Approve 在 bdf38fe6）。

这次只是合进了 main 117d16d0（含 cloud#217/#221/#241）。我在本地用 bdf38fe6 重新合并了一次，冲突只有 package.json、v2-server/README.md、server.go 三处，其余文件和实际合并结果完全一致：

• server.go：只多了 schedule-resources 一条路由，main 的历史/结果/操作路由都在。
• package.json：api:generate:schedules 串上了 runtime 客户端生成，api:check:squads 用的是 main 的 collaboration 路径。
• 相对 main 只剩页面、资源和配置接入自身的增量，schedule-actions / schedule-history 两份契约已不在 diff 里。旧枚举的升级和测试沿用 main 的修复。
• 删除 task/workflow 演示 store、picker 这些文件，在上次审过的 bdf38fe6 里就有，不是这次合并带进来的。

CI 全绿，没有阻塞问题，Approve。

建议合并前顺手修（都只是 v2-server/README.md 的文档）：

1. 第 80 行"专用 HTTP 集成测试按此候选 OpenAPI 验证响应……"和第 105 行重复，是合并留下的，删掉一处即可。
2. 本 PR 已把页面接上运行操作，第 237 行"前端按钮尚未接入"和第 243 行"配置页面尚未连接运行操作"已经过时。

非阻塞：

• main 上 v2-server/schedule-history.md:21 还写着"新底座将旧 admission_unknown 升级为该状态……"，cloud#217 删掉升级后这句已不成立。它不在本 PR 的 diff 里，可以一起顺手修。
• e2e 仍点"开发者登录"。按 owner 在 #796 的说法，W2（cloud#240）合入后再改用 signIn()。