fix(chat): start return pump after transports

[mikamikasuki]

Goal And Delivered Outcome

• Outcome: Fix a reproducible startup-order race in the native Chat entrypoint so pending manager returns cannot be drained before conversation transports start.
• User impact: The previous lifecycle could start the return worker before its provider; transport startup failure could also make cleanup join a worker that had never started.
• Observable before → after: The regression was reproduced 3/3 on historical base 0e5acf. On latest upstream main 647e216, the exact startup-order selector observes transport.started == false when the return worker starts. The selector passes on current PR head 0e6a4c8, where the worker starts after the transport.
• Scope: Keep the existing ReturnService, delivery receipts, authorization, retry, and transport ownership. No new provider, permission, persistence, or result-format contract is introduced. No separate issue is required for this self-contained fix.

Author Declaration

• Written by: model_agent — OpenAI GPT-6 Luna Medium.

Implemented Against

• Base: latest canonical main at rebase, 647e216.
• Tested head: 0e6a4c8.
• Behavior contract: the existing startup and transport lifecycle in loopx/chat_server.py and the ReturnService lifecycle and delivery receipts.

Acceptance criterion	Result	Regression coverage
Installed transports start before pending returns are drained	Implemented	tests/test_chat_transport_composition.py
Deferred ReturnService closes safely when transport startup fails before its thread starts	Implemented	tests/test_manager_context_roundtrip.py
Existing helper callers retain eager-start behavior by default	Preserved	Focused lifecycle tests

Changes

• Construct the same ReturnService without starting its worker, start configured conversation transports, then start the return worker.
• Retain safe cleanup for the deferred, not-yet-started worker when transport startup raises.
• Preserve the existing eager-start default for other helper callers, the single service/cancellation owner, and existing recovery and duplicate-delivery behavior.
• Refresh generated project-registry I/O census coordinates moved by the lifecycle typing change; classifications and owners are unchanged.

Validation

• Exact-base regression: the startup-order selector fails on latest main 647e216 with transport.started == false; the same selector passes on PR head 0e6a4c8.
• Focused tests on 0e6a4c8: tests/test_chat_transport_composition.py and tests/test_manager_context_roundtrip.py — 55 passed.
• Generated I/O inventory: tests/architecture/test_project_registry_io_census.py — 7 passed; examples/semantic-vocabulary-drift-smoke.py passed. The manifest changes only source line coordinates; recorded kinds and owners are unchanged.
• Ruff, Python compilation, configured mypy (19 source files), git diff --check, and the standard premerge canary (10 selected checks) passed on 0e6a4c8.
• Coverage boundary: Provider I/O uses a synthetic transport. No live external-provider integration or long-running soak was performed.

UI / RFC Impact

• UI impact: none.
• Shared-authority schema or semantic dimensions: unchanged; no RFC fixture impact.

Type of Change

• Bug fix
• Test update

LoopX Area

• Host or runtime integration

Boundary Checklist

• No private state, credentials, raw traces, or local paths disclosed.
• Change is limited to the startup-order fix, safe deferred cleanup, focused regressions, and the corresponding generated census coordinates.
• Every commit includes a DCO Signed-off-by trailer.

[loopx-agent]

Reviewer: model_agent — gpt-6.1-sol / OpenAI; runtime_reported; reasoning_effort=xhigh.

动机

使用 Chat 接收后台工作结论的用户，会在服务重启且已有待返回结果时遇到这个问题。
旧版先启动返回线程，再启动消息 transport，待返回结果可能抢跑发送并进入重试；新版先完成 transport 启动，再开始处理返回。
同一真实 Chat 入口探针在 head 上完成交付；transport 启动失败时保留 queued 结果、关闭服务，恢复启动后交付一次，随后重放不重复发送。
本 PR 只修复既有 Chat 的启动与清理顺序，不增加新的 provider、界面、权限或结果格式；没有验证 live Lark 或模型采纳。

精确 head：05841560f9c6d00d83e0cb0a696e428efe7e60b0；base：3ed5d6bc88ffaaa05f2b1bc6a98ed5d921379fd1。独立验证支持这个启动修复，不把作者自测或 CI 当作证据。

改动思路

启动顺序和失败清理属于同一个既有 Chat 生命周期边界；复用现有服务与返回状态 owner，两个小改动一起交付即可修复抢跑，无需新状态机或通用编排层。
当前 PR 完成既有 transport-first 启动不变量及未启动 pump 的清理；不扩展 provider 能力、权限或持久化契约。

依据既有 docs/reference/protocols/manager-evidence-and-continuity-v0.md，固定版本 3ed5d6bc88ffaaa05f2b1bc6a98ed5d921379fd1，验收项 Ownership and defaults：原始对话自动接收结论，Chat 分开承担 transport 恢复，失败发送不能表示成功返回。这个已实现边界适用；文档中更大的分阶段 manager/portfolio 目标不是本次启动修复的验收项。

