[loopx-agent]

A background loopx update apply or loopx upgrade invoked inside another LoopX checkout could import that checkout in its detached worker. The worker could therefore plan or execute for a different installation than the CLI that accepted the update.

Pin the worker import to the requesting installation using the existing subprocess entry pattern. Preserve the caller cwd, environment, explicit registry/runtime arguments, single-flight lock, and durable status/result behavior. Document that boundary.

Validation: real detached update/upgrade processes with conflicting cwd and optional PYTHONPATH fail the ownership assertion on the exact base and pass all four cases on this head and an independently installed wheel. Focused update/runtime tests passed (136 passed, 3 Windows-only skips); standard premerge passed its blocking checks and public boundary scan. The inherited host_process_transport maintainability advisory is retained and compared separately against the exact base. No UI layout changed; native Windows execution and a live archive installation are outside the isolated regression coverage.

[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

在另一个 LoopX checkout 中执行后台升级的用户和维护者会遇到这条路径。 同样的升级命令，旧版会加载工作目录中的另一份 LoopX；修复后由发起安装处理，并能读回本安装的真实结果。 真实 CLI 的四组反例从外来模块执行变为本安装的结构化拒绝；显式相对路由保持原值。 本 PR 不替用户运行未知效果的旧操作，也不增加权限、消费者或安装策略。 尚未证明 Windows 原生执行、真实 archive 升级和桌面 App 采用；安装后的服务版本仍需既有交付流程独立读回。

改动思路 / Approach

最强反对意见是外层 launcher 已固定代码来源，内层再固定可能多余。准确基线的真实 CLI 反例否定了这一点：外层正确，内层普通 -m 仍先加载 cwd。直接换 cwd 会改写相对状态路径，只改 PYTHONPATH 也无法消除这个优先级。

导入归属属于当前进程 IO 边界；安装资格、执行策略和持久状态仍由既有 owner 决定，不增加第二份策略。 只修复后台 worker 的代码来源并保留原路由、锁和结果；不把它等同于整个发布或业务补办。 复用 refresh_settlement.py 和 collaboration_mcp.py 已采用的显式模块根模式；不为了两行启动模板引入跨域依赖。安装策略仍在 self_update.py，持久请求、进程锁和观察者退出逻辑保持原 owner。未新增状态、CLI 参数、服务或消费者。

具体改动 / Changes

准确 head 为 a95d991575f72e6f42d6424748e15d9ecb445143。改动前规范：docs/product/release-readiness.md，revision d41e71b0bee225b9cd69c48fae56e5fd23fa45b8（固定规范）。新增文档段落不是独立规范。原文未编号，本评审用以下定位名：

• owner-environment：implemented。真实源代码、解包安装的 wheel 和公开 CLI 子进程均来自发起安装；没有把合成拒绝路径称为成功升级。
• explicit-intent-flow：implemented。原 check/plan/apply 分流、两个别名及 status 只读行为继续通过现有测试。
• layered-readback：deferred。获取包、宿主材料、服务激活和扩展就绪仍须分别验收；本评审不宣布完整发布采用。

关键代码讲解

start_or_observe 仍先持有 launch 锁、写入原 request，再启动后台进程。变化只有启动方式：-P 排除初始 cwd，显式插入本模块所在安装根，然后运行同一个 worker；不改变子进程 cwd、env 或 request argv。因此带空格的路径、相对 registry/runtime 与原来的解析基准保持一致。

worker 本体未改：它持有整个生命周期锁、读取原请求、进入真实 CLI，并保存最终结果。handle_update_command 仍是 update/upgrade 的共同入口；只读路径和 Windows 原控制台拒绝分支没有迁移。新增四例真实 detached 进程测试，开发文档明确说明代码归属和可恢复观察。

对主干的风险 / Risks

无阻断 finding。PASS：当前 head 的五组聚焦测试为 136 passed / 3 skipped；源码和实际安装 wheel 的四组子进程均通过。另用真实 scripts/loopx 发起相同四组请求：基线四例均执行外来模块，当前 head 四例均不执行，并读回真实不支持安装的结构化结果及原相对路由。测试选用合成状态和已知拒绝路径，没有执行真实 archive 安装；现有安装路由测试中的安装器仍为 mock。

PASS：standard premerge 阻断项、RFC 双语检查、语法/格式和公开边界扫描。保留一项已有 FAIL：host_process_transport.run_host_process 为 91 statements / 49 decisions，限值 90 / 60。隔离准确基线与 head 的完整报告仅替换根目录后相等，故归为 pre-existing unrelated，未改预算或例外。前一份嵌套 archive 的 Git 文件枚举不完整，已保留为无效比较；采用按准确 Git 树建索引的隔离基线重新核验。

3 项 Windows 专用测试因 macOS 跳过；原生 Windows、成功的 live archive 升级及 Desktop 采用为 UNVERIFIED。关联 #7796/#7798 修复外层解释器记录与 PATH 枚举，未触及本 PR 的内层 worker 来源，不作为本补丁依赖。当前策略 wait_for_ci=false，未抓取、轮询或等待远端 CI。CQR 对此 Goal 为 disabled，不能替代评审、授权和最终 merge-readiness。

我的整体评价 / Verdict

这是 justified_increment：确定修复默认升级中的一个真实归属错误，尚不等于整个安装、发布或业务补办完成。long_horizon 为 preserved：原锁、结果、重连与观察者退出机制保持；user_experience 为 improved：同一既有授权命令无需用户额外换目录或补许可。未改变渲染页面，视觉评审不适用，未新增视觉通过声明。

代码量与问题相称。相关重构检查选择保留现有 IO 边界，避免抽取跨域框架或建立第二个安装 owner。可观察变化是有意且已验证的外来模块拒绝，非更改安装资格；现有语义复用，不新增协议/权限词汇。没有未解决的必需证据或阻断发现；原生平台与采用缺口继续由既有 release-readiness 流程负责。合并仍须新鲜准确 head 资格及独立授权。

English verdict: APPROVE at a95d991; no blocking finding. Native source, installed-wheel and actual CLI ownership regressions passed; native Windows and live archive/Desktop adoption remain unverified.