V2 onboarding redesign (mount + bridge + theme + Hanselman fixes)

[indierawk2k2]

V2 onboarding redesign

Replaces the legacy onboarding wizard with a redesigned 5-page V2 flow built from designer mocks (tools/v2-design-refs/). V2 is mounted by default in OnboardingWindow; OPENCLAW_USE_V2_SETUP=0 is a kill-switch fallback to legacy for one release cycle.

Pages (in order): Welcome → LocalSetupProgress → GatewayWelcome → Permissions → AllSet

Architecture

• src/OpenClawTray.OnboardingV2/ — new class library: state, app shell, 5 page components, animations, theme palette, V2Strings, system theme detection. Builds against OpenClawTray.FunctionalUI (the existing minimal-Reactor framework).
• src/OpenClaw.SetupPreview/ — standalone WinUI 3 unpackaged exe for the inner-loop. Mounts the V2 tree against a fake OnboardingV2State. Headless capture mode for visual diffs; F2 to cycle themes; fake stage-progression timer for designer review.
• src/OpenClaw.Tray.WinUI/Onboarding/V2/OnboardingV2Bridge.cs — translates real tray services to OnboardingV2State. All cross-thread mutations marshal through DispatcherQueue.
• src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs — host: V2/legacy mount selection, Advanced→legacy round-trip with bridge-back, completion re-keyed for V2 AllSet.
• tools/v2_visual_diff.py — renders V2 pages headless via SetupPreview and produces side-by-side comparisons against designer PNGs (LLM eval rather than pixel diff per design-team request).
• tools/seed_v2_resw.py — idempotent script that adds every V2_* key to all 5 .resw locales.

Service wiring (bridge)

Real service	V2 state field	Notes
LocalGatewaySetupEngine.StateChanged	LocalSetupRows, LocalSetupErrorMessage	Reuses existing LocalSetupProgressStageMap (no fork — V2 picks up every legacy bug-fix)
PermissionChecker.CheckAllAsync + SubscribeToAccessChanges	Permissions (PermissionRowSnapshot list)
Settings.GetEffectiveGatewayUrl	GatewayUrl	ws:// → http:// flip for browser-launch link
Settings.AutoStart ↔ LaunchAtStartup	LaunchAtStartup	Two-way: initial pull from settings, toggle change persists via Settings.Save()
Settings.EnableNodeMode	NodeModeActive	Engine flips it mid-run; bridge mirrors
OnboardingExistingConfigGuard.GetSummary()	ExistingConfig snapshot	Welcome warn-and-confirm UI
App.ConnectionManager.ReconnectAsync()	(side effect)	Re-init operator client on Status=Complete (PairAsync flips EnableNodeMode mid-run, which kills auto-connect at startup)

Easy-button path is logic-identical to v1

The OnboardingV2Bridge restores v1 LocalSetupProgressPage behaviour 1:1:

• replaceConfirmed flag forwarded from V2 state to engine factory and to legacy OnboardingState
• Pre-advance gateway client re-init on Status=Complete (calls ConnectionManager.ReconnectAsync, seeds legacyState.GatewayClient)
• _advanceFiredForCompletion instance guard
• 1-second pause before advance for visual settling
• Existing-config defense check before starting engine
• engine_construct_failed surfaced as user-facing error
• lastRunningPhase derived from state.History

The only logic changes are around Advanced setup and the new V2 flow shell.

Theme support

• V2Theme.cs centralises every theme-aware brush (window/card backgrounds, text, accents, error/warning cards, transparent button overlays, step-dot inactive). Dark mirrors designer mocks; light patterns off WinUI 3 Fluent defaults; brand accents constant across themes per designer spec.
• V2SystemTheme.cs resolves Windows app-mode color via UISettings.GetColorValue(Foreground) (foreground white = dark mode, black = light mode). Application.Current.RequestedTheme is unreliable on unpackaged WinUI 3 apps.
• OnboardingV2State.ThemeMode (System/Light/Dark) drives EffectiveTheme. Bridge resubscribes to UISettings.ColorValuesChanged so live system theme changes flip the UI.
• All 5 V2 pages + shell + StepDots refactored to look up colours via V2Theme. Permissions row icons sit inside a constant-colour dark badge so the designer's white-on-dark PNGs stay visible on light cards.

