fix(chat): recover managed turns after the Chat process exits

[loopx-agent]

What changes

If an owned Chat process exits while a Turn is active, restoring its HTTP listener used to leave the saved Turn permanently busy. This change positively verifies that the original same-host executor died, fences recovery against execution with the existing kernel lock, and asks the existing TypeScript managed-Turn owner to terminalize that exact Turn. The original Session and history remain usable; no model request is automatically replayed.

Repeated packaged-App qualification also exposed a frontend race: the old four-attempt SSE reader exhausted its 1.75-second backoff before a healthy replacement listener was ready, leaving “Load failed” instead of the saved interruption. The existing read-only event reader now covers the measured restart window, resumes from its cursor after EOF/refused connections, and preserves the typed reconnect route when an outage persists. Six fast attempts have 7.75 seconds of total backoff; the existing four silent-watchdog limit and immediate caller cancellation remain intact.

Independent review also reproduced a transient-recovery failure: taking the execution fence overwrote the dead executor record with the nonexecuting recovery process, then marked it released when the typed decision failed. Recovery now takes that same kernel fence while preserving the original holder metadata, and rechecks its death after acquisition. Temporary decision or initial terminal-write failure leaves proof for a later snapshot, event reconnect or explicit follow-up to finish recovery. The helper’s default recording behavior is unchanged.

Live executors, unknown/legacy lock ownership, foreign-host locks and attached sessions are not taken over. Recovery does not add a persisted lifecycle or permission setting. Python observes local execution facts; the existing TypeScript Turn owner decides eligibility. Clean nonterminal EOF now shares the established retry/error path rather than maintaining a separate immediate retry loop.

Visual evidence

Actual macOS QA App with the production Core/backend and bundled frontend, disposable synthetic conversation and synthetic stdio model transport. Original process-exit comparison: Core/assets bc8acdcdab25edbeff9ef7fed8e2c2b598070b28. Continuous-reconnect comparison: Core/assets 9c56742c7b227b86f56c5f34864e6af685557ab2; the final backend proof repair is 46048338d4aa848cef2225dd701cd4c9a8ee655d, separately repackaged and exercised below. These captures remain the same visual composition; they do not substitute for the new fault-injection evidence. This is private packaged qualification, not promotion of the official installed App, live-model qualification or Windows interactive acceptance. No private conversation or host paths are included.

Active process exit before	After: exact interrupted Turn, original conversation retained

Repeated recovery before	Repeated recovery after

Temporary QA endpoints were stopped after validation; these committed captures remain reviewable.

Validation

• Real macOS QA App: three alternating Status/Chat SIGKILL cycles (six owned process faults). The healthy peer PID remained unchanged each time. Chat listeners recovered in 1.83–2.07 seconds; all three pages automatically showed the correct interruption. Three explicit follow-ups completed in the same Session. Exactly six explicit sends produced six upstream Turn starts; none were replayed. Normal quit/reopen retained all six Turns and their errors/replies, with no new model start. Owned QA processes were cleaned up.
• Final backend/kernel qualification: 33 passed, 2 platform skips, including six decision/initial-write failure → snapshot/events/POST recovery combinations, exactly one terminal event, saved partial history and explicit same-Session follow-up without provider replay. A real replacement-holder race invalidates the earlier death observation; preserved metadata still excludes another kernel-lock acquisition. Active/steering/queue/startup/options/isolation regression: 126 passed.
• Final 46048338 package: strict source archive/frontend and the real private installer pass; actual native Status/Chat termination, automatic accurate interruption and same-Session follow-up pass again (listener 0.87s/1.73s, healthy peer unchanged, two explicit starts only). Owned processes were normally closed.
• New stream regression passes against the final transport; substituting the immutable pre-fix transport fails at the new listener-recovery oracle. Cursor retention, clean EOF, refused reads, bounded offline recovery and the existing abort/watchdog cases are covered. Dashboard TypeScript check passes.
• Standard premerge executes 19 selected checks and six direct checks without command failures; the overall merge gate remains failed on the required quality receipt/module-budget failure below.
• The existing chat-recovery packaged browser scenario passes. Strict committed-source frontend/archive verification and the real private production installer pass at 9c56742; the default CLI owner and official installed App are unchanged.
• Earlier process/HTTP tests (16), active/queue/steering/startup regressions (117), TypeScript Turn-owner tests (24), control-plane types, mypy and Ruff passed for the backend source, which is unchanged by this update.
• The measured line ceilings retain the useful backend recovery semantics: runtime base/head 2185/2230 lines (ceiling 2210→2230), store 2013/2016 (ceiling 2015→2016). No broad size waiver.