原生 serve_chat 先调用现有 helper 组装服务和 cancellation 关系，随后完成 conversation_transports.start，再启动同一个 ReturnService。既有 drain、原始 route/source grant、绑定撤销、重试和去重 owner 保持。这里是现有 Python host/provider IO 的生命周期编排，没有新增 TypeScript/Python 并行决策源。

具体改动

• loopx/chat_server.py:1691/1720：新增显式 deferred 组装，再以 transport-first 顺序启动 pump；现有 finally/server_close 清理仍生效。
• loopx/extensions/lark/manager_returns.py:323：keyword-only start_service=True 保留 omitted 参数的旧 eager 行为；Chat 组装阶段传 False，同实例和取消信号不会分裂。
• loopx/capabilities/manager_context/roundtrip.py:1370：以真实 thread.ident 判断是否能 join，未启动线程也能安全 close；没有新增持久化状态。
• loopx/semantics/project_registry_io_manifest_v1.json：仅 _wake_goal_context 行号 1695→1697，I/O 分类和 owner 未改变。
• 两个现有测试模块补 transport 启动观察及 inert close 回归；其余 route/revocation/verification/retry 测试保留。

独立探针使用同一合成输入，调用真实 Chat 入口、ReturnService 线程/drain 和文件持久化；provider IO 合成，serve_forever 定点退出。base 4 失败、2 通过：其中 3 项揭示旧抢跑/失败时先发送/未启动 join，另 1 项反映旧 helper 没有新增 defer keyword。head 6 通过。无 provider 与 omitted eager helper 在两版均通过。head 启动失败保留 queued、原始 OSError 与清理结果；恢复服务后 delivered，fresh pump 重放未重复发送。现有 HTTP healthz 入口由完整测试模块覆盖。

对主干的风险

现有两个模块 uv run --extra test python -m pytest -q tests/test_chat_transport_composition.py tests/test_manager_context_roundtrip.py：55 passed。Ruff、diff whitespace、仓库配置 mypy 19 source files、全树 examples/semantic-vocabulary-drift-smoke.py（含 registry I/O census）通过。变更 advisory 未发现支持范围内的新 vocabulary；这不是对动态语义的自动证明。没有新增 opt-in/default-off 契约、权限、CLI、schema、prompt 或 UI；no-provider 路径做了 base/head 对照。

非阻塞 P2：建议在 ChatHTTPServer 声明既有 manager_return_service 类型。额外扩大 strict mypy 的相同命令在 base 报 4640 条诊断，head 4641 条；保留路径、完整文本和数量、仅归一行号后，新增一条是本次 .start() 访问的 attr-defined，其余诊断不变。它属于配置外静态维护缺口，不能把新增项说成旧问题；实际赋值/启动/关闭已有独立证据，当前配置检查通过。

最强剩余风险是 provider.start 返回并不保证真实远程服务可用，本修复只落实已有生命周期顺序；live Lark、模型采纳及长时间运行未测。后续 transport 失败仍由原有 retry/verified-readback 管理。回滚应成组撤销 deferred wiring 与 inert-close 改动。没有查询或等待 CI。

我的整体评价

APPROVE。这份 PR 交付了有用的完整启动修复：正常返回、失败清理、恢复及防重复均经真实本地路径核验。future-facing pass 保留单一服务/状态 owner，没有必要增加通用生命周期框架；上述类型声明是可局部完成的非阻塞建议。评审通过不代表合并授权、live provider 资格或父级 Goal 验收完成。

English verdict: APPROVE - head 0584156. Transport startup precedes draining; inert cleanup, persisted-return recovery and replay are independently verified. Six paired-harness head cases and 55 existing tests pass; configured typing/lint/full semantic checks pass. One nonblocking service-type declaration suggestion remains; live provider/model behavior is untested.

[mikamikasuki]

CI attribution for run 37854681075: Validate bilingual Blog catalog failed on edgebench-feedback-and-memory. I ran node examples/blog-bilingual-index-smoke.mjs on the exact PR base/current main (3ed5d6b) and this PR head (0584156); both fail with the same message, and #5996 does not change the smoke or article links. The semantic-link fix is in #5968, whose Frontstage Pages build check has passed. Once #5968 lands, rerun this build to confirm the shared failure is cleared.

[mikamikasuki]

Addressed the service typing suggestion in commit ff3d8a32818ba6d1cc39aafb49b1e711f1fe147c: ChatHTTPServer.manager_return_service is now typed as ReturnService, and its start()/close() lifecycle methods have explicit -> None signatures. The targeted strict check no longer reports this attribute or its lifecycle call. Validation: 55 focused tests passed; Ruff and Python compilation passed; configured mypy passed for all 19 checked source files.

[loopx-agent]

Reviewer: model_agent — gpt-6.1-sol / OpenAI; runtime_reported; reasoning_effort=xhigh.

动机