Advanced setup → legacy Connection round-trip

Welcome's "Advanced setup" link raises V2State.AdvancedSetupRequested → host catches it via the bridge and re-mounts the same FunctionalHostControl onto the legacy OnboardingApp at OnboardingRoute.Connection (no second window). Legacy OnboardingState is constructed up-front so it's available for this swap.

After legacy Connection completes (RouteChanged past Connection), OnRouteChanged re-mounts V2 at the closest equivalent route. Wizard / Permissions / Ready all map to V2 Permissions — Advanced assumes the user is connecting to an already-configured gateway, so the legacy wizard step is intentionally skipped.

A fresh OnboardingV2Bridge is created on bridge-back so the V2 tail (Permissions → AllSet) has live Finished / AutoStart-persist / Refresh / engine wiring.

Cutover (docs/ONBOARDING_V2.md)

• OnboardingWindow.TryCompleteOnboarding recognises both legacy OnboardingRoute.Ready and V2Route.AllSet as terminals
• V2Strings.Resolver = LocalizationHelper.GetString so V2 reads from the same .resw resources as legacy
• 42 V2_* keys seeded into all 5 locales (en-us / fr-fr / nl-nl / zh-cn / zh-tw) with English values via tools/seed_v2_resw.py. LocalizationValidationTests taught (key.StartsWith("V2_")) that V2 strings are intentionally English-only at first ship
• Existing LocalSetupProgressStageMap reused (NOT forked) for stage→row mapping

Hanselman dual-model code review

Ran an adversarial Opus + Codex review against the branch. 9 findings:

Finding	Consensus	Status
Bridge not recreated after Advanced→V2 round-trip — Finish/Refresh/AutoStart/engine all dead	HIGH	fixed
Permissions auto-property doesn't NotifyChanged — V2 never re-rendered real permission state	HIGH (Codex caught, Opus missed)	fixed
"Try again" button stub (no retry pipeline)	HIGH	fixed — RetryRequested event + bridge handler resets engine state
PreviewWindow UISettings subscription leak	HIGH	fixed — moved to fields + Closed handler
NodeModeActive one-way OR latch	HIGH	fixed — direct assignment
MapToV2Rows (V2Stage)i cast assumes ordering	LOW	fixed — explicit StageOrder array + length-mismatch guard
PermissionsPage.AllGranted static V2Strings init	LOW (Opus only)	deferred — preview-only fallback rows, harmless today
OnboardingCompletionPolicy doesn't gate V2 AllSet	LOW (Opus only)	deferred — engine must succeed before AllSet renders
WebView2 handlers stack on retry	LOW (Codex only)	deferred — pre-existing in master

Validation

• ./build.ps1 ✅ all four projects
• OpenClaw.Shared.Tests ✅ 1548 passed / 28 skipped / 0 failed
• OpenClaw.Tray.Tests ✅ 1164 passed / 0 failed
• LLM-eval visual sweep: all 5 pages (+ progress-failed + allset-no-node variants) match designer mocks in both light and dark themes

Manual test pass

Multiple full end-to-end runs from a clean slate (./scripts/dev-reset-rebuild-launch.ps1 -SkipBuild -DontLaunch -WipeWslDistro):

• Welcome → Set up locally → 7-stage WSL install → GatewayWelcome (with embedded provider/model wizard) → Permissions → AllSet → Finish ✅
• Welcome → Advanced → legacy Connection → V2 Permissions → V2 AllSet → Finish ✅
• Existing-config detected → Welcome warn-and-confirm → Replace → engine runs ✅
• Light + Dark + System themes all render correctly; F2 cycles in the preview

Out of scope (follow-up PRs)

