feat(onboarding): WSL local gateway setup, onboarding wizard, and security hardening

.gitignore

@@ -349,3 +349,5 @@ test_ws.py
 
 # Local visual test output
 visual-test-output/
+
+.squad/

.squad/decisions/inbox/aaron-actually-fix-2-3.md

@@ -0,0 +1,31 @@
+# Aaron: actual fixes for PR #274 bugs 2 and 3
+
+## Bug 2 — tray quick-chat broken
+
+Traced tray left-click to `InitializeTrayIcon()` -> `_trayIcon.Selected += OnTrayIconSelected` -> `OnTrayIconSelected()` -> `ShowChatWindow()`. The quick-chat path did use `ShowChatWindow`, but it resolved only `settings.Token` while the working operator client resolves `settings.Token`, `settings.BootstrapToken`, then stored `DeviceIdentity.DeviceToken` via `GatewayCredentialResolver`.
+
+Changes:
+- `App.ShowChatWindow()` and chat pre-warm now use the same `GatewayCredentialResolver` pattern as the operator client.
+- `ShowChatWindow()` calls `ChatWindow.RefreshCredentials()` on every tray click, including newly-created windows.
+- `ChatWindow.RefreshCredentials()` always rebuilds the URL and navigates initialized WebView2 to it; it no longer returns early when the same stale URL is cached.
+- Added diagnostic logs: `[ChatWindow] Quick-chat credentials resolved from ...` and `[ChatWindow] Refreshing to ...`.
+- Applied Mattingly Bug 4 handoff: bootstrap injection now runs from `ChatWindow` after successful WebView navigation.
+
+Manual validation for Mike: click tray icon; tail `%LOCALAPPDATA%\OpenClawTray\openclaw-tray.log` and look for `[ChatWindow] Refreshing to ...`, then verify chat loads without login loop.
+
+## Bug 3 — pairing toast notification storm
+
+Searched toast paths and traced pairing notifications through `WindowsNodeClient` direct `PairingStatusChanged` emitters (`pairing.requested`, `pairing.resolved`, `NOT_PAIRED`, and `hello-ok`) plus tray toasts in `App.OnPairingStatusChanged()` and `App.OnNodeStatusChanged()`.
+
+Changes:
+- Routed all `WindowsNodeClient` pairing emitters through `EmitPairingStatusOnTransition()`; duplicates now log `[NODE] Suppressing duplicate pairing status event: ...`.
+- Added a toast-boundary 30-second dedupe in `App.ShowToast(builder, toastTag, deviceId)`, keyed by `(toastTag, deviceId)`.
+- Tagged node pairing pending/paired/rejected and node-connected toasts.
+- Suppressed the node-connected toast if a node-paired toast was just shown for the same device.
+- Added diagnostic logs: `[ToastDeduper] Showing toast tag=... deviceId=...` and `[ToastDeduper] Suppressed duplicate toast tag=... deviceId=...`.
+
+Manual validation for Mike: complete pairing; expect exactly one node-paired toast and log line `[ToastDeduper] Showing toast tag=node-paired deviceId=...`; duplicates should log suppression.
+
+## Validation
+
+Ran `./build.ps1`: passed. Per fast-loop directive, skipped `dotnet test`.

.squad/decisions/inbox/mattingly-actually-fix-1-4-5.md