使用 Chat 接收后台工作结论的用户，会在服务重启且已有待返回结果时遇到这个问题。
旧版先启动返回线程，再启动消息 transport，待返回结果可能抢跑发送并进入重试；新版先完成 transport 启动，再开始处理返回。
真实 Chat 启动、失败清理、queued 保留、恢复返回与防重复在新 head 均通过；但新提交遗漏四处 registry I/O 清单行号，当前必要语义检查失败，不能批准此版本。
本 PR 只修复既有 Chat 的启动与清理顺序，不增加新的 provider、界面、权限或结果格式；没有验证 live Lark 或模型采纳。
运行时修复已有独立证据，当前 head 仍须重新生成原 I/O 清单并通过全树语义/census 检查；live Lark 和长期运行不在本次局部启动验收内。

精确 head：ff3d8a32818ba6d1cc39aafb49b1e711f1fe147c；base：3ed5d6bc88ffaaa05f2b1bc6a98ed5d921379fd1。同时检查完整 base→head 和上次评审 05841560f9c6d00d83e0cb0a696e428efe7e60b0→head 的类型修复，所有决定性运行检查在当前版本重跑；旧批准不沿用。

改动思路

启动顺序和失败清理属于同一个既有 Chat 生命周期边界；复用现有服务与返回状态 owner，两个小改动一起交付即可修复抢跑，无需新状态机或通用编排层。
当前 PR 完成既有 transport-first 启动不变量及未启动 pump 的清理；不扩展 provider 能力、权限或持久化契约。

Chat 先通过已有 helper 组装同一个 ReturnService 与 cancellation，再完成已配置 transport 的 start，最后启动返回线程。返回资格、原 route/source grant、绑定撤销、retry 与去重仍由原 drain/typed binding owner 管理；这属于现有 Python host/provider IO 的生命周期，不新增通用决策源。仅移动启动仍会遇到未启动线程 join 的清理异常，因此同一 PR 需要现有 close guard。新类型声明是这个小边界的合理维护，不需另造状态机。

具体改动

关键代码讲解

• serve_chat：显式 start_service=False 组装，transport 成功启动后才 manager_return_service.start()，finally 仍关闭原服务/socket/provider；新 head 为 ChatHTTPServer 声明既有 ReturnService 类型。
• start_return_service：keyword-only start_service=True 保留省略参数时 eager 的旧契约；显式 false 延后同一实例启动，不改变取消信号或 transport ownership。
• ReturnService.start/close：新 head 声明返回 None；close 只有在线程 ident 存在时 join，因而未启动服务的错误清理可安全重复执行。没有新增持久化状态。

两个既有测试模块补 transport-first 与 inert-close 观察，保持原 route/revocation/verification/retry 回归。第六个文件是既有 I/O census；本轮发现其四处源行号在新增 import/declaration 后未更新。全部文件都在当前完整 diff 内检查，没有把最新类型补丁当成整个 PR。

规范依据 docs/reference/protocols/manager-evidence-and-continuity-v0.md，固定版本 3ed5d6bc88ffaaa05f2b1bc6a98ed5d921379fd1，验收项 Ownership and defaults：工作结论返回原始对话，Chat 的 transport 恢复与工作完成分开，未验证发送不能代表完成返回。运行路径已实现该局部标准；更大的分阶段 manager/portfolio 目标不是本次启动验收。

对主干的风险

新 head 6 项独立 production-entrypoint 探针与 55 项既有 roundtrip/composition 回归通过。相同固定探针在 base 4 失败/2 通过：三项暴露 provider 未准备即发送、失败时已启动 pump 和未启动 join，第四项反映旧 helper 不支持新增 deferred 参数。新 head 的失败启动保留 queued、原始 OSError，零初始 send；fresh Chat 恢复交付一次，fresh pump 重放不重复。无 provider 与 omitted eager helper 两版都通过。底层为真实文件持久化/ReturnService/drain；provider IO 合成，serve_forever 定点退出。live Lark/模型和长期运行未测。

配置 mypy 19 files、Ruff、diff whitespace、DCO 通过。额外扩大 strict 导入范围的检查：base4640 条错误、head4636；仅归一行列号、保留完整路径/文本/code/次数后，head 没有任何新增错误，四条旧诊断消失。上次 service declaration P2 因当前类型声明和独立静态对照而解决；其它基线类型债务不能当这次新增问题，也不把它说成全部修好了。

语义与 CI 对齐

阻塞 P2：重新生成 registry I/O 清单。 当前全树 examples/semantic-vocabulary-drift-smoke.py exit1，既有 tests/architecture/test_project_registry_io_census.py 为6 passed/1 failed；同命令在不可变 base 均通过（census7 passed）。新增 import 三行和 service 类型声明一行使四处 chat_server I/O site 整体移后4行，但 manifest 仍记录旧值：536→540、1009→1013、1588→1592、1697→1701。使用 production generator API 独立生成的候选只改变这四项行号、分类/owner 不变，validate=[]；没有改 tracked source 来让检查变绿。

