refactor(web-shell): simplify remote workspace flow - #12264

E2E test report

✅ Dedicated Chromium remote-workspace flow passed: 6/6 scenarios.

Covered behaviors:

• Settings adds and persists a verified computer, then returns to Connections.
• Add workspace opens the directory browser directly and defaults to This computer.
• Folder source switches to a verified remote computer and lists only that daemon's directories.
• Choosing a remote folder registers it on the selected daemon, not the source daemon.
• Cancel returns to the exact source tab, and Folder source can switch back to This computer.
• With no connected computer, Add workspace opens directly without a Local/Remote choice.

Also passed locally: root build; Web Shell typecheck, lint, and format check; 1,270 focused unit tests.

E2E test report — independent execution at 3fdc8e473ec6

The triage review above recorded that the author's 6/6 Chromium run was "the author's claim, not independently re-run here", and named two verification gaps it could not close from a static read. I re-ran the suite myself in an isolated worktree at this exact commit, with a base arm and a mutation arm. No Critical found; on this evidence the PR is mergeable. I am not approving in this pass — this is the first independent report on the PR, so the approval decision is left to a re-read at an unmoved head.

Arm choice

A tmux TUI arm cannot reach this diff: all 14 non-docs files are under packages/web-shell/client/**, which is a browser bundle the terminal shell never mounts. The substitute is the suite the PR already ships — client/e2e/web-shell.remote-workspace-add.spec.ts, unchanged by this PR (git diff --stat <base>...<head> -- packages/web-shell/client/e2e/ → 0 files), which is itself a static confirmation of the review's "the suite is unaffected" reading.

Matched base/head A/B

Both arms on the same port, same host, same hardlinked dependency tree, one minute apart:

Unit arm over the six test files this PR changes: Test Files 6 passed (6), Tests 262 passed (262).

Mutation witness (the arm that makes the green mean something)

A green browser run alone proves nothing, so I re-added the one line this PR deletes — rememberRemoteConnection(baseUrl) after confirmDaemonTarget(baseUrl) in StandaloneAuth.tsx, plus its import:

Test Files  1 failed (1)
     Tests  1 failed | 47 passed (48)
   × retries with the typed token, stores it per tab, and creates no connection
     131|   expect(localStorage.getItem('qwen-remote-connections')).toBeNull();

It fails on exactly the headline assertion, and only on it. Restoration was witnessed three ways rather than assumed: git diff --exit-code <head-ref> -- packages/web-shell → rc=0, git status --porcelain -- packages/web-shell → 0 lines, grep -c rememberRemoteConnection StandaloneAuth.tsx → 2 before / 0 after, and a re-run → 48 passed (48).

So "an ordinary daemon link no longer writes to the persistent connection catalog" is now independently pinned, not just asserted.

Dangling-reference census (the real risk surface of a −129-line diff)

Grepped across the whole head tree, not just the patch, because a diff against the merge base cannot show a collision main contributed:

Locale parity holds: i18n.tsx declares exactly two Messages objects (EN at 18, ZH at 3998) and the key is dropped from both. Globe2Icon, the per-row badge in WorkspaceSection.tsx:25,106, is untouched — so "remote folders keep their globe marker" is true at the code level and is now also pinned at DOM level by marks each remote workspace folder / leaves local workspace folders unmarked.

No dead switch: main.tsx:464 renders <StandaloneAuth> without an onChangeTarget, so the default at StandaloneAuth.tsx:160 (onChangeTarget = navigateToDaemon) is the migrated function; StandaloneContext.Provider value={true} makes standalone a boolean, so standalone && isRemoteWorkspaceAddActive() is type-sound and behaviourally identical to the old standalone ? getRemoteWorkspaceAddStep() : undefined compared against 'browse'.

The two gaps the review named

"No test pins the fresh-tab re-prompt" — half closed, and the half that is open is not this PR's to close. main.tsx:40-43, which composes UNCONFIRMED_DAEMON_TARGET from !isKnownDaemonTarget(...) and !isRemoteConnectionKnown(...), is byte-identical at base and head (same line numbers, same text). So the fresh-tab re-prompt is caused solely by the catalog no longer being written on a gate pass — it is the intended change, and it is strictly more conservative on the trust axis. The catalog half is pinned and mutation-witnessed above; the main.tsx composition remains untested, but it is unchanged here, so that gap pre-dates this diff.

"Nothing witnesses the chip removal visually" — still true, and I could not close it either. What I can add is that the gap is narrower than it reads: the removal has a DOM-level witness in the two retained sidebar tests, and the visuals suite reporting "no screenshot changed" means no scenario renders a sidebar driven by a cross-origin daemon. That is a coverage gap in the visuals scenarios, not a defect in this diff.

CI at this commit

Lane census complete and per-lane, not read off the rollup: total_count=92 fetched=92 MATCH=True, 37 distinct lane names, zero non-green, zero incomplete. All six product lanes success — Test (ubuntu-latest, Node 22.x), Lint & Static (ubuntu-latest, Node 22.x), Integration Tests (no-AK, No Sandbox), Desktop Shell (ubuntu-22.04), Desktop Shell (windows-2022), web-shell E2E Smoke (ubuntu-latest, Node 22.x). The skipped rows (Test (macos-latest), Test (windows-latest), Integration Tests (CLI)) are event-type skips present on every PR; they are counted as their own bucket here and are not folded into "green".

One non-blocking note on the spec, not on this diff

web-shell.remote-workspace-add.spec.ts:15 hardcodes const REMOTE_ORIGIN = 'http://127.0.0.1:5199', and its own doc comment says any origin works "as long as it differs from the page origin". Running the suite with PLAYWRIGHT_PORT=5199 therefore makes the page origin collide with the mock-daemon origin and fails 5 of 6 scenarios — I hit this myself and it cost a wasted arm before I read line 15. Deriving REMOTE_ORIGIN from the configured port (or asserting the two differ in a beforeAll) would make the suite portable. This is a test-infrastructure robustness point only; it does not affect the PR under review, whose own CI runs on the default port.