Required holds

This is a completed author proposal in normal review, not merge-ready. Required failures are retained:

• The exact kernel-static CI command fails on both immutable target main 105c4bc15091afac832495167cb98a1389951a04 and this product source: 1 failed, 6 passed, with 146 top-level modules against the pinned 145. Existing fix(packaging): restore top-level module budget #6768 proposes moving the new Ego delivery adapter to its owning subpackage; this PR neither duplicates that work nor raises the budget. Exact-scope quality receipt cqr_b6f2163d3a16c1c48d09 is non-passing because that required validator is still failed, and the broader optional type diagnostic below has not been qualified.
• Previous-head release/dashboard/chat-bundle browser logs fail in goal-showcase: a .goal-overview-objective lookup resolves both the declared Goal objective and delivery-contract objective. Existing test(ci): repair workspace, clock and oracle contract consumers #6766 owns the acceptance/fixture correction. Other failed browser shards are not all independently diagnosed here. These failures and fresh-head CI still require resolution/readback; passing native build jobs do not waive them.
• Repository-configured mypy passes on its 17 files, and the changed file-lock provider passes its scoped typecheck. An additional explicit-file mypy invocation expanded through the legacy Chat import graph and failed with 4939 errors across 577 files. That broader diagnostic is untriaged, retained as failed in quality evidence, and is not waived by the narrower passing checks.
• Independent exact-head review, required CI/readiness and maintainer merge authority remain outstanding. This proposal makes no official install/release claim; full cross-platform and sustained startup/update acceptance remains open.

中文：修复 Chat 退出后旧回合卡住，、连续恢复时前端过早放弃只显示“Load failed”，以及首次恢复判定失败消耗原执行证据的问题。实际打包候选连续三轮恢复、原会话续聊和重开历史通过；没有自动重跑。首屏/前后图直接纳入描述。既有必需 CI 失败仍阻塞合并，未替换正式安装。

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

动机

桌面用户在执行中的 Chat 服务被替换后，需要在原会话看到中断原因，并能继续提出下一条请求。旧行为是 listener 已恢复、保存的 Turn 却一直 busy，用户只能等待或另开会话。本 PR 打算用确切的本机进程死亡证据结束旧 Turn，保留已保存的输入、部分回答和历史，不自动重放发送。

正常死亡恢复和同会话续聊已经有实际通过的证据，但失败后的自动重试尚不可靠：首次判定暂时不可用，就会把恢复所需的死亡证据消耗掉。当前可观察结果仍可能是原 Turn 永久 busy。正式安装、跨平台和长期运行不是本次结论覆盖的范围；这项具体重试缺口属于当前修复本身。

改动思路

保留 TypeScript 生命周期判定、Python 进程观察和现有 store/event 收尾路径，方向合适。执行 worker 持有同一 Turn 的内核文件锁；恢复方先核对已死亡的本机持有者，再尝试取得该锁，重新读取会话与 Turn，交给 typed owner 判断。仅仅没有本地 adapter、网络断开、foreign host 或旧回合请求都不应该成为终结依据。

这套机制不需要新设置或另一套生命周期 owner。更小的“重连就失败”或超时回收会误伤仍在运行的执行者；完全不修又保留原阻塞。当前 PR 边界应是：取得真实死亡证据后，普通读取、事件重连和下一次发送都能安全、可重试地完成原会话恢复。问题在于临时恢复锁和原执行证据使用同一 holder 记录，恢复还未成功就被覆盖；这需要在现有 owner 内修复，而不是增加用户确认或重发原请求。

具体改动

