[kaguranananana]

Summary

On a source checkout, Raven named the checkout's update command in two places with two spellings: raven upgrade printed git pull && ./install.sh on every platform, while the page's editable refusal from system.upgrade already picked the install script by platform (.\install.ps1 on Windows). On Windows the CLI's spelling was also unrunnable as printed: Windows PowerShell 5.1 rejects && as a statement separator, cmd.exe cannot run a .ps1 by name, and the stock client execution policy (Restricted) refuses a bare script file.

raven/updates/upgrade.py now holds both platform definitions: install_script() chooses the script, install_command() chooses the command that runs it, and checkout_update_commands() composes the platform sequence from them. The page's checkout recovery reads install_command() inside its own PowerShell script; the CLI reads checkout_update_commands().

POSIX keeps the one-line git pull && ./install.sh every release has printed. Windows gets three steps:

raven web --stop
git pull
powershell -NoProfile -ExecutionPolicy Bypass -File ".\install.ps1"

raven web --stop releases the running raven.exe before uv tool install --force replaces the environment. The installer line names the PowerShell that ships with Windows, so the guidance is runnable from cmd.exe and Git Bash as well as Windows PowerShell 5.1 and 7. -ExecutionPolicy Bypass applies to that one process only and changes no machine policy.

The page's editable recovery uses the same installer invocation, and it runs the installer only when git pull succeeded, so a failed pull does not reinstall a checkout that did not move. The release-notes template and the docs-site quick start (English and Chinese) name the same Windows sequence.

Type

• Fix

Verification

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

• uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 -> 334 passed, 1 skipped (POSIX permission bits on Windows).

• New cases pin install_command() on both platforms and its default, the page's policy-safe installer and pull guard, the page/CLI shared invocation, and the release-notes stop, pull and install order. Mutation checks: returning the bare script from install_command(), dropping the page guard, or dropping raven web --stop from the release notes turns the corresponding tests red. The sources were restored byte-for-byte after each mutation.

• Real shells on native Windows 11: the printed Windows installer command ran a stub install.ps1 from cmd.exe, Windows PowerShell 5.1 and Git Bash. The page's guarded pull-and-install lines, run under a parent -ExecutionPolicy Restricted, ran the installer after a successful git pull and skipped it after a failed one.

• uv run ruff check and uv run ruff format --check over the changed files -> clean; git diff --check -> clean; scripts/check_commit_messages.py origin/main..HEAD -> exit 0.

• CI runs the docs build and the full unit suite.

Risk

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

User-visible change: on Windows, raven upgrade on a source checkout prints three commands instead of the unusable one line, and the page's editable refusal now runs the installer through a process-scoped policy bypass and only after a successful pull. On POSIX the printed CLI command is unchanged. The change alters advisory text, the page's recovery script, the release-notes template, the quick start, and the shared helper; no new command is executed by Raven itself. Rollback: revert this PR; the change is contained to the CLI, the page's recovery text, the release-notes template, the quick start, and one shared module.

Related Issues

Fixes #1085

Co-authored-by: Claude (deepseek-flash) noreply@anthropic.com

[LivXue]

Windows compatibility review — PR #1136 @ 0aecb7df828eca988507364484d0113103ef2e1e

Scope: full base 06509f8e → this head (4 files, +49/−3): a single install_script() in raven/updates/upgrade.py (.\\install.ps1 when os.name == "nt", else ./install.sh), used by the CLI's editable-checkout refusal (raven/cli/upgrade_commands.py:54-56) and the page's recovery text (raven/rpc/methods/system.py), plus tests.

One finding (low–medium, user-facing guidance only).

The CLI's Windows command is not runnable in the shells a Windows user is likely in

File: raven/cli/upgrade_commands.py:54-56 (new line). On Windows it now prints:

To update, run git pull && .\install.ps1 in the source checkout.

The script name is correct, but the command is not executable as printed:

C:\> cmd /c probe.ps1
'probe.ps1' is not recognized as an internal or external command, operable program or batch file.
    (probe.ps1 is a plain Write-Output script in the current directory)

PS C:\> powershell -NoProfile -Command "Write-Output a && Write-Output b"
ParserError: The token '&&' is not a valid statement separator in this version.
    (Windows PowerShell 5.1, the default powershell.exe)