@@ -0,0 +1,45 @@
+# Mattingly: actual fixes for PR #274 bugs 1, 4, 5
+
+## Bug 1 — chat window auto-launch on Finish
+
+Changed `OnboardingWindow.OnWizardComplete()` to ignore `WizardLifecycleState == "complete"`. The signal now is: the window is completing from `OnboardingRoute.Ready` and `StartupSetupState.RequiresSetup(settings, identityDataPath)` is false. That is the path the Finish button actually takes: `Ready` page Finish -> `OnboardingState.Complete()` -> `OnOnboardingFinished()` -> `OnWizardComplete()`.
+
+Log to validate: `[OnboardingWindow] OnWizardComplete launching chat`.
+
+## Bug 4 — BOOTSTRAP.md kickoff injection
+
+Hardened `BootstrapMessageInjector`:
+
+- Traverses shadow DOM for Lit UI controls.
+- Probes and logs visible control count: `[OpenClaw] Bootstrap probe controls=N`.
+- Supports `textarea`, text inputs, contenteditable, and role=textbox.
+- Uses native value setters so controlled inputs see the value.
+- Clicks Send/form-submit/Enter fallbacks.
+- Does **not** burn `HasInjectedFirstRunBootstrap` when the script returns `no-input`; the gate is only persisted on `sent`.
+
+Aaron still needs to move the call site to after successful chat navigation because current `App.ShowChatWindow()` can see `TryGetScriptExecutor()==null` when the WebView2 is still initializing.
+
+Exact handoff line for Aaron in `ChatWindow.xaml.cs` NavigationCompleted success branch after `RequestChatInputFocus();`:
+
+```csharp
+OpenClawTray.Services.BootstrapMessageInjector.ScriptExecutor exec = script => WebView.CoreWebView2.ExecuteScriptAsync(script).AsTask();
+_ = OpenClawTray.Services.BootstrapMessageInjector.InjectAsync(exec, ((App)Microsoft.UI.Xaml.Application.Current).Settings, initialDelayMs: 500);
+```
+
+If `App.Settings` is not exposed, add an internal property returning `_settings`, or route the existing `_settings` from `App.ShowChatWindow()` into a ChatWindow method. The important point is that the call must happen inside `NavigationCompleted` when `e.IsSuccess` is true.
+
+## Bug 5 — autostart default/toggle
+
+Changed `ReadyPage` to render the toggle ON as a safety default, then sync to `Settings.AutoStart` on mount and immediately call `AutoStartManager.SetAutoStart()` so a user who never toggles still gets the Run-key. The toggle handler still persists settings and updates the Run-key immediately.
+
+Changed `AutoStartManager.SetAutoStart()` to use `Registry.CurrentUser.CreateSubKey(...)` instead of `OpenSubKey(...)`, so it can create the Run key/value when missing instead of silently returning.
+
+Manual registry validation:
+
+```powershell
+Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name OpenClawTray -ErrorAction SilentlyContinue
+```
+
+## Validation
+
+Ran `./build.ps1`: passed. Per fast-loop directive, skipped `dotnet test`.

.squad/decisions/inbox/mattingly-finish-actually-hub.md