完整差异为 16 个文件、增加 412 行、删除 41 行，包含五张公开合成 QA 截图、模块行数基线、七个生产文件及三个测试文件。五张图片已逐张查看，description 也明确测试代码版本与独立 QA App 边界；它们展示正常恢复，不证明故障重试、正式安装或所有平台已经合格。

规范依据是改动前 docs/development/frontend-delivery.md，spec_revision：105c4bc15091afac832495167cb98a1389951a04。其中 Task-first delivery / 从用户任务开始 要求同一任务经过真实失败/恢复和结果读回：普通子进程死亡、HTTP 事件和续聊部分通过；临时判定失败后再次恢复这一项 not_met。既有 Desktop README 的 Coexistence With 章节同时明确原生 shell 不重放会话，持久 Session/Turn 恢复归 Core；本次仍复用该边界。

关键代码讲解

• ChatRuntimeController._run_turn 在 queued→starting 之前取得 Turn 专属执行锁，直到 worker 退出才释放；未取得锁时不派发 provider。
• recover_exited_turn 在三个现有 HTTP 入口调用。它核对死亡记录、取得同一个锁，再读当前 active identity；临时异常会经过锁的 finally，这正是下面阻塞项的触发位置。
• mayRecoverChatTurn 只允许 managed、owner_dead、非 closed、准确 active Turn 且处于 starting/running/interrupting；Python bridge 仅投影事实，不另定生命周期规则。
• _fail_turn 继续使用既有状态更新、turn.failed、错误消息和 active claim 释放路径。SERVER_RESTARTED_MESSAGE 去重保留原语义。

新增的 streamChatTurn 差异已独立核验：非终结 EOF 和 refused fetch 走相同重连路径，六次快速尝试总 backoff 为 7.75 秒；四次静默 watchdog 和 caller abort 仍保留。生产 bundle 与原 stream smoke 通过；额外把基线/当前导出的生产 transport 接到真实 HTTP fixture：首条事件后 listener 停两秒，基线约 1.5 秒以 raw fetch error 退出，当前约 3.8 秒从同一 cursor 收到 server_restarted；持续断线则六次读取后返回带原 Session/Turn/events_url 的 typed reconnectable 错误，所有请求均为 GET。这是实际网络与生产 transport 验证，服务端是合成 SSE fixture，不冒充 Core 生命周期或原生 App；后者由前述独立进程/HTTP 与缺陷复现分别验证。该 frontend 修复有效，但不会修复后端 holder 被覆盖的问题。

对主干的风险

[P1] 首次恢复失败会永久丢失后续恢复资格。 在真实 spawned worker 持久化部分回答后 SIGKILL，初始 holder 为 dead。我只向 TypeScript decision transport 注入一次 EffectRuntimeStartupError，没有伪造策略结果；try_exclusive_file_lock 已把 holder 改为恢复进程，并在异常退出时标记 released。移除故障后，真实 typed owner 对同一 durable 状态仍返回 allowed=true，但第二次 recover_exited_turn 因 holder 已是 released 直接返回。实测 Turn 仍 starting、active_turn_id 仍匹配、turn.failed 数为 0。恢复执行者本身的死亡证据被一次未完成的读消耗，重新连接、读取或下一条发送均不能补救。

最小修复是在原 owner 内保留可重试的原执行死亡证据，直到终结成功；不要把任意 released 锁当死亡，也不要取消 live/foreign/unknown 和准确 identity 保护。增加“首次 typed 判定或收尾暂时失败→依赖恢复→重复原 HTTP 入口→恰好一个 terminal event→同会话续聊”的回归，保留无自动 provider 重放。重跑 uv run --extra test python -m pytest tests/test_chat_process_recovery.py -q 并覆盖上述新用例。

