fix(turn): project durable completion continuation in built-in CLI provider

[liubf21]

Concrete gap

Current main already defines and validates the governed successor, active_goal, and no_followup completion outcomes. The loop controller also enforces successor lineage and fresh terminal-frontier evidence.

The remaining gap is narrower: loopx turn run-once's built-in completion_writeback calls complete_goal_todo(...) but always journals active_goal. It does not project the durable outcome that the Todo lifecycle actually wrote.

Proposed provider-only slice

• derive the completion outcome from persisted Todo lifecycle state after complete_goal_todo, never from host result JSON;
• project successor only for existing declared successor Todo ids, and no_followup only when existing Todo policy/authority has durably recorded it;
• preserve the existing completion_turn_key replay fence and settlement ordering;
• keep goal termination downstream: a fresh loop-controller decision remains required for terminal closure;
• add focused CLI/recovery fixtures for successor/no-followup projection and idempotent replay.

Non-goals

• no new result schema, Todo/event store, scheduler, or host-granted continuation authority;
• no arbitrary successor creation from Host text;
• no change to existing loop-controller continuation semantics.

Maintainer question

Is this provider-state projection a distinct, acceptable follow-up to #2882/#3024? If so, implementation will be limited to the built-in Turn CLI provider plus a pure durable-outcome projector and focused tests.

[liubf21]

Closing as redundant after mapping current main: the governed completion contract already accepts successor, active_goal, and no_followup outcomes, while the loop controller validates declared successors and requires fresh terminal frontier evidence for no_followup. A future follow-up should identify a concrete provider-policy or missing-fixture gap rather than duplicate this contract.

[huangruiteng]

Thanks for the detailed write-up — I re-verified the claim against current main (61652670, post-#3040/#3042) and I think the picture is slightly more precise than "redundant": the governed contract already supports all three outcomes, but the built-in CLI provider still hardcodes active_goal in its completion echo, so successor/no_followup are currently unreachable through loopx turn run-once's completion writeback.

Evidence

1. Provider echo is hardcoded. In loopx/cli_commands/turn.py (completion_writeback, run-once), the callback calls complete_goal_todo(...) without no_followup/successor_todo_ids and then unconditionally returns "completion": {"todo_id": ..., "continuation": "active_goal"}.

2. The durable lifecycle supports all three. complete_goal_todo(..., no_followup=..., successor_todo_ids=...) exists, and the completion payload persists completion_turn_key, no_followup, and successor_todo_ids (event_writeback.py).

3. Settlement validation accepts all three. require_loopx_turn_completion_outcome allows successor | active_goal | no_followup and requires non-empty successor_todo_ids for successor.

4. Loop controller enforces the strong semantics separately. no_followup requires fresh terminal-frontier evidence (no_followup completion requires fresh terminal Goal frontier evidence), and successor requires the selected todo to be in the declared successor list (stale_receipt: fresh decision is not a declared completion successor).

So the author-side note "the governed completion contract already accepts successor, active_goal, and no_followup" is correct about the durable contract — but because the provider always echoes active_goal, the built-in CLI path never produces the durable outcome the lifecycle actually recorded. That is a real (if narrow) provider-state projection gap, not just documentation drift.

Answer to the maintainer question

Yes — this is a distinct and acceptable follow-up to #2882/#3024, provided it stays provider-only and additive:

• derive the outcome from persisted Todo lifecycle state after complete_goal_todo, never from host result JSON (as proposed);
• project successor only for declared successor ids and no_followup only when durably recorded;
• keep the completion_turn_key replay fence and settlement ordering — note test(todos): fence cross-turn completion replay #3049 (merged) already fences cross-turn completion replay, so the slice should build on that, not re-roll it;
• keep goal termination downstream (a fresh loop-controller decision remains required).

One implementation detail worth keeping: the same derived outcome should be returned inside the completion payload that _completion_writeback_outcome/require_loopx_turn_completion_outcome validate, so the typed settlement sees the truthful continuation rather than a normalized active_goal.

I'd suggest keeping this issue open (or retitling it to the concrete provider slice) as the tracking item for that PR; happy to review the exact-head implementation when it lands.

[yuefengw]

我想认领这个 issue，并按维护者确认的 provider-only、additive 边界完成实现。

计划范围：

• 在 complete_goal_todo 后从持久 Todo lifecycle 精确重读 continuation，不采信 Host result JSON；
• 仅在已持久记录时投影 no_followup，仅对真实存在且已声明的 successor 投影 successor，其余保持 active_goal 或 fail closed；
• 保留 completion_turn_key replay fence、settlement 顺序及下游 fresh decision；
• 增加三种 continuation、dangling/矛盾状态和中断后幂等重放测试；
• 不新增 schema、store 或 scheduler，不从 Host 文本创建 successor。

如果 @liubf21 仍在推进，请告诉我，我会停止以避免重复；否则我会从最新 origin/main 建立独立分支并提交聚焦 PR。

[liubf21]

@yuefengw 感谢先让出认领。确认：我在推进这个 issue，无需担心重复。

已按维护者确认的 provider-only、additive 边界完成实现并提交 PR：

• PR: fix(turn): project durable completion continuation in built-in CLI provider #3195 — fix(turn): project durable completion continuation in built-in CLI provider
• 新增纯投影器 loopx/control_plane/todos/durable_completion.py：
  • read_persisted_todo_record：complete_goal_todo 后从持久 Todo lifecycle 重读记录（Markdown block 优先，event-sourced goal 走 event projection 回退），并收集 goal state 内的 Todo id 全集；
  • project_durable_completion_outcome：仅对真实存在且已声明的 successor 投影 successor，仅对已持久记录的 no_followup 投影 no_followup，其余 active_goal；no_followup+successor 矛盾、dangling successor、todo_id 不匹配、未 durably done 均 fail closed（ValueError）。
• turn.py 的 completion_writeback 改为从持久记录投影 continuation，不采信 Host result JSON；投影失败在 refresh writeback 之前返回 fail-closed payload，turn 以 writeback_failed 收尾、不消耗 quota。
• executor.py：typed settlement 透传 provider 的 fail-closed 具体原因（原为固定字符串）。
• 测试：11 个纯投影器单测 + 4 个 CLI 端到端（successor / no_followup 投影、dangling fail-closed 不 spend、durable writeback 与 quota spend 之间中断后的幂等重投影）。
• 边界保持：无新增 schema/store/scheduler，不从 Host 文本创建 successor；completion_turn_key replay fence 与 settlement 顺序不变；goal 终止仍由 loop controller 下游 fresh decision 决定。

欢迎 review。