@@ -0,0 +1,58 @@
+# Mattingly — PR #274 finish should open Hub chat
+
+## Audit
+
+Command requested: `grep -rn "launching chat\|ShowChatWindow\|ShowHub\|OnWizardComplete" src/OpenClaw.Tray.WinUI` (run with ripgrep equivalent because `rg` was not on PATH in PowerShell; Copilot rg tool was used against the same tree).
+
+HEAD before this fix: `8c68111 Launch hub chat after onboarding`.
+
+Matches found:
+
+- `src/OpenClaw.Tray.WinUI/App.xaml.cs:498` — tray icon click calls `ShowChatWindow()`.
+- `src/OpenClaw.Tray.WinUI/App.xaml.cs:501` — `ShowChatWindow()` method.
+- `src/OpenClaw.Tray.WinUI/App.xaml.cs:542` — `ShowChatWindow` deferred-show warning string.
+- `src/OpenClaw.Tray.WinUI/App.xaml.cs:644` — tray menu `openchat` calls `ShowChatWindow()`.
+- `src/OpenClaw.Tray.WinUI/App.xaml.cs:562,581,647,652,654,710,1043,1855,2809,2928,3048,3101,3603,4265` — `ShowHub(...)` method/call sites.
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs:587` — Finish event calls `OnWizardComplete()`.
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs:596` — X/Closed path calls `OnWizardComplete()`.
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs:620` — single `OnWizardComplete()` implementation.
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs:649` — required diagnostic log line.
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs:650,658,660,667,671,675,679` — deferred Hub chat launch helper.
+- Documentation/comment-only references in `ChatWindow.xaml.cs`, `HubWindow.xaml.cs`, `VoiceOverlayWindow.xaml.cs`, and `OnboardingState.cs`.
+
+The literal old string `launching chat` has no remaining source match in this worktree.
+
+## Diagnosis
+
+The log Mike captured (`[OnboardingWindow] OnWizardComplete launching chat`) corresponds to the pre-`8c68111` body of `OnboardingWindow.OnWizardComplete` in `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs`, the only wizard-completion implementation. In the current clean worktree, `8c68111` did change that exact method to log `[OnboardingWindow] OnWizardComplete launching HubWindow on chat tab` and call `App.ShowHub("chat")`.
+
+I did not find a second `OnWizardComplete`, overload, post-finish hook, or hidden `ShowHub` fallback to `ChatWindow`. `App.ShowHub(...)` creates a `HubWindow` when `_hubWindow` is null/closed, sets state, navigates, and activates it. The remaining `ShowChatWindow()` calls are tray quick-chat entry points, not wizard finish paths.
+
+The prior fix therefore did not take in the live run because that run was not executing source/binaries containing `8c68111` (or was launched from another stale build/worktree). To make the wizard finish path more robust and easier to verify, this follow-up keeps the exact required log line and dispatches `ShowHub("chat")` at low priority after the wizard close event settles, so the Hub opens after the wizard finishes closing and cannot lose an ordering fight to wizard teardown.
+
+## Changes
+
+- `src/OpenClaw.Tray.WinUI/Onboarding/OnboardingWindow.cs`
+  - Keeps the required log line: `[OnboardingWindow] OnWizardComplete launching HubWindow on chat tab`.
+  - Replaces the inline post-finish call with `ShowHubChatAfterWizardClose()`.
+  - The helper dispatches `App.ShowHub("chat")` on the UI dispatcher at low priority, with a direct fallback if enqueue fails.
+  - Adds an explicit warning if `Application.Current` is not the tray `App`.
+  - Updates stale bootstrap comment from `App.ShowChatWindow()` to HubWindow chat navigation.
+
+- `src/OpenClaw.Tray.WinUI/Onboarding/Services/OnboardingState.cs`
+  - Updates stale route comment to say the Ready path launches the Hub chat tab, not the old chat window.
+
+- `src/OpenClaw.Tray.WinUI/Services/BootstrapMessageInjector.cs`
+  - Updates stale comment to describe HubWindow chat page injection instead of post-wizard `App.ShowChatWindow()`.
+
+## Validation
+
+- `git pull --rebase fork feat/wsl-gateway-clean` before commit: already up to date.
+- `./build.ps1`: passed.
+- Tests intentionally not run per active directive: NO tests, incremental `./build.ps1` only.
+
+## Verification log line
+
+Mike should verify this exact line on the next finish run:
+
+`[OnboardingWindow] OnWizardComplete launching HubWindow on chat tab`

.squad/decisions/inbox/mattingly-finish-launch-hubwindow.md

@@ -0,0 +1,21 @@
+# Mattingly: Finish opens HubWindow chat
+
+## Summary
+Onboarding completion from Ready now launches the full HubWindow directly on the Chat tab instead of the standalone quick-chat ChatWindow.
+
+## Changes
+- `src\OpenClaw.Tray.WinUI\App.xaml.cs`
+  - Made `ShowHub(string? navigateTo = null, bool activate = true)` internal so onboarding can reuse the existing hub-opening path.
+- `src\OpenClaw.Tray.WinUI\Onboarding\OnboardingWindow.cs`
+  - Replaced `ShowChatWindow()` completion launch with `ShowHub("chat")`.
+  - Added diagnostic log: `[OnboardingWindow] OnWizardComplete launching HubWindow on chat tab`.
+- `src\OpenClaw.Tray.WinUI\Pages\ChatPage.xaml.cs`
+  - Wired `BootstrapMessageInjector.InjectAsync` into the Hub chat WebView2 `NavigationCompleted` success path, matching the standalone `ChatWindow` gated injection behavior.
+
+## Validation
+- Ran `./build.ps1` successfully after the code change.
+- Per active session directive, did not run tests after the fix.
+
+## Architectural notes
+- Hub already exposes tag-based navigation through `NavigateTo("chat")`; `ShowHub("chat")` selects the existing NavigationView item and navigates to `ChatPage`.
+- Bootstrap injection remains wired in both standalone `ChatWindow` and Hub `ChatPage`; the existing global `Settings.HasInjectedFirstRunBootstrap` gate ensures only one path injects.