Neither cmd.exe (a .ps1 is not executable) nor Windows PowerShell 5.1 (&& needs PowerShell 7) runs it; Git Bash cannot execute .ps1 by name either. Only PowerShell 7 accepts both, and even there .\install.ps1 is subject to ExecutionPolicy. The page's recovery text (_checkout_recovery) is already PowerShell-shaped and uses the script on its own line — that path is fine.

Remedy direction: on Windows print the two steps separately, as the page does (git pull then .\install.ps1), or print a form that actually invokes PowerShell (powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1, or pwsh -File .\install.ps1); keep git pull && ./install.sh on POSIX. The rest of the change (one definition for the script name, platform-guarded) is correct.

Verification (native Windows 11, CPython 3.12.13, isolated worktree D:\tmp\rv-1136 at this head, scratch HOME/USERPROFILE, PYTHONUTF8=1):

pytest tests/test_updates_upgrade.py -q
→ 234 passed, 1 skipped (POSIX permission bits)

The two shell probes above are the runnability evidence; the new tests assert the string only, not that a shell can execute it.

Limitations: not exercised under PowerShell 7 or an elevated policy; the change is a printed message, not upgrade logic.

[gloryfromca]

Blocking: the Windows CLI guidance must be executable in supported Windows shells.

Agreed. I independently checked the changed CLI path and the existing PowerShell-shaped RPC recovery path. The RPC path uses separate lines and remains valid, but the CLI now emits git pull && .\install.ps1: cmd.exe cannot directly execute a PowerShell script, while Windows PowerShell 5.1 does not accept &&. This leaves the exact Windows source-checkout guidance this PR is fixing unusable as printed. Please make the Windows CLI form shell-compatible (for example, separate PowerShell statements/lines) and cover the rendered Windows CLI output in the matching CLI test file.

[gloryfromca]

Blocking: the Windows CLI guidance must be executable in supported Windows shells.

I independently reviewed the full base-to-head diff, the CLI and RPC callers, the installer behavior and relevant history, backward compatibility, test changes, and the repository's AGENTS.md/CLAUDE.md and CONTEXT-MAP.md architecture rules. The shared platform helper is otherwise coherent, preserves the RPC recovery text, and introduces no dependency or architecture issue. However, the Windows CLI command remains unusable as printed, which is the user-facing path this fix intends to repair.

Verification: uv run pytest tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_updates_upgrade.py -q initially could not enter test bodies because the fresh environment lacked the workspace raven_everos package. After uv sync --all-packages, the exact command passed: 314 passed, 2 skipped. uv run ruff check and uv run ruff format --check passed on all four changed files. I also checked that the new tests were additive rather than weakened; they cover helper selection but not the rendered Windows CLI command that fails here.

[LivXue]

Blocking: the Windows CLI guidance this PR changes is not runnable as printed; that finding is already filed by @gloryfromca at this head and is not re-filed here.

Scope: I reviewed all 4 changed files in this PR. None of them is under raven/agent/, so this review carries no inline notes, and every finding below is reported here only. The blocking finding is cited from @gloryfromca rather than re-filed.

I examined the full base-to-head diff (06509f8e..0aecb7df8), both call sites of the new install_script() helper, install.sh's own platform refusal, the release-notes generation path, and the CLI and RPC tests that assert the rendered guidance.

Confirmed findings:

• Nonblocking: tests/test_cli_upgrade_commands.py:49 (also :73, :83, :97) pins the CLI guidance to the POSIX spelling. install_script() now reads os.name, so all 14 cases in that file fail on a Windows host; the fix is to patch the helper or assert the suffix per platform. Reproduced by replacing raven.updates.upgrade.os with a proxy reporting name="nt": 14 failed, while the unpatched control passed 316 tests across the three related files.
• Nonblocking: .github/release-notes-template.md:78 still says the remedy is git pull && ./install.sh, and release.yml:255 renders that template into the user-facing release notes. That makes it the third surface naming this command, and the only one still POSIX-only. Code-reading.

Already filed, not re-filed:

• @gloryfromca reviewed this head on 2026-10-29 12:18 UTC and graded the Windows CLI command Blocking, with an unresolved inline thread at raven/cli/upgrade_commands.py:55. Mechanism: the CLI prints git pull && .\install.ps1, which cmd.exe cannot run (a .ps1 is not executable) and Windows PowerShell 5.1 rejects (&& is not a statement separator). An earlier PR-level comment by LivXue on 2026-10-27 reported the same mechanism. I agree with the Blocking grade and am not opening a second note for it.

Verification:

• uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py -q -n 0 on the head tree: 316 passed in 11.44s.
• Windows-platform simulation (raven.updates.upgrade.os replaced by a proxy with name="nt", everything else delegated): tests/test_cli_upgrade_commands.py -> 14 failed.
• _checkout_recovery output compared between base 06509f8e and head for four checkout paths on both platform branches: identical.
• uv run ruff check and uv run ruff format --check on the four changed files: clean.
• CI at read time: every check passed except unit (py3.12 / ubuntu-latest / 1/4) still pending; python lint including import contracts passed.

Checked and deliberately not reported:

• The function-level import in _checkout_recovery matches the existing lazy-import style in system_upgrade; raven.rpc importing raven.updates is not a forbidden import-linter edge.
• raven/cli/doctor_commands.py:482 and raven/browser/driver.py:58 already branch on sys.platform for the reinstall hint, which is a different message from the checkout update command.
• The unconditional install.sh in raven/cli/doctor_commands.py:1068 is pre-existing and outside this PR's scope.
• tests/test_updates_upgrade.py:602 patches the real os.name; the repository already does this in tests/test_cli_theme.py:123 and tests/test_rpc_system.py:690.
• ui-web/src/state/upgradeShade.test.ts:61 uses the command only as fixture data.
• The ./install.sh in the README and docs-site quick-start is the initial local install, not the checkout update command; the quick-start update section is already platform-aware.
• The page's recovery text is byte-identical after the change, so the refactor is complete on that surface.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

The new commit resolves the outstanding Windows-shell blocker: the CLI emits separate update steps and explicitly launches install.ps1 through Windows PowerShell with execution-policy bypass. POSIX keeps its existing git pull && ./install.sh form. The rendered Windows CLI output now has direct coverage, the existing CLI cases are pinned to their intended POSIX branch rather than weakened, and the release-notes template now names both platform forms. I closed the superseded thread.

I reviewed the previous-to-current delta and the full base-to-head diff, affected CLI/RPC callers, installer behavior and relevant history, backward compatibility, test changes, and AGENTS.md/CLAUDE.md/CONTEXT-MAP.md architecture and language constraints. No new findings.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 passed with 326 passed and 2 existing truststore-dependent skips. Ruff check and format checks passed. make is unavailable in this environment, so I ran the underlying scripts/check_large_files.py and scripts/check_source_language.py commands directly against github/main..HEAD; both passed.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

This revision is a rebase of the previously reviewed fix onto current main. After refreshing github/main, the range-diff shows the code and tests are patch-equivalent; only the release-notes hunk was replayed against newer upstream wording, preserving the same platform-specific guidance. The resolved Windows-shell fix remains intact, and my earlier thread is still resolved.

I checked the full current base-to-head diff, the old-to-new range-diff, affected callers and history, backward compatibility, test strength, and AGENTS.md/CLAUDE.md/CONTEXT-MAP.md architecture and language constraints. No new findings.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 passed with 328 passed. Ruff check and format checks passed, as did scripts/check_large_files.py and scripts/check_source_language.py against github/main..HEAD.

[LivXue]

Windows compatibility review — PR #1136 @ 2e28f90059bfb8d2819ad1fe8be25e28c55e0e25

Scope: the PR's own diff at this head is b05267b2..2e28f900 (7 files, +145/−4): one definition of a checkout's installer per platform (upgrade.install_script, upgrade.checkout_update_commands), the CLI's editable-upgrade guidance printed from it, the page's editable recovery embedding the same installer, and the release-notes template naming both platforms. Tests pin the Windows and POSIX branches.