• Hatching conversation doesn't fire after V2 Finish — confirmed pre-existing master bug. The hatching bootstrap (OnboardingChatBootstrapper.BootstrapAsync) only runs in the WebView2 chat surface; the native FunctionalUI chat surface (default, added in 08cab69) doesn't have an equivalent. My V2 path didn't touch any chat code.
• V2-styled provider/model wizard — currently the legacy WizardPage is embedded inside V2 GatewayWelcome via a factory closure. The V2 chrome owns the title; the legacy wizard owns the body. A future PR should redesign the wizard step to share V2 card chrome.
• Real translations for V2_ keys* — currently English in all 5 locales.
• Delete legacy onboarding pages — OnboardingApp + WelcomePage + SetupWarning + Wizard + LocalSetupProgress (legacy) + Permissions (legacy) + Ready + Chat are dead code in V2 mode but reachable via kill-switch + Advanced fallback. Deleting requires test refactoring; scope as its own PR.
• Drop the OPENCLAW_USE_V2_SETUP=0 kill-switch after one release cycle on V2.

Co-author

Co-authored with Copilot.

[indierawk2k2]

@shanselman ready for review when you have a chance — V2 onboarding redesign is mounted in the app, easy-button path is logic-identical to v1 master, Hanselman dual-model review findings (5 HIGH consensus) all addressed. PR body has the full architecture + service-wiring table + manual test results. Thanks!

[shanselman]

Requesting changes on the Keep my setup path because this regresses the onboarding bug we just chased down and fixed in #375.

Context: after #340, we proved that “Keep my setup” must be a true dismiss/preserve action: close onboarding without completing setup, without touching settings/autostart, and without continuing into local setup. #375 then fixed the remaining startup gate so node-mode returning users with per-gateway NodeDeviceToken no longer see setup again on relaunch.

PR #381 reintroduces the same class of bug in the V2 flow:

// src/OpenClawTray.OnboardingV2/Pages/WelcomePage.cs
void KeepSetup() => setConfirmingReplace(false);

That only hides the warning card. The user then gets the normal V2 CTA cluster again, including Set up locally. If they click it, ReplaceExistingConfigurationConfirmed is still false, so the bridge falls into the defense-in-depth guard and shows a confusing “Existing configuration detected...” error. That is not “keep my setup”; it is a dead-end path after the user explicitly asked us to preserve their working setup.

There is also a legacy fallback regression in OnboardingWindow: PR #381 removed the _state.Dismissed += OnOnboardingDismissed subscription and the _dismissedWithoutCompletion skip in OnClosed. That was the important #340 behavior: dismissing must not run the completion pipeline.

Suggested fix:

1. Add a first-class V2 dismiss/keep-existing event, e.g. OnboardingV2State.KeepExistingSetupRequested or DismissRequested.
2. Wire V2 “Keep my setup” to the same semantic path as legacy OnboardingState.Dismiss(): set a window-level dismissed-without-completion guard, close the window, do not call TryCompleteOnboarding, and do not mutate settings/autostart.
3. Restore/keep the legacy _state.Dismissed subscription and _dismissedWithoutCompletion handling for the fallback path.
4. Add regression tests that fail on this PR shape:
   • V2 existing-config + Keep my setup closes/dismisses without setting Completed and without invoking OnboardingCompleted.
   • V2 existing-config + Keep my setup does not expose/start local setup afterward.
   • Closing after dismiss does not call TryCompleteOnboarding/settings save/autostart side effects.

How to avoid this going forward: treat “replace existing setup / keep existing setup / advanced setup” as shared onboarding policy, not page-local UI state. Both V1 and V2 should call the same host-level actions for Replace, Keep, and Advanced, and tests should cover those host-level actions rather than only checking the visual page state. This is exactly the kind of lifecycle behavior that gets lost when a redesign reimplements the buttons independently.

[shanselman]

Additional findings from the deep review, separate from the Keep my setup regression above.

1. Stale retry continuation can auto-advance from an old setup run

OnRetryRequested() detaches the old engine event handler and clears _runTask, but the old RunLocalOnlyAsync().ContinueWith(...) is still alive and calls OnEngineStateChanged(finalState) directly:

_runTask = _engine.RunLocalOnlyAsync();
_runTask.ContinueWith(t =>
{
    if (t.IsCompletedSuccessfully && t.Result is { } finalState)
    {
        OnEngineStateChanged(finalState);
    }
}, TaskScheduler.Default);

If a user clicks Try again while the old task is still completing, the stale continuation can observe Complete, set _advanceFiredForCompletion = true, and advance the V2 flow from LocalSetupProgress to GatewayWelcome before the retry run actually completes.

Suggested fix: add an engine generation/run id and ignore stale callbacks.

private int _engineGeneration;

private void OnRetryRequested(object? sender, EventArgs e)
{
    _engineGeneration++;
    ...
}

private void EnsureEngineStarted()
{
    ...
    var generation = _engineGeneration;
    _runTask = _engine.RunLocalOnlyAsync();
    _runTask.ContinueWith(t =>
    {
        if (generation != _engineGeneration) return;
        if (t.IsCompletedSuccessfully && t.Result is { } finalState)
        {
            OnEngineStateChanged(finalState);
        }
    }, TaskScheduler.Default);
}

Even better if the engine supports cancellation/disposal: cancel the old run before starting a new one, and still keep the generation guard as defense-in-depth.

2. NodeModeActive is hard-coded true

OnboardingV2Bridge initializes:

_state.NodeModeActive = true;

That is fine for the local easy-setup happy path, but misleading for Advanced setup, remote reconnect, or MCP-only paths. The All Set page can show “Node Mode Active” even when Settings.EnableNodeMode is false.

Suggested fix: initialize from real settings and only flip true when the local engine actually enables node mode.

_state.NodeModeActive = _settings.EnableNodeMode;

Then keep the existing update in OnEngineStateChanged() after PairAsync changes settings. If the design needs a preview default, keep that in OpenClaw.SetupPreview, not in the real tray bridge.

3. Existing-config guard can permanently block direct local setup route

EnsureEngineStarted() sets _engineStarted = true before the existing-config guard:

if (_engineStarted) return;
_engineStarted = true;

if (!_state.ReplaceExistingConfigurationConfirmed && existingConfig)
{
    ...
    return;
}

If an env override, future deep link, or route bug opens directly on LocalSetupProgress, the guard returns early and _engineStarted remains true. A later confirmation/retry cannot start the engine.

Suggested fix: only set _engineStarted = true after all preflight guards pass, or reset it before the guarded return.

if (_engineStarted) return;

if (blockedByExistingConfig)
{
    ...
    return;
}

_engineStarted = true;

4. V2 shows Try again for terminal failures

LocalSetupProgressPage shows the error card and retry button for any failed row, and OnRetryRequested() always restarts. Legacy behavior distinguishes retryable failures from terminal failures.

Suggested fix: carry a CanRetry flag or the original LocalGatewaySetupStatus into OnboardingV2State.

public bool LocalSetupCanRetry { get; set; }

Set it true only for FailedRetryable (and only for Blocked if that is intentionally retryable), render the Try again button only when true, and also gate OnRetryRequested() so a terminal failure cannot restart through a stale UI event.

5. New projects are missing from the solution

The PR adds:

• src/OpenClawTray.OnboardingV2/OpenClawTray.OnboardingV2.csproj
• src/OpenClaw.SetupPreview/OpenClaw.SetupPreview.csproj

but openclaw-windows-node.slnx does not include either. Command-line builds work through project references, but Visual Studio/Rider users will not see or build the new projects from the solution.

Suggested fix: add both projects to /src/, with the same x64/ARM64 platform mapping used by the WinUI projects. OpenClaw.SetupPreview especially needs concrete platform mapping because it is WinUI/WindowsAppSDK.

6. V2Theme creates static WinUI brushes at class-load time

V2Theme has static SolidColorBrush fields. SolidColorBrush is a WinUI dependency object, so it is safest to create it on the UI thread. This likely works today because render code touches V2Theme first, but it is brittle for tests or future non-UI callers.