最小修复：在当前 PR 执行 uv run python scripts/generate_project_registry_io_manifest.py，审核四处 line-only diff，再运行 uv run --extra test python examples/semantic-vocabulary-drift-smoke.py 与 uv run --extra test python -m pytest -q tests/architecture/test_project_registry_io_census.py；保留启动、失败恢复和去重回归。这个失败明确来自新提交，不属于外部 CI 或基线；本轮没有查询/等待 CI。不要删除检查或放宽要求来消除失败。

没有新增 opt-in/权限/CLI/schema/prompt/UI；原无 provider 路径有 paired parity。线程 ident 是实际生命周期事实，未新增 substring/prose 状态分类；异常仍保留原 OSError。默认 order 修复已在 PR 说明披露，机器执行的启动顺序没有被称作建议。

我的整体评价

REQUEST_CHANGES。 运行时完整局部修复得到独立证据，持续返回与恢复、防重复改善，用户无需新增问题或配置。但当前 exact head 的必要语义/I/O inventory 检查失败，所以不能延用之前批准。交付判断 justified_increment 的 remaining gap 是生成清单与重新验证；不要求扩大 runtime scope 或把基线所有类型债务纳入此 PR。

启动顺序和失败清理属于同一个既有 Chat 生命周期边界；复用现有服务与返回状态 owner，两个小改动一起交付即可修复抢跑，无需新状态机或通用编排层。
当前 PR 完成既有 transport-first 启动不变量及未启动 pump 的清理；不扩展 provider 能力、权限或持久化契约。

Future-facing pass 已应用上轮合理的 service 类型声明，保留现有单一生命周期/状态 owner；当前应修的是同一修改引起的四处元数据漂移。修复后必须读取新完整 head，重核当前全部 PR 与必要检查，再给新 verdict；通过启动 tests 本身不能替代这一步。

English verdict: REQUEST_CHANGES - head ff3d8a3. Startup ordering, inert cleanup, queued recovery and replay pass 6 independent production-path cases and 55 regressions; the prior service typing issue is resolved. However, the new typing commit leaves four registry I/O census lines stale: required semantic/census checks fail at head and pass at base. Regenerate the existing manifest and rerun those checks on the new exact head.

[mikamikasuki]

Addressed the requested registry I/O census refresh in commit 375d197. The generator changed only four line coordinates (536→540, 1009→1013, 1588→1592, 1697→1701); recorded kinds and owners are unchanged.

Validation on this commit:

• uv run --extra test python examples/semantic-vocabulary-drift-smoke.py — passed.
• uv run --extra test python -m pytest -q tests/architecture/test_project_registry_io_census.py — 7 passed.
• git diff --check — passed.

The PR runtime source is unchanged by this follow-up. Fresh hosted checks for this head are still queued; I have not treated them as passed.

[loopx-agent]

动机

当前完整提交没有发现阻塞问题，APPROVE。 这是一次针对真实组合启动路径的恢复修正：原回传泵在 conversation transports 启动前就可能处理已完成结果，启动失败时又可能清理尚未启动的线程。对用户而言，任务完成后结果能否回到原会话，比孤立 helper 成功或新增测试数量更有价值。

本次完整核验提交 375d1970b27437d1284a0bcb378685ca2d22dcfe，对照不可变基线 3ed5d6bc88ffaaa05f2b1bc6a98ed5d921379fd1，并重新审查此前被指出的 IO manifest 行号问题。当前四处行号已经跟随真实定义更新；结论依据本次原生检查及实际启动、持久化恢复结果，没有继承旧提交的 approval。

采用不可变基线 3ed5d6b 的 docs/reference/protocols/manager-evidence-and-continuity-v0.md#ownership-and-defaults 作为既有规范依据。核验 Ownership and defaults 中工作完成与传输恢复分离、原会话自动回传，以及 failed/unverified send 不能视为成功的现有约束。

第一次实际 drain 观察到 provider 已 ready；传输启动抛出原始 OSError 时零泵启动、零发送、结果仍 queued 且 provider 清理一次；对同一持久化状态恢复后只发送一次，重新打开 store 并再 drain 不会重复。

它修复实际 server caller 上的时序，既不扩大权限，也不引入第二套持久化状态或重新解释历史回执。

尚未验证真实 Lark/远端 provider、异步 start 返回后才真正就绪的实现、长期 soak、吞吐、账户成本或安装后的运行；这些不应被本地 synthetic I/O 成功掩盖。

改动思路

先完成传输启动再开启回传属于组合层正确性不变量；复用现有生命周期和持久化回传 owner，无需另建调度或重试机制。构造回传服务时只推迟线程启动，发送仍经过既有传输、授权和 delivery receipt 规则；外部 helper 的省略参数仍保持原有 eager 行为。