Windows angle: no defect found. The change fixes a real Windows problem correctly — Windows PowerShell 5.1 rejects && as a statement separator, and cmd.exe does not run a .ps1 by name, so the Windows form is two commands (git pull, then powershell -NoProfile -ExecutionPolicy Bypass -File ".\\install.ps1"), using the built-in Windows PowerShell and double quotes that keep a path with spaces one argument; .\install.ps1 inside the quoted -File argument resolves relative to the checkout the guidance says to run in. The POSIX one-liner is unchanged, and the RPC recovery script keeps its Set-Location -LiteralPath quoting and the same installer name. The residual -ExecutionPolicy Bypass behaviour under a machine Group Policy is an environment policy, not a code defect.

Verification (native Windows 11; detached worktrees D:\tmp\rv-1136 at head and D:\tmp\rv-base-1136 at base b05267b2; offline venv; scratch HOME/USERPROFILE; PYTHONUTF8=1; PYTHONPATH pinned):

• uv run --no-sync pytest tests/test_cli_upgrade_commands.py tests/test_updates_upgrade.py tests/test_release_plugin_list.py tests/test_rpc_system.py -q -n 0 --tb=line
  • head: 327 passed, 1 skipped (77.6 s)
  • base: 318 passed, 1 skipped (42.5 s)
  • zero failures at both; the 9 added tests pass, including test_editable_update_guidance_is_runnable_on_windows asserting the exact two-line output and the absence of &&. The single skip is the pre-existing "Windows keeps no POSIX permission bits" case.

Coverage gaps: the printed guidance was verified through the tests and by reading, not pasted into a real PowerShell/cmd here; no live page editable-upgrade flow was driven.

No Windows-specific issue found.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

The new commit closes the remaining Windows guidance gaps without regressing the earlier fix: it stops the resident gateway before replacing the executable, tells the reader not to install after a failed pull, keeps the PowerShell invocation on one copyable line, and aligns the release notes and platform tests. A merge-tree check against current github/main is conflict-free, and my earlier finding thread remains resolved.

I reviewed the new delta and full base-to-head diff, affected CLI/RPC and installer paths, relevant history, backward compatibility, test strength, and AGENTS.md/CLAUDE.md/CONTEXT-MAP.md architecture and language constraints. I tried to refute the shutdown requirement against the installer and web-stop behavior; Windows cannot reliably replace the running raven.exe, so the added step is warranted. No new findings.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 passed with 331 passed. Ruff check and format checks, git diff --check, scripts/check_large_files.py, and scripts/check_source_language.py all passed.

[LivXue]

Windows compatibility re-review — PR #1136 @ 9c6b7c4efba356b90caee805e5207b04de64319f

Scope: the delta since the previously reviewed head 2e28f900 is 1 commit / 6 files (+68/−17): the Windows checkout guidance now stops the page first (raven web --stop), prints the installer with soft_wrap=True so it stays one copyable line on a narrow console, and adds "If git pull fails, fix it before installing."; the release-notes template carries the same three-step form, and tests pin the order, the single-line installer at a 60-column console, and that _on_windows reads os.name.

Windows angle: correct, and each addition answers a real Windows constraint — uv tool install --force cannot replace a running raven.exe, so the page has to stop before the installer runs; a wrapped 67-character command pasted from the terminal becomes a call with no script, hence soft_wrap; the POSIX one-liner is unchanged because install.sh stops and restarts the gateway itself. No path, argv, encoding, or filesystem surface is added beyond the displayed guidance.

Verification (native Windows 11; detached worktrees D:\tmp\rv-1136b at head and D:\tmp\rv-base-1136b at base b05267b2; offline venv; scratch HOME/USERPROFILE; PYTHONUTF8=1; PYTHONPATH pinned):

• uv run --no-sync pytest tests/test_cli_upgrade_commands.py tests/test_updates_upgrade.py tests/test_release_plugin_list.py tests/test_rpc_system.py -q -n 0 --tb=line
  • head: 330 passed, 1 skipped (25.0 s)
  • base: 318 passed, 1 skipped (24.0 s)
  • zero failures at both; the 12 added tests pass, including the 60-column single-line assertion and the os.name switch test. The single skip is the pre-existing "Windows keeps no POSIX permission bits" case.

Coverage gaps: the printed guidance was verified through the tests and by reading, not pasted into a real PowerShell/cmd here; no live page editable-upgrade flow was driven.