Suggested fix: avoid static dependency-object instances. Either use Lazy<SolidColorBrush> and only access from UI render, or return cached brushes through the same B(...) path used for themed brushes. At minimum, avoid touching V2Theme from background tests/helpers.

7. CI red: integration timeout still needs triage

Local required validation passed for me in the PR worktree:

• ./build.ps1
• Shared tests: 1548 passed / 28 skipped
• Tray tests: 1164 passed
• OpenClaw.SetupPreview builds after restore

But GitHub CI is red on OpenClaw.Tray.IntegrationTests.McpHttpServerIntegrationTests.CanvasEval_ReturnsResultOrWellFormedError, timing out after the 30s HTTP client timeout. That may be environmental, but this PR should not merge with red CI unless we confirm it is unrelated/flaky and rerun green.

[indierawk2k2]

@shanselman thanks for the keepSetup() heads up. Pushed 488c94f which:

1. Merges current master to absorb PR fix(onboarding): skip wizard for paired operators and make "Keep my setup" actually dismiss #340 (the legacy Dismiss machinery + per-gateway operator-token scan we missed when we cut this branch).
2. Applies your PR Fix startup setup check for per-gateway node tokens #375's symmetric fix locally (refactored to HasAnyDeviceTokenForRole(dataPath, role), used for both operator and node, and StartupSetupState.HasStoredNodeDeviceToken now delegates to it). I'll happily drop the local copy if/when Fix startup setup check for per-gateway node tokens #375 merges first.
3. Wires V2 equivalents of the Dismiss machinery so the V2 redesigned UI gets the fix too: OnboardingV2State adds Dismissed + idempotent Dismiss(); the V2 Welcome "Keep my setup" button now calls Props.Dismiss() instead of just toggling the warning off; OnboardingV2Bridge surfaces Dismissed; OnboardingWindow reuses the existing _dismissedWithoutCompletion flag for both legacy and V2 dismiss paths.