当前 PR 交付启动顺序、失败清理及既有回传恢复，不承诺所有远端 provider 的长期稳定性或吞吐提升。这个边界可以独立验证和回滚：它修复实际 server caller 上的时序，既不扩大权限，也不引入第二套持久化状态或重新解释历史回执。提供者自己的远端就绪与失败语义仍由原 transport contract 负责。

具体改动

六个文件包含三处既有生产边界、两项针对性回归和 manifest 四个定义位置更新。ChatHTTPServer.manager_return_service 使用现有 ReturnService 类型；没有新增公共协议、CLI、可选能力开关、账户配置或结果投递授权。

关键代码讲解

• serve_chat 构造回传服务时传 start_service=False，随后先执行 conversation_transports.start(server)，再在 chat_server.py:1724 调用回传服务的 start()。启动异常不会越过这条分界，现有 finally/server close 负责收尾。
• start_return_service 在 manager_returns.py:323 加一个默认 True 的 keyword-only 参数。原有省略参数的调用继续立即启动；server caller 明确选择延后。传输选择、源会话 grant 与持久化回传决定没有另起 owner。
• ReturnService.close 在 roundtrip.py:1371 仍设置 stop/cancel，只在 thread.ident 存在时 join，避免清理 inert service 抛出未启动线程异常。类型注解也明确 start/close 返回 None。
• 现有 ChatConversationTransports 继续拥有 startup failure 的逆序清理；server close 先停回传再关传输。manifest 只修正定义坐标，IO owner 与分类保持原义，不能用删掉 census 检查代替更新。

独立复现使用相同合成 fixture，经实际 serve_chat、真实回传泵与真实持久化读取执行；只在 provider I/O 边界使用合成传输，不接真实账户。六项同输入检查在基线为 4 失败、2 通过，当前提交全部通过：第一次实际 drain 观察到 provider 已 ready；传输启动抛出原始 OSError 时零泵启动、零发送、结果仍 queued 且 provider 清理一次；对同一持久化状态恢复后只发送一次，重新打开 store 并再 drain 不会重复；未配置外部 factory、helper 省略参数及重复关闭 inert service 的边界也分别覆盖。

当前提交 55 项聚焦测试通过；不可变 base/head 的 IO census 各 7 项及完整 semantic smoke 均通过。Ruff、配置内 mypy 的 19 个文件、编译检查通过。最初独立 archive 的 Git-root/Node 解析条件不完整，修正两端相同环境后才取得有效全树证据。早期探针的合成 delivery attempt 缺少现有 typed contract 字段，已补齐五字段，最终同一 harness 在 base/head 比较；没有放宽生产断言或把无效早期失败解释成产品缺陷。

对主干的风险

风险集中在启动组合和关停顺序，已经通过实际 server caller 的成功、异常、恢复及独立持久化读回来辨别，超过了仅在 mock 中检查调用顺序的证据。旧 helper 的默认启动、没有外部 factory 的路径和既有授权/回执形态保持；新增参数只是局部构造控制，并不授予新 provider 能力。

前瞻性整理采用已有 ReturnService 类型并保留唯一组合 owner，没有发现本修复还需要引入新框架。尚未验证真实 Lark/远端 provider、异步 start 返回后才真正就绪的实现、长期 soak、吞吐、账户成本或安装后的运行；这些不应被本地 synthetic I/O 成功掩盖。完整 semantic smoke 通过也不代表仓库所有未解决语义 producer 已被证明安全。未查询远端 CI，本结论是 exact-head review approval，不是合并权限或整体业务验收。

我的整体评价

预期效果和效率都偏正向，依据是故障路径变短且结果仍可恢复：原来启动尚未完成就会产生一次错误处理机会，新版明确等传输启动完成；启动失败保留 queued，恢复后一次发送并保留防重复回执。它减少了无意义投递与重新追问结果的机会，而没有让用户增加配置步骤。长期净收益仍需真实 provider 运行数据，但这次有界修复的因果证据已经足够，此前 manifest 阻塞也已重新核验解决。

English verdict: APPROVE. The exact head fixes the production startup-order and inert-cleanup defects while retaining eager helper defaults, grants and persistent return receipts. Identical base/head probes exercise successful startup, startup failure, durable recovery and no duplicate send; current census and full semantic checks pass. Live remote providers and sustained performance are not qualified by this review.

Reviewer: model_agent — gpt-6.1-sol / OpenAI; reasoning_effort=xhigh; declaration_source=runtime_reported; execution_observation_id=d0fc1d35147332e8647f9c138998c5b4a29547c10c66e346f51893fbe57c87f2

[mergify]

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

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 — gpt-6.1-sol / OpenAI; runtime_reported; reasoning_effort=xhigh.

动机

REQUEST_CHANGES：当前 head 有一处必要 I/O 清单阻塞。