初始 91d 头的 133 项 Python 和 24 项 TS 测试通过，原 128 项普通回归在不可变基线也全部通过；新头全部后端、测试及相关 caller 的 blob 不变，明确复用这批证据。临时故障反例在当前 92c 准确头重新执行，结果仍为 dead→released、原 Turn starting/active、零终结事件。当前 TS typecheck、生产 UI build 与改动 Python 的 Ruff 通过。额外实际进程/记录反例确认 live、foreign、不可读、released 和错误 Turn 不被回收，正常死亡终结及重复读取不重复事件。当前头标准 premerge 的 19 项选择检查和 6 项直接检查通过，包含语义清单、边界扫描与维护性检查。模块实际行数 2185→2229、2013→2016 与新增恢复调用一致；提高的是披露过的回归基线，没有以删语义或搬空 helper 隐藏增长。通过这些检查仍未覆盖前述异常重试，因此不能替代修复。另行执行的必需模块预算在基线和当前头均为同一 workflow_skill_install.py 导致 146/145、1 failed/5 passed；该因果路径未改，保留独立合并限制，不要求本 PR 扩大修复。按 wait_for_ci=false 未查询或等待 CI。

语义与 CI 对齐

复用既有 lifecycle、server_restarted 及文件锁词汇；新 bridge method 是既有 typed owner 的局部扩展，没有新权限、配置或通用模型观察器。这里的问题是 holder 生命周期与恢复语义不一致，不是文案、遥测或测试条数问题。无 marker 的 legacy Turn、attached host 与活执行者继续保守保留；这些默认边界不应为了通过重试而放宽。

我的整体评价

REQUEST_CHANGES。保留原会话、明确中断和显式续聊能改善用户任务，当前 owner 选择和模块增长也有理由；但暂时故障会重新造成无限 busy，持续工作与恢复体验的关键承诺仍未证明。保留同一套 owner，补上失败后可重试和一次收尾，即可在这条有界路径重新评估，无需扩大成跨平台改造或新的恢复框架。没有独立运行作者的原生 QA App、签名安装、付费模型或长期运行；现有截图和作者声明不代替这些证据，也不授予合并权限。

English verdict: REQUEST_CHANGES — 92c9e69. A single temporary recovery-decision failure replaces the dead executor marker with a released recovery marker; subsequent reads leave the original Turn active despite the restored typed owner allowing recovery. Preserve retryable death evidence and prove one terminal event plus same-session continuation. The ordinary process/HTTP tests and premerge pass but do not cover this failure.

[loopx-agent]

[P1] Keep the dead-executor evidence retryable until recovery commits. A real spawned worker was killed, then one temporary TypeScript decision transport failure was injected. Acquiring this lock overwrites its dead holder and finally marks the recovery holder released. After restoring the real typed owner (allowed=true), every later recovery read skips at the liveness check: the original Turn remains starting/active and has zero turn.failed events. Preserve the original death fact across failed decisions/terminalization without treating arbitrary released/live/foreign/unknown locks as dead. Add a fail-once→restore→same-entry retry test proving one terminal event and explicit same-session continuation without replay.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

动机

桌面用户需要在执行中的 Chat 服务退出后，留在原会话读到准确中断原因并继续工作。旧行为是 listener 已恢复，保存的回合却一直 busy，用户只能等待或另开会话。本次正常恢复保留输入、部分回答和历史，并允许显式续聊。

当前临时判定失败已能安全重试；后续收尾写失败仍可能留下 failed 回合的 active claim，或者缺失终结事件。原先“死亡记录被恢复进程覆盖”的反例已关闭，这次阻塞是状态已经写成 failed 后，尚未完成的收尾再也不会被重试。评审覆盖当前源码中的恢复交付；正式安装、跨平台、真实模型和长期运行另有验收边界。

改动思路

复用现有 TypeScript 回合生命周期判定、Python 本机进程观察和内核文件锁，归属合适。执行 worker 持锁覆盖其实际工作；恢复方在确认本机原执行者死亡后，取得相同 fence，保留 holder 记录并再次核死，随后由 typed owner 判断准确 Session/Turn。它没有另建生命周期、配置页或权限来源。

保持现有 owner 是合理的当前 PR 边界：仅根据 listener 断开或没有 adapter 来回收会误伤仍在执行的工作；不修又会保留已确认的无限 busy。新增的 preserve_holder 仅供非执行恢复使用，普通调用仍记录当前持有者并在退出时标记 released。独立对照证明既有 Turn lane 的同 lane 排斥、另一 Agent 正常执行、释放和下一轮获取均保持相同结果。

