Gap A: Gateway wizard has no per-step Back navigation (server-driven, needs wizard.previous RPC)

[indierawk2k2]

Symptom: The gateway wizard (WizardPage) has no per-step Back navigation. Once the user advances past a step, they cannot return to fix an answer. Combined with terminal-error wedges, this traps users at the wrong branch with no recovery path. (Mike's 2026-05-13 session: picked the API-key option, ended up in a custom-endpoint URL prompt instead, entered an invalid value, no way back to fix the choice.)

Why it's architectural: The wizard is server-driven. The gateway sends step payloads via wizard.start / wizard.next / wizard.status RPCs. The protocol surface (per src/OpenClaw.Shared/OpenClawGatewayClient.cs:296) is exactly those four method names plus wizard.cancel. There is no wizard.back or wizard.previous. Adding client-side Back requires either:

1. A new wizard.back / wizard.previous RPC on the gateway with semantics for retracting answers and side-effectful steps (OAuth, device-code polling, progress markers), OR
2. A client-side payload-history stack which would desynchronise from gateway state.

This needs cross-repo design (gateway server team owns the protocol decision).

Bonus discovery: wizard.cancel is declared in the protocol surface (OpenClawGatewayClient.cs:296) but has zero callers across the tree. Restart logic uses clearWizardSessionState() + a fresh wizard.start instead (see WizardFlowController.cs:119). If a future Back/Cancel UI is built, the cleanup path should call wizard.cancel so the gateway can free server-side state.

Source pointers (from Mattingly's investigation):

Concern	Location
Protocol surface	src/OpenClaw.Shared/OpenClawGatewayClient.cs:296
Wizard buttons (only Continue/Skip/Retry — no Back)	src/OpenClaw.Tray.WinUI/Onboarding/Pages/WizardPage.cs:632-636
Outer page Back (does NOT cancel wizard session)	src/OpenClaw.Tray.WinUI/Onboarding/OnboardingApp.cs:55, 157
Onboarding docs	docs/ONBOARDING_WIZARD.md:37

Severity: Medium UX. Not breaking, but creates wedge scenarios when combined with bad user input.

Recommended path:

1. Gateway team designs wizard.previous semantics (idempotent rewind? state retraction? side-effect rules?)
2. After protocol lands, client adds Back button + handler calling new RPC
3. Same change should wire wizard.cancel from existing client cleanup paths

Filed by: coordinator on behalf of Mattingly's investigation (see .squad/decisions/inbox/mattingly-wizard-recovery-affordances.md Gap A).

[shanselman]

Triage note: this still looks like a real UX gap, but it is blocked on gateway protocol semantics rather than being a Windows-only UI fix.

Please either scope/update this into a concrete cross-repo protocol issue for wizard.previous / wizard.back semantics, or close it if we are not going to add server-side rewind support. I do not think we should implement a fake client-side Back stack because the wizard is server-driven and that would risk desynchronizing from gateway state.

A smaller Windows-only cleanup can be tracked separately: call wizard.cancel from current cancel/restart/outer-back paths when a server-side wizard session exists.