review fix: distinguish checkpoint settlement

docs/core-data-structures/persistence.md

@@ -6,7 +6,7 @@ The seam is a textbook [capability seam](../rfc/implemented/architecture/2026-06
 
 ## The flush checkpoint
 
-`session/event` is a *synchronous* notification; persistence plugins buffer it (write-behind) and drain at the awaited `session/flush` checkpoint the loop fires at every turn end. Flush is `ctx.parallel` (awaited): a turn's events are durably committed before the next turn starts, and the turn boundary is the commit boundary. A rejecting flush is reported via `agent/error` and the logger — never as a session event (it would land past the commit boundary), so the backend keeps its buffered events for the next flush.
+`session/event` is a *synchronous* notification; persistence plugins buffer it (write-behind) and drain at the awaited `session/flush` checkpoint the loop fires at every turn end. The next turn waits for that checkpoint to settle. A successful flush durably commits the closed turn as one unit; a rejecting flush is reported via `agent/error` and the logger — never as a session event (it would land past the closed turn) — and does not prevent the next turn, while the backend keeps its buffered events for the next flush.
 
 ## Crash recovery preserves an interrupted turn
 

docs/persistence-catalog.md

@@ -293,7 +293,7 @@ Source: [`packages/core/session/src/types.ts:276`](../packages/core/session/src/
 
 #### `turn/end` — log-only
 
-Closes turn `turn` with the TurnEndReason that ended it. The loop fires the awaited `session/flush` checkpoint at every turn end, so the turn boundary is also the durable-commit boundary.
+Closes turn `turn` with the TurnEndReason that ended it. The loop fires the awaited `session/flush` checkpoint at every turn end; the next turn waits for settlement. Success commits the closed turn; rejection is reported live and does not prevent later work.
 
 ```ts persistence-catalog
 'turn/end': { turn: number; reason: TurnEndReason }

docs/rfc/implemented/simplification/2026-07-17-one-send-one-turn.i18n.yaml

@@ -3,4 +3,4 @@
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write
 2026-07-17-one-send-one-turn.md: 232e91b1d13ed07f230ffc2d0a190adafb29c6e2
-2026-07-17-one-send-one-turn.zh.md: b4dc8d37a0dc03a8aae1abfab4c9d473c7afd332
+2026-07-17-one-send-one-turn.zh.md: c533e0fa35a73056b2bb5ae6ca8a53e5757c55cf

docs/rfc/implemented/simplification/2026-07-17-one-send-one-turn.zh.md

@@ -8,17 +8,17 @@ Status: implemented
 
 每次普通 `Agent.send()` 接受的载荷都是一条完整的调用方消息。如果机会式地把所有待处理载荷放入同一个轮次，相邻调用是否共享边界就会取决于驱动器的运行时机：即使调用方使用相同 API，来自同一个同步调用栈、相邻微任务、事件监听器和模型回调的调用也可能产生不同分组。
 
-轮次拥有提示词准入、`turn/start`、`turn/end` 和持久性检查点。合并消息会让后一条消息加入前一条消息的模型请求，无法观察前一轮次关闭后写入同一会话日志的结果；获准与被阻止提示词的混合还会引入调用方从未显式请求的生命周期状态。
+轮次拥有提示词准入、`turn/start`、`turn/end` 和持久性检查点。合并消息会让后一条消息加入前一条消息的模型请求，无法观察同一会话日志中前一个已关闭轮次的结果；获准与被阻止提示词的混合还会引入调用方从未显式请求的生命周期状态。
 
 `steer()` 已经用于表达加入当前轮次，`inject()` 则记录面向模型的上下文而不充当普通消息。隐式批处理会让 `send()` 与这两种显式操作产生语义重叠，无法保持单一含义。
 
 ## 决策
 
-每次成功的 `send()` 都会同步校验 agent（智能体）状态、创建并冻结内容快照、追加一个独立的 FIFO 队列项，然后发布 `agent/queued`。agent loop（智能体循环）在每个轮次开始时最多取出一个普通队列项。如果两个队列项最终都被认领，第二个轮次只能在第一个轮次结束且其持久性检查点处理结束后开始；广义取消、dispose（资源释放）或启动前失败可以丢弃尚未启动的队列项，而不创建空轮次。
+每次成功的 `send()` 都会同步校验 agent（智能体）状态、创建并冻结内容快照、追加一个独立的 FIFO 队列项，然后发布 `agent/queued`。agent loop 在每个轮次开始时最多取出一个普通队列项。如果两个队列项最终都被认领，第二个轮次只能在第一个轮次结束且其持久性检查点处理结束后开始；广义取消、dispose（资源释放）或启动前失败可以丢弃尚未启动的队列项，而不创建空轮次。
 
 提示词准入只处理一条消息。获准提示词成为该轮次的 `user/message`；被阻止提示词追加一条持久的 `prompt/blocked`，并让这个单消息轮次以 `rejected` 结束。实现中没有混合批次或全阻止批次分支。
 
-运行中的 `steer()` 会把消息追加到当前轮次的 steering（中途引导） FIFO。空闲时的 `steer()` 委托给 `send()`，因此创建一个独立的普通队列项。`inject()` 保持现有的轮次封闭与持久化刷新行为。`cancel()`、`status` 和 `whenIdle()` 仍是面向整个智能体的操作，不变成逐消息控制。
+运行中的 `steer()` 会把消息追加到当前轮次的 steering（中途引导） FIFO。空闲时的 `steer()` 委托给 `send()`，因此创建一个独立的普通队列项。`inject()` 保持现有的轮次封闭与持久化刷新行为。`cancel()`、`status` 和 `whenIdle()` 仍是面向整个 agent 的操作，不变成逐消息控制。
 
 ## 曾考虑的替代方案
 
@@ -28,11 +28,11 @@ Status: implemented
 
 - 单元与性质覆盖固定了同一调用栈、相邻微任务、不同来源和重入 `send()` 的行为：每个轮次只有一条消息，并按 FIFO 排序。
 - 延迟第一个轮次的持久化刷新可以证明下一个排队轮次不能在检查点处理结束前开始，且其请求能看到前一条助手结果；刷新即使失败，下一轮次也要等它结束后才会开始。
-- 提示词否决、监听器失败、广义取消、资源释放和 `turn/start` 提交前失败都会保持已记录轮次边界平衡，不会合并消息或让仍应处理的排队工作滞留。
-- 运行中与空闲时的 `steer()`、`inject()`、面向整个智能体的状态和 `whenIdle()` 保持原有覆盖。
+- 提示词否决、监听器失败、广义取消、dispose 和 `turn/start` 提交前失败都会保持已记录轮次边界平衡，不会合并消息或让仍应处理的排队工作滞留。
+- 运行中与空闲时的 `steer()`、`inject()`、面向整个 agent 的状态和 `whenIdle()` 保持原有覆盖。
 
 ## 后果
 
-普通轮次边界是确定的，被认领的 FIFO 后继项会在前一轮次关闭且其检查点处理结束后观察会话中的结果；检查点处理结束不表示失败的持久化刷新已经成功。多个排队项仍可在同一个全局 `running` 区间内执行，广义取消也可以丢弃整个未启动队尾，因此状态和静止性仍是面向整个智能体的观察，而不是逐消息结果。
+普通轮次边界是确定的，被认领的 FIFO 后继项会在前一轮次关闭且其检查点处理结束后观察会话中的结果；检查点处理结束不表示失败的持久化刷新已经成功。多个排队项仍可在同一个全局 `running` 区间内执行，广义取消也可以丢弃整个未启动队尾，因此状态和静止性仍是面向整个 agent 的观察，而不是逐消息结果。
 
 依赖偶然批处理的工作负载会产生更多模型请求和检查点，队列清空时间也可能延长；持续有消息进入时，FIFO 队列还可能增长。只有建立显式且经过测量的契约后，才能重新引入吞吐量优化。

packages/core/agent-loop/tests/properties.spec.ts

@@ -114,7 +114,7 @@ describe('agent loop scheduling properties', () => {
 
           // No message lost: every send appears as a user/message, in order.
           expect(userMessageTexts(agent)).toEqual(texts)
-          // Every successful send owns an independent turn even before the driver wakes.
+          // This failure-free fixture claims every item into an independent turn.
           expect(turnNumbers(agent)).toEqual(texts.map((_, i) => i + 1))
           expect(turnEndNumbers(agent)).toEqual(texts.map((_, i) => i + 1))
           expect(userMessageCountsByTurn(agent)).toEqual(texts.map(() => 1))
@@ -172,7 +172,7 @@ describe('agent loop scheduling properties', () => {
 
           // No message is lost or reordered, regardless of driver timing.
           expect(userMessageTexts(agent)).toEqual(steps.map(s => s.text))
-          // Every send owns exactly one turn, numbered in FIFO order.
+          // Every item is claimed and therefore owns one FIFO-ordered turn.
           const turns = turnNumbers(agent)
           expect(turns).toEqual(steps.map((_, i) => i + 1))
           expect(turnEndNumbers(agent)).toEqual(turns)

packages/core/session/src/types.ts

@@ -221,8 +221,8 @@ export interface SessionEventMap {
   'turn/start': { turn: number; trigger: TurnTrigger }
   /**
    * Closes turn `turn` with the {@link TurnEndReason} that ended it. The loop
-   * fires the awaited `session/flush` checkpoint at every turn end, so the turn
-   * boundary is also the durable-commit boundary.
+   * fires the awaited `session/flush` checkpoint at every turn end; the next turn waits for settlement.
+   * Success commits the closed turn; rejection is reported live and does not prevent later work.
    */
   'turn/end': { turn: number; reason: TurnEndReason }
   /** Opens step `step` of turn `turn` — one model call plus the tool executions it requested. */