Projection、Checkpoint 与冷启动

结论：事件日志掌握真相，Checkpoint 与 Projection 掌握时机和成本

只有把这些层严格分开，架构的优势才成立。语义 checkpoint 证明更早的事实已经到达存储；projection checkpoint 只记住一次 fold；watermark 表示一个值观察到了哪里；baseline 是传输 cut；client row 则是可丢弃的收敛状态。把其中任何一层误当成日志本身，恰好会制造这套设计试图避免的恢复错误。

1. 六个名称对应六种不同合同

2. Semantic checkpoint 是 await barrier，不是存储中的 checkpoint object

把事实 append 到 live Session
        ↓
sessions.flush(session)
        ├─ persistence listener 排空 write-behind
        ├─ 其他 scoped durability listener settle
        └─ 所有 listener settle 后才抛出第一个失败
        ↓
构造 model stream 或进入顶层 tool body

SessionStore.flush() 解析精确 live Session 的 scoped listeners，调用全部 listener，以 Promise.allSettled 等待，若存在拒绝再抛出第一个。它的返回值只表示是否有 durability listener 参与；这个 API 不会生成任何耐久的“checkpoint record”。

3. Write-behind 把热路径接纳与耐久静止点分开

Persistence 与 checkpoint scheduling 是两个独立插件。只加载 backend 合法，但崩溃可能丢失仍处于 batching window 或 outstanding write 中的事件。发布的 base composition 会显式同时挂载 JSONL persistence provider 与 checkpoint policy。PROJ-SHIPPED-COMPOSITION

4. Projection unit 是对每个 committed event 的同步 fold

ProjectionDefinition<K, S> = {
  key,
  schema,             // 校验 wire-facing view
  init(): S,
  apply(S, event): S, // pure 且同步
  view(S): Value,
  stateVersion
}

同步要求具有关键作用。Carrier 可以复制 Session 的 event snapshot，并在同一个 JavaScript turn 中立刻调用 snapshot()，得到共享 asOfSeq 恰为 session.seq - 1 的 values；异步 unit 会撕裂这个 cut。

5. 十三个生产 key 共用一个框架，却表达不同生命周期

这是固定 commit 上对生产注册的全仓库清点，并不承诺每种部署都激活全部十三个 key。注册取决于 composition；process-wide unit table 还意味着某个 preset 挂载的 key，可能出现在自身 preset 并不会产生有意义值的其他 Session snapshot 中。

6. Watermark 在观察时前进，Push 只在变化时发生

seq N 的 event 进入每个 unit
  ├─ apply 返回同一 reference
  │    observedSeq = N
  │    不发送 session/projection frame
  └─ apply 返回新 reference
       observedSeq = N
       schema.parse(view(state))
       emit { key, value, seq: N }

这个区分解释了为何 imageLimits 从不发送 push，却仍会出现在 tail baseline 中；也解释了为何完整 snapshot 中一个安静的 value 可以合法地标记为日志当前 asOfSeq。Watermark 表示“已观察至此”，而不是“最后一次变化发生在此”。

7. Durable projection cache 是版本化 shortcut，从不是读取权威

8. 已实现的 cold-cache ladder 没有接入发布的 Cold History

已实现的 SessionProjectionCache.coldSnapshot(id)
  cache rows → restoreFloor → persistence.readFrom(tail)
  → registry.restore → fail-soft refreshed write-back

发布的 ordinary cold History
  persistence.inspect(full logical log)
  → registry.restore({}, all events, 0)

发布的 Session list
  只调用 cachedSnapshot(header)，零 log I/O

9. Inspect、Prepare 与 Resume 构成冷启动协议，而不是三个别名

10. 浏览器 Cold Open 被刻意设计为不同于 Agent Resume

Cold Session 必须能被 persistence list 找到，并携带 project cwd，才可由 Web 服务。若日志记录的 preset 已无法提供 standing presenter scope，History 仍可降级为 generic tool card。真正 resume 更严格：它必须通过 format、continuity、ownership、preset composition、setup 与最终 publication 检查。

11. Client Convergence 组合完整 Baseline、稀疏 Push 与 Generation Repair

history tail baseline { asOfSeq: N, values: all registered keys }
                       ↓ seed
resident ProjectionValueStore
                       ↑ 仅 frame.seq 更大时 apply
session/projection { key, value, seq }

新 mux generation：
session/subscribed { lastSeq: D }
→ 删除 client 中 seq > D 的 rows
→ 重新拉 list，并 resync 已打开的 History windows

Mux 与 host feed 是两条独立 stream，没有共享 total-order 声明；v1 的 events.mux({since}) 也会忽略 since。被支持的收敛方式是重开 stream、刷新 list、重拉 History，并按各 domain 规则 repair，而不是从一个全局线性 stream offset 继续。

12. Rebuild 与 Invalidation 发生在四种不同 Scope

没有任何 live registry API 会从 persisted checkpoint hydrate 自己的 WeakMap cells。Cache 的 detached restore() 路径会返回 snapshot 与 refreshed checkpoint，但 resumed live Session 在 registry 第一次访问时仍会 fold 内存 event array。Cache 也没有 eviction 或 retention surface；record 会一直累积，直到 out-of-band maintenance 删除。

13. 四项文档声明已经偏离当前生产控制流

14. 源码级风险：Detach 可能短暂让 Projection Cache 领先日志

Session detach
  1. 从 SessionStore 移除 Session
  2. emit 被 contain、未 await 的 session/disposed observers
       ├─ persistence 启动异步 retirement flush
       └─ projection cache 取 snapshot 并写入
            live-entry 检查此时失败 → 不调用 sessions.flush()

coldSnapshot() 原本可通过 anchored floor 检出 overreach，但发布路径没有 caller 使用它；zero-I/O list read 也不校验 stored log endpoint。因此 phantom list projection 可能进入 client；后续较低 seq 的 cold-History full-fold baseline 会在 higher-seq-wins 下失败，直到真正 resume 发出 session/subscribed 并 truncate row，或日志前进超过它。

15. 源码级风险：Equal-seq Replacement 无法跨越 Host Generation

imageLimits 让场景变得具体：它的 state 永远是 null，view 读取当前 boot 的 attachment config，并且刻意从不 push。浏览器若跨 Host restart 保持存活，就可能在 seq N 保留旧 limits；subscribed 不会删除它，因为它没有超过 N，而新的 N baseline 会因 equal 被拒绝。只有另一个 event 推进 baseline、client 完整重置，或协议携带 generation/version 维度后，value 才会收敛。

同一个边界也适用于 unit view semantics 在日志 watermark 不变时改变，以及同 key 的 unload/reload。stateVersion 能保护 Host persisted cache，却没有出现在 client wire row 中，因此无法解决这个 client-generation 歧义。PROJ-IMAGE-LIMITS

16. 源码级风险：一个 Optional Unit 可以让 Ordinary History 不可用

这不只是 failing domain 内部的 corrupt state：process-wide registry 的 all-unit fold 允许一个无关 projection 阻断基础 transcript read。Fail-loud 是否符合预期需要明确产品决策；当前 carrier 行为并不一致。

17. 设计评价与验证状态