[loopx-agent]

Goal And Delivered Outcome

Four Windows activation tests start with an archive-snapshot plan and then overwrite only execution_driver with pip/pipx. Windows correctly refuses the original archive plan, leaving plan.apply_supported=false, so these tests stop before exercising their intended package-manager path. This failure is visible in the Windows job on #7630.

Build each fixture through the real installation-owner planner: Python-distribution metadata selects pip/pipx, while the archive arm retains source-snapshot planning. Both test families now share this setup and assert planner admission and the selected driver before mocked execution. Their route propagation, launcher ownership and failure assertions remain.

Author Declaration

• Written by: model_agent — OpenAI Codex / GPT-6 family.
• Specification: the reproduced Windows CI failure and the existing installation-owner behavior in loopx/self_update.py at 8caaf678e52019453ca3e5a2adf363c954ae2642; no separate written specification. Intended base: main.

Criterion	Disposition	Evidence
Exercise the requested package-manager owner through a valid plan	implemented	apply_plan_for_driver; both existing parametrized test families
Preserve selected registry/runtime propagation and launcher ownership	implemented	Existing execution/readback assertions retained
Preserve Windows archive refusal	implemented	No production changes; existing native-Windows refusal test retained

Scope And Continuation

Complete within the fixture repair. One test file changes; updater behavior, platform admission and service activation are untouched. This is independently reviewable from #7630. Its merge does not certify that PR's remaining checks, performance or adoption.

Validation

The current head incorporates main; the proposed test file is byte-identical to the original repair. The earlier Windows run stopped before activation tests at a CLI output-budget failure on its older base (job). That failure is retained; it did not qualify the Windows fixture repair.

• Tested revision: 36cdca826383c7adaacc0c9441d05bedb5369b38; base 99cfa3ac559bfa237f04f36fb7e926672fea44b2.
• Run state: finished locally. Input classes: synthetic, public_fixture.

Check	Result	Evidence / limitation
Update/activation suite	passed	uv run --extra test python -m pytest -q tests/test_self_update_runtime_activation.py tests/test_python_install_owner_platform.py: 58 passed, 6 platform-specific skips on macOS
Windows planner sensitivity	passed	With only the updater's OS adapter reporting Windows, the old pip/pipx fixtures refuse apply; the corrected owner-derived plans admit both. This is not native Windows execution.
Static and public boundary	passed	Ruff, diff checks and an explicit source scan with zero errors/warnings
Quick premerge / change quality	passed	Five direct checks; no catalog canaries selected. Exact-scope receipt cqr_617a9ec57899953a6e60 verified: zero blockers, one native-Windows validation warning
Native Windows lifecycle batch	failed	Exact-head Windows job: full updater file executed; 417 passed, 20 skipped, 2 failed. The earlier four updater assertion failures no longer appear. Remaining failures are manager-inspection todos / todos_exact timeouts; the Windows workflow and all required CI are not qualified

No real installer, package upgrade or service restart was executed. No UI changes; visual evidence is not applicable. No shared protocol/vocabulary, RFC pair or runtime/backend surface changes.

Boundary Checklist

• Only public fixture source is committed; no private state, logs, captures, credentials or local paths.
• Dedicated branch/worktree, explicit path staging and DCO sign-off.
• No paired RFC changes and no UI impact.
• The complete Windows workflow, required remote checks and independent review remain separate qualification gates.

[xiaoan17]

交接：Windows 上验证过这个修复

这个 PR 修的正是 windows-powershell lane 上那 4 个用例：

FAILED tests/test_self_update_runtime_activation.py::test_update_preserves_selected_route_through_install_and_readback[python_pip]
FAILED tests/test_self_update_runtime_activation.py::test_update_preserves_selected_route_through_install_and_readback[python_pipx]
FAILED tests/test_self_update_runtime_activation.py::test_python_distribution_activation_ignores_archive_bin_override[python_pip]
FAILED tests/test_self_update_runtime_activation.py::test_python_distribution_activation_ignores_archive_bin_override[python_pipx]
4 failed, 415 passed, 20 skipped

根因是那 4 个用例用共享的 doctor fixture 描述 release snapshot 属主，而 Windows 上
release snapshot 的 apply 归 install-windows.ps1 所有，于是计划阶段就被拒绝
（"loopx update apply cannot mutate an installation owned by
loopx_release_snapshot"），driver 从未运行。这个 PR 让每个 driver 使用自己能执行的
属主报告，方向与本 PR 一致。

本 PR 自己的 Windows run 未能证明这一点：它的 windows-powershell 红在另外两个
用例上——tests/test_chat_manager_inspection.py::test_manager_runtime_installs_tool_and_records_real_subprocess_read[todos]
和 [todos_exact]，都是 TimeoutError: chat turn wait timed out，与这个修复无关。

所以这里附上一个等价的修复在 Windows runner 上跑完的实测结果：

419 passed, 20 skipped in 320.15s (0:05:20)

零失败，其中包含这 4 个 self-update 用例。同一份改动在 macOS 上是
62 passed, 3 skipped。该次 Windows run 的整体 conclusion 显示 cancelled，只是
因为 cancel-obsolete-pr 终止了整个 run；测试步骤本身跑完并全绿，日志里没有 FAILED。

本 PR 的做法与这份实测一致（同样是按 driver 派生的属主 doctor report），并且额外
断言了 payload["install_lifecycle"]["execution_driver"] == driver，覆盖略强。