下面是当前准确头的执行观察，表格仅概括已有实验：

暂时失败位置	恢复依赖后重读 snapshot/events
TypeScript 判定 transport	原 claim 释放，恰好一个失败事件；显式续聊完成
终结事件 append	回合已 failed，claim 仍指向它，原事件和 SSE 均零个失败事件
释放 active claim	已有一个失败事件，claim 仍指向 failed 回合

三种情况之后显式 POST 续聊都能完成，只有一次显式 provider start；这不补回第二行永久缺失的旧回合事件，也不能替代自动读取应完成的恢复。

具体改动

评审完整 105c4bc15091afac832495167cb98a1389951a04 → 46048338d4aa848cef2225dd701cd4c9a8ee655d：17 个文件，+545/-53，包括八个生产文件、三个测试文件、模块行数基线及五张公开合成截图。相对上次 92c 头，实际新差异仅为 runtime、共享文件锁、恢复测试和行数基线；其他 13 个文件的 blob 不变。没有继承先前结论。

规范依据是改动前的 task-first delivery，spec_revision：105c4bc15091afac832495167cb98a1389951a04。Task-first delivery / 从用户任务开始 要求同一任务经过真实故障、恢复与结果读回：普通死亡、首次判定/初始写失败和显式续聊 implemented；终结状态写入后恢复剩余收尾 not_met。既有 Desktop Coexistence With 约定 将持久会话恢复归 Core，shell 不重放请求；本次保留这个边界。

关键代码讲解

• _run_turn 在 queued→starting 前取得专属 execution lock，直到执行结束才释放；未取到锁时不启动 provider。
• try_exclusive_file_lock 的新参数默认为 false。恢复分支只持有相同 kernel fence，不覆盖/释放原 holder；默认分支仍执行原 metadata 行为。
• recover_exited_turn 在 snapshot、events、POST 三个入口运行。持锁后重新读取 holder 和持久状态，修复前次死亡观察与 replacement holder 之间的竞态。
• mayRecoverChatTurn 仍只允许准确 active managed 回合的 starting/running/interrupting；failed 会直接拒绝。与非原子 _fail_turn 收尾组合后产生下面的 P1。
• streamChatTurn 统一非终结 EOF 和 refused fetch 的只读重连。六次快速尝试共 7.75 秒 backoff，保留四次 watchdog 上限、cursor、caller abort 和 typed reconnect 路由。

前端 source、stream smoke、五张 PNG 及相关消费路径与上次已检查的 92c 字节相同，明确复用当时的生产构建、逐图检查和真实 HTTP transport 对照：两秒 listener 停机时基线约 1.5 秒 raw error，修复约 3.8 秒从原 cursor 收到保存的中断；持续停机六次后返回 typed reconnectable，全部为 GET。当前新增后端另以真实 worker/store/HTTP 验证，不把该合成 SSE 服务当作 Core 或原生 App。PR 描述直接展示五张图，并披露其实际代码版本与私有打包候选边界；视觉素材没有因后端头变化而伪称重新拍摄。

对主干的风险

[P1] 状态已终结、收尾尚未完成时，后续读取永远跳过修复。 在真实 spawned worker 已持久化部分回答后 SIGKILL，从原 HTTP snapshot 触发恢复。我分别只向 append_event(kind="turn.failed") 和 release_active_turn 注入一次暂时 OSError。真实 _fail_turn 已先成功保存 failed；依赖恢复后，snapshot 和 events 都返回 200，却因 typed owner 排除 failed 而不再进入收尾。前者保存事件及 SSE 的 turn.failed 数均为 0，后者事件数为 1，但两者 snapshot 的 active_turn_id 仍指向旧 failed 回合。显式续聊完成后，前者缺失的原终结事件仍未补齐。

触发位置是当前新增恢复入口调用既有多步 _fail_turn：先 update_turn，再 append_event、append_message、release_active_turn。保留死亡 holder 只保证第一步之前能重试，不能使已经提交的终结状态自动完成后续写入。当前六种新增故障用例覆盖判定和第一次状态写入失败，所以全部通过仍会漏掉这个窗口。