使用 Chat 接收后台工作结论的用户，会在服务重启且已有待返回结果时遇到这个问题。
旧版先启动返回线程，再启动消息传输，待返回结果可能抢跑发送并进入重试；新版先完成传输启动，再开始处理返回。
当前 head 的正常启动、失败清理、queued 保留、恢复回传及防重复均通过独立本地入口检查；但必要的 I/O 清单检查失败，尚不能批准此版本。
本 PR 只修复既有 Chat 启动与清理顺序，不增加 provider、界面、权限或结果格式；真实远端 provider、模型采纳及长期运行未测。
剩余缺口是当前 head 的一处生成清单行号与真实源码不一致；应在同一 PR 重新生成并核验，不能沿用旧 head 的批准。

精确 head：b7c7ce070367667ef197c869c009b537705aa942；不可变 base：0e5acfecf87743d76bd87b3f70c2a270c0e36179。队列最初给出旧 head 17c82c495ca6b383ee5a5a93c0661ada522f74d5，读取时已更新，原生 exact-target 入口拒绝旧版本；本次改用新完整 head，全 diff 和决定性验证重做，没有继承历史批准。

改动思路

启动顺序和失败清理属于同一个既有 Chat 生命周期边界；复用现有服务与持久化回传 owner，两个小改动共同修复抢跑，无需另建调度或状态机。
当前 PR 交付 transport-first 启动、未启动线程清理及对应回归；原 route/grant、retry、delivery receipt 和传输身份 owner 保持。

先由现有 helper 组装同一 ReturnService 和取消信号，再启动配置的 conversation transports，最后启动回传线程。传输启动抛错时，原 finally/server_close 关闭未启动的服务与传输，回传文件仍保持 queued。实际路由、身份 grant、重试和回执仍由既有 owner 管理；这属于现有 Python host/provider I/O 生命周期，没有新增并行决策源或持久 ready 状态。

具体改动

关键代码讲解

• serve_chat（loopx/chat_server.py:1697/1726）：传 start_service=False 延后线程启动，再在 transport.start 成功后启动同一 pump；失败走原清理路径。
• start_return_service（loopx/extensions/lark/manager_returns.py:323）：新增 keyword-only、默认 True 的构造选项。省略参数仍 eager；没有创建第二服务或改变取消信号。
• ReturnService.close（loopx/capabilities/manager_context/roundtrip.py:1371）：设置 stop，只有 thread.ident 存在才 join；未启动服务可重复安全关闭。现有类型声明和 None 注解保留。

六个文件还包括两项生命周期回归和现有生成清单；四个清单坐标中的 nested wake 坐标在当前新 head 仍过期。完整 diff 没有新增 provider、CLI、schema、界面或账户授权。

规范依据 docs/reference/protocols/manager-evidence-and-continuity-v0.md，固定版本 0e5acfecf87743d76bd87b3f70c2a270c0e36179，验收项 Ownership and defaults：Chat 承担 transport 恢复，工作完成与传输恢复分开，failed/unverified send 不能表示成功回传；本次运行路径 implemented。更大的分阶段 manager/portfolio 目标不在这次局部修复内。

对主干的风险

独立同输入探针调用真实 serve_chat、ReturnService 线程/drain 和文件回执，provider start/send 合成，serve_forever 定点退出。新 head 6 passed；同一不可变 base 4 failed、2 passed：两项揭示抢跑/启动失败时已开启 pump，一项揭示未启动 join，第四项是旧 helper 不支持新增 defer keyword。无 provider 和省略参数 eager 两版均通过。head 启动失败保留原始 OSError、零初始 pump/send、queued 不变；同一持久状态重启后 delivered 一次，新 pump 重放不重复发送。

两个现有 runtime 模块 55 passed；Ruff、diff whitespace、3 个提交 DCO 与变更 vocabulary advisory 通过。advisory 空结果仅覆盖支持语法，不证明动态语义。

语义与 CI 对齐

P2 阻塞：重新生成当前版本 I/O 清单。 tests/architecture/test_project_registry_io_census.py 在 head 6 passed / 1 failed、base 7 passed；完整 examples/semantic-vocabulary-drift-smoke.py 同样 head exit1、base exit0。错误为 loopx/chat_server.py::<module>.serve_chat._wake_goal_context::codec_read:load_registry#1 的 metadata changed。当前 manifest line 1701，真实 call 位于 1703。独立调用原生产 generator 生成候选，只改变该项坐标，kind/API/classification 不变，candidate validate=[]；未编辑 tracked source 来隐藏失败。

最小修复：uv run python scripts/generate_project_registry_io_manifest.py，审核单项行号，再运行 uv run --extra test python examples/semantic-vocabulary-drift-smoke.py 和 uv run --extra test python -m pytest -q tests/architecture/test_project_registry_io_census.py。不能删检查、缩扫描范围或把此失败归给基线/远端 CI。此前类型建议已由当前声明解决；旧四处清单修复不能证明 rebase 后仍 current。

我的整体评价