No Windows-specific issue found.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

The new full-command helper correctly keeps the CLI and RPC recovery on the same policy-safe Windows invocation, and the RPC now gates installation on a successful pull. The English and Chinese quick-start updates match the implemented three-step Windows sequence. Current-main merge simulation is conflict-free, and my prior finding thread remains resolved.

Nonblocking follow-ups:

• checkout_update_commands() still says the page recovery embeds install_script(), but this revision intentionally changes that path to install_command(); the docstring should name the new shared seam when convenient.
• The three new commits use Co-Authored-By: Claude Code <noreply@anthropic.com> without the actual model ID required by AGENTS.md section 3.3. The repository's commit-message checker does not currently catch that attribution detail.

I reviewed the new delta and full base-to-head diff, all helper call sites, CLI/RPC and installer behavior, relevant history, backward compatibility, test strength, and AGENTS.md/CLAUDE.md/CONTEXT-MAP.md architecture and language constraints.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 passed with 335 passed. Ruff check and format checks, git diff --check, current-main git merge-tree, and the large-file, source-language, and commit-message scripts all passed.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

The new commit correctly updates checkout_update_commands() to name install_command(), resolving the stale-docstring follow-up without changing runtime behavior. The implementation remains mergeable and my earlier finding thread remains resolved.

One nonblocking follow-up remains: the new commit also uses Co-Authored-By: Claude Code <noreply@anthropic.com> without the actual model ID required by AGENTS.md section 3.3, so the same attribution issue now appears in four recent commits. The repository's commit-message checker still passes and does not enforce that detail.

I reviewed the one-line delta, full base-to-head diff context, affected helper call sites, current-main mergeability, backward compatibility, test strength, and the repository rules previously covered.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 passed with 335 passed. Ruff check and format checks, git diff --check, current-main git merge-tree, and the large-file, source-language, and commit-message scripts all passed.

[LivXue]

All five findings from the re-review are fixed, plus two consistency fixes found while re-reviewing, in 9d4e6953e (six commits on top of 9c6b7c4ef).

• Page recovery, Windows (37b4b5ada): install_command() in raven/updates/upgrade.py is now the one definition of the installer invocation (powershell -NoProfile -ExecutionPolicy Bypass -File ".\install.ps1" on Windows, ./install.sh on POSIX). The page's editable recovery reads it and runs the installer only when git pull succeeded (if ($LASTEXITCODE -eq 0)), so a failed pull does not reinstall a checkout that did not move.
• PR description: updated to the three-step Windows sequence (stop, pull, policy-safe installer), including the page and docs changes.
• Release-notes test (368886d0e): pins raven web --stop before git pull before the installer; dropping the stop step now fails the test.
• Docs quick start (93858e763): the English and Chinese pages name the same Windows sequence and warn to fix a failed pull before installing.
• CLI test docstring: now says "separate steps" instead of "two lines".
• Docstring (2c1c24e6d): checkout_update_commands() now names install_command().
• Page recovery, POSIX (57b13b6e2): the page now uses the guarded git pull && ./install.sh one-liner, matching the CLI and the release notes, so a failed pull no longer reinstalls an unmoved checkout. The quick-start POSIX block uses the same one-liner.
• Checkout precedence test (9d4e6953e): the case asserted an exact git pull line, which only holds on the Windows branch; it now checks the substring, so the guarded POSIX form passes.

Verification:

• uv run pytest tests/test_cli_upgrade_commands.py tests/test_updates_upgrade.py tests/test_release_plugin_list.py tests/test_rpc_system.py -q -n 0 -> 334 passed, 1 skipped.
• Five mutation checks (bare page installer, dropped Windows guard, dropped release-notes stop step, bare install_command(), unguarded POSIX pull) each turned the new tests red; the sources were restored byte-for-byte.
• Native Windows 11: the printed installer ran a stub install.ps1 from cmd.exe, Windows PowerShell 5.1 and Git Bash. The page's guarded pull-and-install lines, run under a parent -ExecutionPolicy Restricted, ran the installer after a successful git pull and skipped it after a failed one.
• ruff check, ruff format --check and git diff --check are clean.
• CI at 9d4e6953e: 22 success / 4 skipped / 0 failure, including docs build, coverage gates, all four unit shards and Windows self-upgrade.