Validation: build green; Shared.Tests 1548/0/28 skipped; Tray.Tests 1178/0 (+14 from #340's new coverage).

[shanselman]

Re-reviewed latest head 488c94f. Thanks for the quick update — the Keep my setup regression looks fixed now.

What I verified as fixed:

• V2 now has a real dismiss signal: WelcomePage.KeepSetup() calls Props.Dismiss(), OnboardingV2State.Dismiss() is idempotent, OnboardingV2Bridge relays it, and OnboardingWindow closes with _dismissedWithoutCompletion so the completion pipeline does not mutate existing setup.
• The legacy OnboardingState.Dismissed path is restored.
• The PR absorbed the per-gateway node-token startup fix from Fix startup setup check for per-gateway node tokens #375 and added regression tests around it.

Local validation on this head passed:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 1548 passed / 28 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1178 passed

Still requesting changes on these remaining items:

1. _engineStarted is still set before the existing-config guard

In src/OpenClaw.Tray.WinUI/Onboarding/V2/OnboardingV2Bridge.cs, EnsureEngineStarted() does this:

if (_engineStarted) return;
_engineStarted = true;
...
if (!ReplaceExistingConfigurationConfirmed && HasExistingConfiguration())
{
    ...
    return;
}

If a caller reaches this guard before replace is confirmed, the method returns with _engineStarted == true. A later attempt after the user confirms replacement can hit the early return and never create/start the engine.

Suggested fix: move _engineStarted = true until after the guard passes, or reset it before every guarded return. A good regression test would simulate: existing config present -> direct local setup start blocked -> set replace-confirmed -> start again -> engine factory is invoked.

2. Retry still allows a stale run-task continuation to update V2 state

OnRetryRequested() detaches StateChanged, resets _runTask, and starts a fresh engine, but the previous RunLocalOnlyAsync().ContinueWith(...) can still complete later and call OnEngineStateChanged(finalState) from the stale run.

Suggested fix: add a generation/task identity guard. For example, increment _engineGeneration whenever a new run starts or retry resets, capture it in the continuation, and no-op if the captured generation is no longer current.

3. Terminal/blocked failures still show the same Try again affordance

OnEngineStateChanged() maps FailedRetryable, FailedTerminal, and Blocked into the same LocalSetupErrorMessage, and LocalSetupProgressPage renders Try again for any failed row with an error message.

Suggested fix: carry retryability into V2 state, e.g. LocalSetupCanRetry, and render the retry button only for FailedRetryable. Terminal/blocked cases should show the error and route the user back / to Advanced Setup instead of offering a retry loop.

4. New projects are still missing from openclaw-windows-node.slnx

The solution still does not include:

• src/OpenClawTray.OnboardingV2/OpenClawTray.OnboardingV2.csproj
• src/OpenClaw.SetupPreview/OpenClaw.SetupPreview.csproj

Please add both so Visual Studio / solution builds include the new V2 project and preview app explicitly.

Lower priority: I’m less worried about the hard-coded NodeModeActive = true if V2 local setup is intentionally node-only, but if V2 later gains a non-node completion path this should be seeded from actual settings/route instead. Also, V2Theme moved many brushes behind a cache, but it still has static SolidColorBrush accent fields; not blocking, just worth converting those to lazy/cache accessors too if you are already touching that file.

[indierawk2k2]

@shanselman thanks for the careful re-review. Pushed 136e3e0 (on top of merging current master) which addresses all four items:

1. _engineStarted permanent-block — moved the flag set to AFTER all preflight guards. Also reset to false in the engine-construction catch path, so transient construction failures stay recoverable. The synthetic existing-config block is now marked retryable so the user can back up to Welcome, confirm replace, and Try-again without restarting the flow.

2. Stale retry continuation race — added monotonic _engineGeneration. OnRetryRequested bumps it before resetting bookkeeping; EnsureEngineStarted captures it before kicking off RunLocalOnlyAsync; the ContinueWith no-ops if the captured value no longer matches. Old runs can no longer reach OnEngineStateChanged and auto-advance V2 after the user clicked Try-again.

3. Try-again on terminal failures — added OnboardingV2State.LocalSetupCanRetry. Bridge sets it true ONLY for FailedRetryable; FailedTerminal and Blocked clear it. LocalSetupProgressPage.BuildErrorCard now takes Action? onTryAgain and omits the button when null (single-column grid layout in that case). OnRetryRequested is gated on LocalSetupCanRetry as defense-in-depth so a stale UI event from a pre-rerender click can't restart the engine on a terminal failure.

4. Slnx additions — added OpenClawTray.OnboardingV2 (no platform mapping needed) and OpenClaw.SetupPreview (with x64/ARM64 mapping like Tray.WinUI, since it's WindowsAppSDKSelfContained=true). Both now visible in VS/Rider.

Tests added in OpenClawTray.OnboardingV2.Tests: 3 new LocalSetupCanRetry_* tests covering default, set-true, and idempotent-setter semantics. The bridge-level simulation you suggested for #1 (existing-config blocked → confirm-replace → engine-factory invoked) is the right shape, but constructing OnboardingV2Bridge with a mock factory pulls in App.xaml.cs (gateway client reseeding) which we don't have a clean way to unit-test without the WinUI runtime. The fixes have strong inline contract comments documenting the invariants — open to ideas if you have a cheap testing seam in mind.

Validation (worktree, OPENCLAW_REPO_ROOT set):

• ./build.ps1 ✅
• Shared.Tests — 1548 passed / 28 skipped ✅
• Tray.Tests — 1197 passed (+19 from master merge) ✅
• OpenClawTray.OnboardingV2.Tests — 7 passed (+3 CanRetry) ✅

Lower-priority items not addressed (per your note they're not blocking): hard-coded NodeModeActive = true in the bridge constructor (still right for the local-only V2 flow), and the static V2Theme accent SolidColorBrush fields. Happy to do those in a follow-up if you'd like.

[indierawk2k2]

@shanselman quick re-review ping — head is now 60c54da. Two new commits since your last pass:

136e3e0 — addresses your re-review of 488c94f:

1. _engineStarted permanent-block (your finding Add unit tests and code review for Moltbot.Shared #1) — moved flag to AFTER all preflight guards in EnsureEngineStarted. Synthetic existing-config block is now marked retryable (LocalSetupCanRetry=true) so the user can back up to Welcome, confirm replace, and Try-again without restarting onboarding. Engine-construction catch path also resets _engineStarted so transient construction failures stay recoverable.
2. Stale retry continuation race (your finding Rename MoltBot to OpenClaw across entire codebase #2) — added monotonic _engineGeneration. OnRetryRequested bumps it; EnsureEngineStarted captures it before RunLocalOnlyAsync; the ContinueWith no-ops if generation no longer matches. Old runs can no longer reach OnEngineStateChanged and auto-advance V2 after the user clicked Try-again.
3. Try-again on terminal failures (your finding WinUI tray menu crashes in Microsoft.UI.Windowing.Core.dll after idle/interaction #3) — added OnboardingV2State.LocalSetupCanRetry. Bridge sets it true ONLY for FailedRetryable; FailedTerminal and Blocked clear it. LocalSetupProgressPage.BuildErrorCard now takes Action? onTryAgain and omits the button when null. OnRetryRequested is gated on LocalSetupCanRetry as defense-in-depth.
4. Slnx additions (your finding Fix WinUI tray menu crash with invisible anchor window pattern #4) — added OpenClawTray.OnboardingV2 and OpenClaw.SetupPreview (with x64/ARM64 mapping like Tray.WinUI). Both visible in VS/Rider now.

Plus 3 new LocalSetupCanRetry_* tests in OpenClawTray.OnboardingV2.Tests.

60c54da — fixes from a live setup test + a follow-up Hanselman pass:

• Bug: gateway wizard fell through to "offline" branch on first-run V2 setup (no wizard.start ever fired). Root cause: bridge skipped ReconnectAsync after engine Complete because the engine's bootstrap-pairing lifecycle still reported IsConnectedToGateway==true momentarily — the socket then died after Phase 14/15 cleanup, leaving the wizard with a zombie client. Fix: ALWAYS call ReconnectAsync after Complete, await it from a Task.Run, re-seed legacy.GatewayClient from the post-reconnect value via the dispatcher. Pre/post diagnostic log lines added.
• Bug: V2 Welcome → Advanced setup → Back on legacy Connection landed the user on V2 Permissions instead of V2 Welcome. The route-map catch-all _ => V2.Permissions was swallowing the SetupWarning event. Fix: explicit SetupWarning => V2.Welcome and Chat => V2.AllSet mappings.
• Hardening from the Hanselman pass: capture _engineGeneration around the forced ReconnectAsync so a Retry mid-reconnect can't have its post-reseed continuation race the new run. Added _disposed checks at 3 points so post-dispose continuations don't mutate a torn-down OnboardingState. Dropped the immediate "zombie seed" of legacy.GatewayClient; it's now set exactly once by the post-reconnect dispatcher continuation. Catch-all on the route map now logs unmapped legacy routes instead of silent fallback.

Validation (worktree, OPENCLAW_REPO_ROOT set):

• ./build.ps1 ✅
• Shared.Tests — 1548 passed / 28 skipped ✅
• Tray.Tests — 1197 passed ✅
• OpenClawTray.OnboardingV2.Tests — 7 passed ✅

Live manual test: V2 setup completes → wizard mounts with provider/model picker → Permissions → AllSet. V2 Welcome → Advanced → Back returns to V2 Welcome correctly.

Lower-priority items from your earlier review still open (per your note, not blocking):

• Hard-coded NodeModeActive = true in the bridge constructor — fine if V2 stays node-only; would need re-seed-from-settings if a non-node completion path is ever added.
• Static V2Theme accent SolidColorBrush fields — partial cleanup happened, accents could move to Lazy<> too.

Happy to do those in a follow-up if you'd like. Otherwise this should be ready for another look.

[indierawk2k2]

Superseded by #411, which has merged.