[xiaoan17]

这个 PR 的 run 正占死全仓库的 6 条 test-shard lane

排查 #7695 的 CI 时发现：仓库里所有 PR 的 test-shard 都卡在 pending、拿不到
runner，而其他 job 用同样的 ubuntu-latest 正常在跑。原因是本 PR 的 run
40929089454
的 6 个 shard 全部停在 in_progress，各 lane 都被占住：

2026-10-30T00:47:26Z test-shard (6)  run=40929089454
2026-10-30T00:47:39Z test-shard (2)  run=40929089454
2026-10-30T01:15:06Z test-shard (3)  run=40929089454
2026-10-30T01:21:48Z test-shard (4)  run=40929089454
2026-10-30T01:23:55Z test-shard (1)  run=40929089454
2026-10-30T01:28:05Z test-shard (5)  run=40929089454

外加 main 的 run
40924380841
的 test-shard (2) 也停在 in_progress。

这 7 个 job 的日志都在 01:47 左右同时停止输出（runner 失联），而 job 自身的
timeout-minutes: 60 没有把它们清理掉。test-shard 用的是跨 PR 共享的
workflow-level concurrency group（loopx-python-test-shard-<N>，queue: max），
所以这 6 条 lane 一被占死，仓库里每个 PR 的 shard 都在后面排队——包括
#7695，它从 18:28 排到现在。

解除办法（需要上游 admin 权限，我这边是 403）

POST /repos/loopx-project/loopx/actions/runs/40929089454/cancel
POST /repos/loopx-project/loopx/actions/runs/40924380841/cancel

取消这两个 run 会释放全部 6 条 lane，本 PR 和仓库里其他 PR 的 shard 就能开始跑。
取消后本 PR 需要重新触发一次 CI（新的 push，或对 run 执行 re-run）。

这不是本 PR 的改动造成的：本 PR 只改 tests/test_self_update_runtime_activation.py，
而卡住的 shard 在 tests/control_plane/test_todo_decision_scope_runtime_boundary.py
跑到 51% 之后失去 runner 连接。

顺带一提：本 PR 的修复本身有 Windows 实证

本 PR 修的正是 windows-powershell 上那 4 个 self-update 用例
（doctor fixture 描述 release snapshot 属主，而 Windows 上 release snapshot 的
apply 归 install-windows.ps1 所有，计划阶段就被拒绝，driver 从未运行）。一份等价
的修复在 Windows runner 上跑出 419 passed, 20 skipped、零失败，其中包含这 4 个
用例；本 PR 自己的 Windows run 红在另外两个用例上
（test_chat_manager_inspection.py 的 TimeoutError: chat turn wait timed out），
与这个修复无关。详见上面的评论。

[xiaoan17]

更新：占死 6 条 lane 的 7 个 shard 里，有一个是本 PR 的

上一条评论说占死 lane 的是本 PR 的 run 加上 main 的 run。重新全量扫描（这次覆盖了
更早的 run，之前只扫最近 100 个漏掉了）后，准确的分布是 6 条 lane 各被一个
in_progress 的 shard 占着：

2026-10-30T01:15:06Z test-shard (3)  run=40929089454   ← 本 PR
2026-10-30T01:21:48Z test-shard (4)  run=40929089454   ← 本 PR
2026-10-30T01:23:55Z test-shard (1)  run=40929089454   ← 本 PR
2026-10-30T01:28:05Z test-shard (5)  run=40929089454   ← 本 PR
2026-10-30T01:47:57Z test-shard (2)  run=40929089454   ← 本 PR
2026-10-30T01:47:46Z test-shard (6)  run=40930663039   ← #7695

也就是说，除本 PR 的 run 之外，#7695 的 run 也有一个 shard 卡在同一分钟。
main 的 run 那个已经不在列表里了。

这些 job 不是测试卡住，而是 runner 中途失联：

• 本 PR 的 test-shard (1)：01:23:55 启动，日志停在 01:47（约 51%）
• 本 PR 的 test-shard (6)：01:47:46 启动，日志停在 01:53:22（约 19%，只跑了 5 分半）
• docs(rfc): state the activation guard's refusal boundary #7695 的 test-shard (6)：01:47:46 启动，日志停在 01:53:22

runner 断开后 job 永远停在 in_progress，而 job 自己的 timeout-minutes: 60 没有
清理它们。由于 test-shard 用跨 PR 共享的 concurrency group
（loopx-python-test-shard-<N>，queue: max），这 6 个死 job 占满 lane，仓库里每个
PR 的 shard 都排在后面——包括 #7695 的另外 5 个 shard，它们从 18:28 排到现在。

解除办法（需要上游 admin；fork 身份是 403）

POST /repos/loopx-project/loopx/actions/runs/40929089454/cancel   ← 本 PR 的 run，5 个 shard
POST /repos/loopx-project/loopx/actions/runs/40930663039/cancel   ← #7695 的 run，1 个 shard

取消后需要给这两个 PR 重新触发一次 CI。#7695 的另外 5 个 shard 一旦有 lane 就会
开始跑。

这不是本 PR 的改动造成的：本 PR 只改 tests/test_self_update_runtime_activation.py，
而卡住的 shard 分别停在 tests/control_plane/test_todo_decision_scope_runtime_boundary.py
和 tests/architecture/test_source_session_registry_denial.py / test_top_level_module_budget.py，
都与它无关。