[wanglongan587]

Summary

最终状态与核对查询：同任务占位、状态证据、原身份只读查询及旧草稿状态升级；没有执行派发。

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

本轮同步 #214 的 (recorded_at, id) 复合游标与时间倒序查询，并合入最新 main（b3b875d7）。状态 Go 实现与 #217/#221 保持一致，schema.sql 保留 v2_schedule_occurrences_history 索引与状态升级逻辑。

本 PR 依赖与审查范围： 依赖 #214；审查自身增量可用 git diff 372f65ae 1380b6eb -- v2-server。

Evidence

• 本次 head 1380b6ebc66bdf95a1c035a2c7b6188f4f5f1d7e。CI：https://github.com/ora-space/cloud/actions/runs/41162039336 （server / frontend / e2e 全绿）。
• 真实 PostgreSQL go test -race -count=1 ./internal/store 及 Linux go vet / go build 通过。
• 下图为当前五份 PR 组合在本地预览环境的运行历史页面（含成功与忙即跳过记录，按 recorded_at DESC, id DESC 排列）。

Merge Danger

Door: two-way

Blast Radius: v2

v2，不涉及 specs。

Refs ora-space/circus#784

[ObsisMc]

审查 head 2ad52b8d380219bd2359878aa1157ef255be4510。只审本 PR 相对 #214（8bccc8d6）的增量：git diff 8bccc8d6 2ad52b8d，7 个文件。

核对

• 增量都在 v2-server/internal/store/ 和 README，都是交付物；occurrence-states.md 是长期的状态说明。
• 状态机和 occurrence-states.md 的表一致：
  • begin 只从 recorded 出发，在同一事务里锁配置行、检查同任务未释放占位、配置版本和暂停；已有占位记 skipped/previous_unfinished。RecordOccurrence 插入时也做同样检查，部分唯一索引 v2_schedule_active_occurrence ... WHERE NOT released 兜底，手动和自动共用，手动绕不过去。
  • rejected 必须带原因、只从 starting 出发，才释放占位；reconcile / 超时类结果保留占位。
  • accepted 绑定 Ref 后不可替换；not_accepted 只在没有 Ref 时允许。
  • 结果终态要求 Ref 一致，且不释放；只有 released（End 确认）才释放。
  • recover：recorded → skipped/server_restarted（不补跑），starting/running/cancelling → reconciling，保留 Ref 和占位。
  • expectedVersion 挡住迟到回调。
• 同步 owner 结论的提交 2ad52b8d 只改了排序相关的查询和测试，和 #214 一致。
• head 上 CI 全绿。本次只做了静态审查，没有在本地重跑测试。

非阻塞建议

1. schema.sql 里升级旧草稿状态的三条 UPDATE（admission_unknown、workspace_busy、admission_not_accepted）只针对从没进过 main 的草稿库。#214 和本 PR 合并后，main 上不会有这些值，可以考虑删掉，省得以后被当成真实的历史状态。另外每次启动都 DROP/ADD CONSTRAINT，会锁表并全表校验一次，演示规模下没问题。
2. ApplyOccurrenceEvidence 和 ActiveOccurrences / RecoverableOccurrences 都要求创建者当前仍是有效成员。成员在运行中被移出租户时，适配层写不进终态和 released，这条记录会一直占位。对演示影响不大，记一下即可。
3. cancelling 遇到 recover 变成 reconciling 后，取消意图就丢了；之后核对到仍在运行会回到 running。如果公共服务重启时一定会把旧轮次结算成 interrupted，这里就没问题，建议在状态说明里写一句这个前提。

结论：没有阻塞问题，可以按 #214 → #215 的顺序合并；合并由 owner 决定。

[ObsisMc]

复审 head 1380b6ebc66bdf95a1c035a2c7b6188f4f5f1d7e。相对上次 Approve 的 2ad52b8d 只多了一个 merge 提交，合进了 main（cloud#237）和 #214 的新 head。我在本地重做了合并：只有 v2-server/README.md 冲突，其余文件和自动合并一致；README 的解法保留了本 PR 对"定时触发记录基础"一节的改写，也保留了 main 的新内容，没有丢东西。CI 全绿，可合并性 CLEAN。

结论不变：可以合并，合并由 owner 决定。

[ObsisMc]

复审 head 08633e76d3a0811df04914f1a1b87b7fac8efa63。相对上次 Approve 的 1380b6eb，只多了一个 merge 提交，合进了最新 main c0e90298（其中含已合并的 #214）。合并后的树和 1380b6eb 完全一致，代码没有变化。现在相对 main 只剩本 PR 自己的 7 个 v2-server 文件，和我审过的增量相同。CI 全绿，可合并性 CLEAN。

结论不变：可以合并。是否等 preflight 依赖，由 owner 决定。