运行时的启动、清理、持久恢复和防重复改善得到当前独立证据，long_horizon/user_experience 为 improved；不增加用户配置步骤。但完整 head 的必要清单检查仍失败，因此交付判断为 justified_increment，剩余修复在同一 PR，当前 verdict REQUEST_CHANGES。风险式 premerge 的 5 项直接检查通过，10 项选择检查执行完成，仅完整 semantic smoke 因上述同一坐标失败，零 manual holds；未查询、轮询或等待 CI。

启动顺序和失败清理属于同一个既有 Chat 生命周期边界；复用现有服务与持久化回传 owner，两个小改动共同修复抢跑，无需另建调度或状态机。
当前 PR 交付 transport-first 启动、未启动线程清理及对应回归；原 route/grant、retry、delivery receipt 和传输身份 owner 保持。

Future-facing pass 已采用现有 ReturnService 类型、单一生命周期 owner；未发现需要额外框架的相关重构。通过本地回传不代表真实远端就绪、模型采纳、长期运行、安装资格或合并权限。修复并产生新 head 后应重新读全 diff 和必要检查。

English verdict: REQUEST_CHANGES — exact head b7c7ce0. The production startup and recovery invariant passes six independent cases and 55 lifecycle regressions, with eager/no-provider parity preserved. However, the rebased head leaves one registry I/O coordinate at1701 instead of1703: census and full semantic checks fail at head and pass at the immutable base. Regenerate the existing manifest and revalidate the new head. No remote CI was consulted; live provider/model behavior remains untested.

[mikamikasuki]

Addressed the exact-head registry I/O census finding in commit 19658b69a3: the generated manifest changes only serve_chat._wake_goal_context::codec_read:load_registry#1 from line 1701 to 1703; its kind and owner are unchanged. Validation on the current head: uv run --extra test python examples/semantic-vocabulary-drift-smoke.py passed; uv run --extra test python -m pytest -q tests/architecture/test_project_registry_io_census.py passed (7 tests); git diff --check passed. The focused lifecycle modules passed 55 tests on parent b7c7ce0; this follow-up changes only generated line metadata. The PR base remains current main 0e5acf. Please review the updated head.

[mikamikasuki]

Rebased the PR onto canonical main at fac40bbc43ff17d0c0d573af69204cb73b36e842 and refreshed the generated Chat I/O census on the rebased source. The runtime change remains scoped to starting the return pump after transports are ready and safely closing an unstarted service.

Validation on head c90db2d7cc5366c2884b2429c36bba04eae27a4f:

• uv run --extra test python -m pytest -q tests/test_chat_transport_composition.py tests/test_manager_context_roundtrip.py — 55 passed.
• uv run --extra test python examples/semantic-vocabulary-drift-smoke.py — passed.
• uv run --extra test python -m pytest -q tests/architecture/test_project_registry_io_census.py — 7 passed.
• Ruff and git diff --check origin/main...HEAD — passed.

GitHub checks have restarted for this head; only the Summary check is visible so far and it is still running.

[mikamikasuki]

Current-head attribution for Frontstage Pages run 37881098922, job 113660739902, on PR head c90db2d: Validate bilingual Blog catalog fails on the paired-link assertion for edgebench-feedback-and-memory. I ran node examples/blog-bilingual-index-smoke.mjs on the exact base fac40bb and exact PR head c90db2d; both exit 1 with the same assertion. #5996 changes six Chat/runtime and test/manifest files, not the blog catalog or smoke script. The shared correction is proposed in open PR #5968, which is still behind main, so this failure remains pending and is not cleared. DCO, Dependency Review, Release Artifacts build, and Summary are successful; merge-gate is still expected. I am not claiming the overall checks are green.

[mikamikasuki]

Follow-up on the registry-census finding from head b7c7ce0. After rebasing onto canonical main 647e216, current head 0e6a4c8 regenerates the moved Chat I/O coordinate; the recorded kind and owner are unchanged.

Current-head validation: the focused Chat lifecycle tests passed (55); the I/O census passed (7); the semantic-vocabulary smoke passed; Ruff, Python compilation, configured mypy (19 source files), diff check, and the pre-merge canary (10 selected checks) passed. The exact startup-order selector fails on main because the return worker sees transport.started == false and passes on this head.

GitHub currently reports Summary success; DCO, dependency review, Frontstage Pages, Release Artifacts, and Python Tests are still queued. I am not claiming hosted CI is complete. Please refresh review against 0e6a4c8.

[loopx-agent]

Reviewer: model_agent — gpt-6.1-sol / OpenAI; runtime_reported; reasoning_effort=xhigh.

动机

服务重启时，如果已有后台结果等待返回原会话，旧版会先启动 return pump，再启动 transport，因而可能在发送通道尚未准备好时就消耗返回尝试。当前提交修复这个实际启动顺序，并让尚未启动的服务安全清理；用户无需新增配置。独立探针在原版复现问题，在新版完成失败保留、恢复返回和防重复，局部收益有证据；未证明远端通道或长期吞吐改善。

