[loopx-agent]

API 转发器原先把未标版本的 health 当作已采用新版，因此 Chat/插件升级后仍可能使用旧 daemon。本次在现有 native account provider 中加入独立的正式扩展入口、加载版本读回、认证排空和单 owner 升级接续，并保留原只读 qualification 协议。

已接收流等待正常结束；新请求在排空期间停止准入。旧协议迁移要求明确 PID 及两次归属核验，只请求正常退出。凭据、账号策略、原会话及业务队列仍由原 owner 管理。

验证：22 项 relay/生命周期测试、109 项账号与 API 回归通过；旧源码能复现健康旧进程被静默采用，新版本拒绝该情况；实际 wheel 安装与原生 extension install/doctor 已通过隔离运行环境。原管家实际业务补回复仍须独立验收，当前还有真实额度失败。

[loopx-agent]

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

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

动机 / Motivation

使用原 Chat 管家的用户和升级 native account provider 的维护者。 升级后旧转发进程仍返回健康，旧实现继续采用它；新实现核对已加载版本，停止新准入并等待旧请求结束后才采用新版。 同一个模型转发 owner 能报告真实采用版本，并通过现有调用入口安全接续升级。 此增量不更改消息业务、付费许可、账号优先级或原 Bot 身份，也不宣称历史问题已全部回答。 原管家的历史问题是否已处理并正常送达，仍需按原消息逐条验收；当前存在真实额度失败。

改动思路 / Approach

版本观察、排空和启动必须落在同一 provider owner；Core 原来的账户策略及消息执行者继续复用。 本 PR 交付模型 provider 的正式安装入口和真实转发升级闭环，原 Bot 的业务补回复仍由其原队列执行和独立验收。

原生账户的 TypeScript 策略继续决定是否使用 API；只有已获该策略准入的原模型调用进入 ensure。新增事实由实际服务生成：加载代码版本来自启动时的包内容，instance 来自本次进程，active_requests 来自准入锁内计数。它们不是人工维护的第二份部署账本。控制凭据在已有私有文件中独立随机生成，模型调用方拿不到它。

健康旧进程曾在实际安装中持续存在，单次手工重启无法修复下一轮默认升级。这里把版本比较、排空和启动放回原 owner，复用既有状态锁与服务锁；只读 qualification CLI 保持原边界。新增 manifest 和 CLI 在 wheel 中实际安装，并通过现有 extension install/doctor 流程验收。登记不改变原账户策略，也不创建消息消费者。

触发	原行为	本次行为
健康但旧协议的进程	直接当作可用版本	保留进程，要求明确且核验过的正常迁移
支持管理协议的旧版本	无版本校验	原实例停止新准入，旧请求结束并释放锁后启动新版
排空尚未结束	无显式管理状态	有界返回 pending；不强杀、不启动第二实例

具体改动 / Changes

规范依据：packages/loopx-codex-provider-routing/NATIVE.md，提交 1dd8cbf79770648cd473b88eaf87587e48c0fcd8。按改动前的契约逐项核验：Native-owner 由现有可选 package 管理凭据和进程，Core 继续组合；Native-stream-drain 用真实阻塞上游及单次调用断言核验已接收流；Native-private-state 由替换前后路由、Key 和账户文件相同以及既有账户回归核验。新文档解释安装、升级和验收边界，不能反过来作为已完成业务的证据。

8 个文件 +584/-26，包含 222 行生命周期测试与 74 行安装运维说明，其余是已有 relay 的扩展、两个包内 IO/CLI 模块、入口及 manifest。没有新 Core capability、业务存储或调度器。

关键代码讲解

1. ensure 是原 NativeAccounts.model_transport 真实使用的入口；在原状态锁内核验实际运行版本。它不从 health、安装版本字符串或测试通过推导采用成功。
2. reconcile 比较实际实例，正常排空后等待同一 server lock 释放；超时返回 pending。旧协议只有明确 PID、同 UID 内核出生身份、精确 module/root 参数及锁/端口归属二次核验后才请求 SIGINT。没有强杀路径。
3. begin_drain 在准入锁内先改变 accepting，再异步 shutdown；既有 daemon_threads=False 与 server_close 保留已经接收的 handler，流不会重放。
4. provider.main 提供明确原生协议、只读状态/预览和显式执行。doctor 实际执行随包 TS 依赖检查、读本地版本事实，保留 message_delivery_verified=false。旧公开只读 CLI 没有被升级成私有操作入口。

对主干的风险 / Risks

最大风险是升级正好遇到已接收的长流。真实 HTTP 测试阻塞上游，在控制请求后验证新请求拒绝、旧流完整返回、上游只调用一次；独立进程测试验证旧 owner 退出后才有一个新 owner，同实例重复 ensure 不重启，后来增加 steward 凭据仍能正常采用。错误控制凭据、错误 instance、未知或复用 PID 以及未释放的 drain 锁均保留工作并拒绝越界操作。

PASS：22 项 relay/生命周期组合测试、109 项账户/API 回归。最终控制凭据类型检查后重跑精确版本的 8 项生命周期测试。配对反证中旧源码有 6 项保真控制通过，但“健康旧版本不可静默采用”断言失败；新版本同一组 7 项全部通过。旧基线 ensure 的 AST 与实际 PR base 相同。实际 wheel 安装与 extension install/doctor 已在隔离环境通过，最终 wheel 在最后修改后重建；安装生产版本和消息送达另行验收。

源码 premerge 的 5 项直接检查通过，包含编译、diff 和双语 RFC 检查。Goal 的质量收据策略为 disabled，没有伪造资格；按 wait_for_ci=false 未查询 CI。公开 diff 无私有路径或真实凭据。正常模型转发、已开始流不重试、订阅优先及默认关闭策略由既有同输入测试覆盖。

语义与 CI 对齐

本次扩展的是包内本地 transport 生命周期词汇，沿用已有账户策略和 private store；不改变 Goal、额度结算或消息执行义务。新控制 credential 的权限仅用于本实例正常排空，不能作为模型 token，也不能证明用户已收到答案。旧 health 保留兼容，因为实际 daemon 和调用方独立升级；过渡分支仅用于归属可证明的旧安装。回滚应使用保留的不可变环境及原 extension/host 正常回滚，先处理同一排空边界。

我的整体评价 / Verdict

结论为 justified_increment / APPROVE。long_horizon 与 user_experience 均得到改善：默认入口不再把旧健康进程当作已采用新版，未来接续无需重复询问既有授权，同时保留在途工作和明确的失败恢复归属。版本观察、排空和启动必须落在同一 provider owner；Core 原来的账户策略及消息执行者继续复用。 本 PR 交付模型 provider 的正式安装入口和真实转发升级闭环，原 Bot 的业务补回复仍由其原队列执行和独立验收。

这 584 行新增量主要用于实际排空、版本证明、安装入口及必要反证，复用原 owner 比新建 Bot 服务或扩展 Core 策略更合适。保持旧 health 的兼容是独立升级边界所需，并非为旧消息格式再造执行者。仅 native CLI、relay 与文档变化，没有渲染界面改动；原管家业务回复与长稳运行仍待原路径验收。测试、插件登记或健康都不能替代该验收，因此这不是全部历史消息已完成的结论。

English verdict: APPROVE this bounded native-provider lifecycle change; original Bot business replies remain separately unverified.