This is a comment, not a review approval; the PR still needs a formal approving review.

[LivXue]

Windows compatibility re-review — PR #1136 @ 2c1c24e6d06e18d8c367d020f165f13d686408e4

Scope: the delta since the previously reviewed head 9c6b7c4e is 4 commits / 8 files (+105/−23): the page's checkout recovery now launches the installer as powershell -NoProfile -ExecutionPolicy Bypass -File ".\install.ps1" and only when git pull succeeded (if ($LASTEXITCODE -eq 0) { ... }); install_command() becomes the one definition both the page and the CLI read; the release-notes guidance gains the stop step with a test pinning it; the docs-site EN/ZH pages carry the Windows three-step form; the docstring follows.

Windows angle: correct, and it closes the two real remaining Windows gaps — a bare .\install.ps1 is refused by the stock Restricted client execution policy, and the -File + -ExecutionPolicy Bypass form runs it for that process only; the $LASTEXITCODE guard fails closed (a missing git leaves $null -ne 0, so the installer is skipped), and the page's raven web --stop still precedes the pull and install. POSIX keeps ./install.sh with no stop step.

Verification (native Windows 11; detached worktrees D:\tmp\rv-1136c at head and D:\tmp\rv-base-1136c at base b05267b2; offline venv; scratch HOME/USERPROFILE; PYTHONUTF8=1; PYTHONPATH pinned):

• uv run --no-sync pytest tests/test_cli_upgrade_commands.py tests/test_updates_upgrade.py tests/test_release_plugin_list.py tests/test_rpc_system.py -q -n 0 --tb=line
  • head: 334 passed, 1 skipped (43.9 s)
  • base: 318 passed, 1 skipped (48.4 s)
  • zero failures at both; the 16 added tests pass, including the page-recovery policy-safe invocation and the release-notes stop-step assertions. The single skip is the pre-existing "Windows keeps no POSIX permission bits" case.

Coverage gaps: the generated PowerShell recovery script was verified through the tests and by reading, not executed under a real Restricted-policy shell here; no live page editable-upgrade flow was driven.

No Windows-specific issue found.

[gloryfromca]

Blocking: update the RPC classification test for the guarded POSIX recovery command.

The new POSIX git pull && ./install.sh behavior is sound and aligns the page, CLI, release notes, and quick-start guidance. However, the affected suite now fails because TestUpgradingFromAGatewayHostedPage.test_it_classifies_a_checkout_before_the_unsupervised_refusal still asserts that git pull is a complete standalone line. Update that existing assertion to the new guarded command while preserving its editable-before-unsupervised classification check.

I reviewed the new delta and full base-to-head context, callers, history, backward compatibility, test changes, current-main mergeability, and the repository rules previously covered. I tried to refute the failure as unrelated; it is directly caused by this commit's intended command-shape change.

Verification: uv run pytest tests/test_updates_upgrade.py tests/test_cli_upgrade_commands.py tests/test_rpc_system.py tests/test_release_plugin_list.py -q -n 0 produced 334 passed and 1 failed at tests/test_rpc_system.py:360. Ruff check and format checks, git diff --check, current-main git merge-tree, and the large-file, source-language, and commit-message scripts passed.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

The one-line delta fixes the failing RPC classification test without weakening its editable reason/classification coverage; I replied on and resolved my blocker thread. The focused upgrade, CLI, RPC, and release-plugin suite passes: 335 tests.

I rechecked the delta, affected recovery caller and test, backward compatibility, test integrity, and the previously reviewed architecture. The repository rules and prior CLAUDE/CONTEXT assessment are unchanged. Ruff lint/format, large-file, source-language, commit-message, diff-check, and merge-tree checks pass. The previously reported nonblocking commit-attribution follow-up remains.

[LivXue]

No blockers at 9d4e6953e.

The two re-review findings are fixed: the page's POSIX recovery now uses the guarded git pull && ./install.sh, and the RPC classification test accepts it. CI is green (22 success / 4 skipped / 0 failure), all review threads are resolved, and the PR description carries the required co-author trailer.