最小修复是在现有 Core/store owner 内支持对已持久化的确切 server_restarted 结果幂等补齐事件、错误消息和 claim 释放，并维持一次终结与原 Session/Turn 保护。不要为此将任意 failed/released/foreign 回合放开成新的死亡或执行权限。增加真实 HTTP 首次事件、消息、claim 写失败后的重试用例，断言旧 claim 清除、恰好一个终结事件和错误消息、原部分历史、显式续聊以及无自动 provider replay；重复读取不增加副作用。重跑 uv run --extra test python -m pytest tests/test_chat_process_recovery.py -q。

当前独立执行：34 项进程/锁测试通过，2 项 Win32 长路径检查在 macOS 按平台跳过；128 项 Chat active/queue/steering/startup/ordinary 回归、24 项 TS owner 测试、配置 mypy 17 文件、file-lock scoped mypy、Ruff，以及标准 premerge 的 19 项选择/6 项直接检查通过。额外三种真实 HTTP 故障反例为 1 通过、2 失败，未用绿色套件覆盖这两项失败。live、foreign、不可读、released、错误 Turn 均未被回收，正常死亡及重复读取一次收尾；共享锁基线为 22 通过/同 2 平台跳过，普通 lane 完整归一结果在 base/head 相同。

另行执行的必需模块预算仍为同一 workflow_skill_install.py 导致 146/145、1 failed/5 passed；不可变 base 的原失败身份、细节、模块列表、offender、预算及检查器与当前头一致，判作 pre_existing_unrelated，但保留独立 CQR/合并限制。runtime 实际 2185→2230、store 2013→2016，行数预算的增长与保留的恢复语义对应。作者额外展开 legacy import 的 4939 条 mypy 失败仍是未归因的作者质量记录；上述窄检查没有将它改判通过。按 wait_for_ci=false 未查询、轮询或等待 CI。

语义与 CI 对齐

复用既有 managed 生命周期、server_restarted、holder liveness 与锁策略词汇；扩展现有 typed method 和共享 helper 的局部参数。没有新权限、配置 authority 或通用调度规则。状态终结与事件/claim 的一致性是当前恢复契约，不能把未完成的持久化当作解释性提示；需要修复同一 owner 的重试收尾，而非扩充状态词表或放宽门禁。

我的整体评价

REQUEST_CHANGES，绑定 46048338d4aa848cef2225dd701cd4c9a8ee655d。先前覆盖死亡记录的缺陷已经实证修好；完整方案的 owner、默认边界和有限代码增长有理由，删除重复 EOF 分支也属于适当的同域整理。但部分收尾失败仍损害持续工作与自动恢复读回，long_horizon 和 user_experience 的当前交付判断均为 not_yet_proven。补齐现有持久化路径即可重新评估，不需要跨平台重构或另一套恢复框架。当前独立证据没有覆盖作者原生 QA、正式安装、真实模型或长期净益；它们也不替代已复现的具体阻塞。

English verdict: REQUEST_CHANGES — 4604833. The previous dead-holder overwrite is fixed. However, a temporary terminal-event append or active-claim release failure occurs after the Turn becomes failed; subsequent real snapshot/events reads reject recovery and never finish that partial terminalization. Complete it idempotently under the existing owner and prove exactly one terminal event, cleared claim and explicit same-session continuation without provider replay. Local regression/premerge passes and the unchanged module-budget hold remain separate evidence.

[loopx-agent]

[P1] Resume partial failure finalization after the terminal status has committed. A real spawned/killed worker was recovered through GET snapshot; injecting one temporary OSError in append_event(kind="turn.failed") or release_active_turn lets _fail_turn first persist status=failed. Once the dependency is restored, snapshot/events both return 200 but mayRecoverChatTurn rejects failed and this call is skipped forever. The event-append case retains the old active claim and has zero saved/SSE terminal events, even after a successful explicit follow-up; the claim-release case keeps the stale claim despite one event. The new six fault tests stop before the status commit and miss this window. Under the existing owner, idempotently finish the exact server_restarted event/error/claim effects without treating arbitrary terminal or released holders as new recovery authority. Add real HTTP retry tests after event/message/claim write failure, proving exactly one terminal event/error, cleared claim and no automatic provider replay.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @loopx-agent.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Reviewer: model_agent; provider=OpenAI; runtime_reported

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