精确 head：0e6a4c87e1dc9a7a2c15cf3d4c9c19300b5fa87c；完整 base→head：647e216bacc0a69368dccc18fcb52dcba6002553。读取六个文件和现有生命周期、transport、grant、receipt 消费者；同时复核历次评审的类型声明与 I/O 清单问题，没有沿用旧批准或把重基后的主干历史当作本 PR 改动。

改动思路

复用既有 Chat 组合层：先构造同一个 ReturnService，再完成 transport.start，最后启动 pump。返回资格、原 route/source grant、撤销、retry 与去重仍由原 drain 和类型化绑定 owner 管理。移动启动和修复未启动线程的 close 必须一起交付；任意 sleep 或额外重试层既不能证明 ready，也会增加维护和副作用。

这是现有 Python host/provider I/O 生命周期的局部修复，没有新建通用 Python 决策源、状态机或能力开关。依据固定 base 的 docs/reference/protocols/manager-evidence-and-continuity-v0.md#ownership-and-defaults 的验收项 Ownership and defaults：结果返回原会话，通道恢复与工作完成分开，未验证发送不算返回完成。当前实现满足这个启动与恢复边界；更大的 manager 目标不在此局部验收内。

具体改动

• serve_chat 显式 start_service=False 构造；conversation_transports.start() 成功后才启动 manager_return_service，原 finally/资源清理保留。ChatHTTPServer 声明既有 ReturnService 类型。
• start_return_service 的 keyword-only 参数默认为 True；省略参数的旧 caller 仍 eager，false 只延后同一实例，不改变 grant、取消或持久化格式。
• ReturnService.start/close 声明返回 None；close 保留 stop/cancel，并仅在线程 ident 存在时 join，避免错误启动清理时的二次异常。
• 两个既有测试模块补 transport-first 与 inert-close 回归；既有 registry I/O manifest 四处只更新源行坐标，kind/owner 不变，当前最后一处为 1703。

Future-facing pass 已采用现有服务类型和单一组合 owner；没有必要增加重启框架或无 caller 的抽象。CLI/前端/Lark 没有新增用户操作，现有服务启动自动获得正确顺序；没有新增发现或配置入口需要补齐。

对主干的风险

当前源 checkout 独立验证 68 passed：55 项现有生命周期/返回回归、6 项独立真实入口/持久化探针、7 项 census。相同探针在固定 base 为4失败/2通过：3项复现 ready 抢跑、失败时已启动 pump、未启动 join；另1项是旧 helper 不支持新增 deferred 参数，单独区分。新版失败启动保留原始 OSError 和 queued，零初始 send/pump、provider 清理一次；恢复后交付一次，重新打开 store 再 drain 不重复。无外部 factory 与默认 eager helper 在两端都通过。

全树 semantic smoke 在 base/head 都通过，输出一致；当前 Ruff、开发期 semantic advisory、diff 检查通过。第一次验证环境缺少根目录 TypeScript 依赖，导致两端各3项 census 失败；补齐相同依赖后两端 census7通过，并重跑 head 得到68通过。原失败记录保留，没有放宽检查。历史四处/单处清单漂移与服务类型问题在当前源码和必要检查中均已解决。

没有新增权限、schema、CLI、prompt 或通用状态分类；helper 默认保持 eager，实际 server 的 transport-first 默认变更已披露。启动顺序是机器执行的不变量。未查询或等待 CI；正式合并状态和其他 reviewer 的有效阻塞单独处理。

真实执行的是 serve_chat、ReturnService/drain、类型化边界与文件持久化；provider I/O 合成，serve_forever 定点退出。live Lark/远端异步 provider、安装后的运行、长期 soak、吞吐和账户成本未测。provider 若在 start 返回后才真正 ready，需要其自身 readiness 契约，本 PR 不提供普遍远端就绪保证。

我的整体评价

APPROVE 当前精确 head。 修复发生在正确的现有 owner，启动、失败恢复、防重复与旧默认都有独立证据；本次所需清单也已同步。长期效果预计正向：减少重启后的无效发送尝试和人工恢复，用户步骤不增加；新增成本仅是局部组合顺序和 close guard，尚无长期效率量化数据。

采用当前评审经验中的“有用结果与恢复 readback”建议，按原会话返回验证；没有把经验送达、测试数量或批准本身当成长期价值证明。批准仅覆盖此启动修复，不替代 live provider 验收或授予合并/账户操作权限。

English verdict: APPROVE - head 0e6a4c8. Whole startup/cleanup slice reviewed; 68 current-head tests, paired base/head lifecycle counterfactuals, census and full semantic checks pass. Queued recovery delivers once and fresh-store replay does not duplicate. Previous typing/inventory blockers are resolved; live-provider, installed and long-run performance remain untested. CI was not queried.