评审 6772@2187fca7d1878d0bcb35c64a26c052e99731eb27。上一轮 P1 是「状态已写成 failed 后，剩下的收尾写失败就再也不会被重试」；本头在既有 owner 内补齐了这条幂等收尾，并把 main 合入解决冲突。

动机

受影响的是 Chat 服务进程退出后留在原会话的用户。恢复方确认本机执行者死亡后调用既有多步收尾：先 update_turn(failed)，再写 turn.failed 事件、错误消息、释放 active claim。若后三步中任一步遇到一次暂时性存储错误，回合已经是 failed，而 typed owner 只允许 starting/running/interrupting 被恢复，于是后续 snapshot/events 读取再也不会进入收尾：claim 可能一直指向这个已失败回合，或者 turn.failed 事件与错误消息永久缺失。

改动思路

不为失败回合开放新的执行或死亡权限，只在现有 Core/store owner 内补一个精确的收尾补全：当恢复入口读到「managed 会话 + turn.status=failed + error_code=server_restarted」时，把该结果缺失的部分幂等补齐——事件与错误消息仅在不存在时追加，claim 仅在当前回合仍持有它时释放。turn 不会被重新打开，也不会启动或重放 provider。

合入 main 时只有 loopx/chat_runtime.py 冲突，原因是 main 把同一段恢复代码包进了 commit() 事务、并把错误文案内联，而分支抽出了 SERVER_RESTARTED_MESSAGE 常量；解决方式是保留 main 的事务结构与缩进，同时使用分支的常量。

具体改动

4 个文件、+153/−1：

• loopx/chat_runtime.py：recover_exited_turn 在 typed owner 拒绝后调用新增的 _complete_recovered_terminalization；该 helper 严格限定 managed + failed + server_restarted，先用 events_after / messages 判断是否已有 turn.failed 与错误消息，缺失才追加，最后只在 active_turn_id == turn_id 时调用 release_active_turn。
• tests/test_chat_process_recovery.py：新增三条真实 HTTP 反例，分别在 append_event、append_message、release_active_turn 注入一次 OSError；随后通过真实 snapshot 触发重读，断言 claim 清零、恰好一个终结事件与一条错误消息、部分回答仍在、重复读取不新增写入、显式续聊可完成且 provider turn/start 仍为 1 次。
• tests/test_chat_event_retention.py：该文件自建裸 server 直接请求 events 端点，而本 PR 让该端点先调用恢复；补一个只实现 recover_exited_turn 与 close 的 stub。
• loopx/canary/module_metric_baseline.json：runtime 行数上限按本次接受的增长从 2230 刷新到 2312（any_count 仍为 36，未超 37）。

对主干的风险

补全只在「该回合已经是本次恢复写下的确切 server_restarted 失败」时执行，不会把任意 failed/released/foreign 回合变成新的死亡或执行授权；同时保留了单次终结与 Session/Turn 绑定。实测：tests/test_chat_process_recovery.py 15 项通过，撤掉修复后新增的 3 项全部失败（例如 claim 未释放）；tests/test_chat_event_retention.py 16 项通过；chat 操作/活动/事件/输入校验/后台清单五文件 130 项通过；TS chat_turn_acceptance.test.ts 24 项通过；维护性 ratchet 为 ok（unreviewed 0）；ruff 与 git diff --check 干净。未查询或等待托管 CI；真实 Windows、已安装产品与长期运行仍不在本轮资格内。

我的整体评价

结论 APPROVE。P1 的两条具体表现（缺失终结事件、claim 未释放）都被同一处幂等收尾覆盖，并用真实 killed worker + 真实 HTTP 读取验证；修复边界没有放宽 typed owner，也没有重启或重放 provider。

English verdict: APPROVE - 2187fca. Partial server_restarted terminalization is now completed idempotently under the existing owner, the three new post-failure windows fail without the fix and pass with it, and 130 chat plus 24 TS tests, the maintainability ratchet, ruff and diff checks are green.