feat(setup): guide native Gateway installation and onboarding

[karkarl]

What Problem This Solves

Companion needs a guided onboarding path connecting the Windows Gateway MSIX to its existing setup wizard without separate install, availability-check, and wizard-launch clicks.

User Impact

Eligible devices see native Gateway setup recommended first. Users choose Windows capabilities and permissions, then Companion automatically prepares the package/profile and opens the shared Gateway wizard with progress indicators and completion checkmarks. WSL alternatives appear only when native setup is unavailable.

Windows installation consent and provider sign-in remain interactive. The native Gateway runs as the signed-in Windows user; this PR does not provision an isolated MXC session. Store delivery is not available yet. Missing-package development installs require OPENCLAW_GATEWAY_MSIX_PATH before launching Companion and an ARM64 package. Healthy installed packages do not require that setting.

Why This Change Was Made

• Reuse the capabilities/permissions UI and upstream Gateway wizard.
• Let Windows own MSIX signing, consent and deployment. Companion waits for verified registration and package-qualified aliases with bounded cancellation/retry.
• Preserve lifecycle ownership: the setup session owns temporary runtime validation; the existing connection manager takes over after gated publication. Listener ownership is checked at credential handoff, and finalization cannot race an onboarding restart.
• Save capability choices without overwriting unrelated settings. Completion does not falsely claim a running Gateway or paired Windows node.
• Update six locales, regression coverage and the architecture ledger.

Private workstation paths were removed from code, tests and docs. Unpublished history was consolidated into one sanitized commit, so the removed paths are absent from the outgoing history as well. No local-directory links, runtime profiles, credentials or MSIX payloads are included.

Native package and runtime handoffs

MSIX discovery and installation. Companion checks current-user package name, publisher, health and package-qualified execution aliases, never a generic PATH command. Only a missing package opens Windows App Installer for the configured MSIX after manifest preflight. Windows owns signature validation and consent. Companion waits for verified registration; opening the installer alone is not success. Store delivery remains a follow-up.

Dedicated profiles and process ownership. Each Gateway gets separate configuration, credentials, identity and workspace without replacing the default profile. Companion owns the packaged launcher; the launcher owns Node's separate job. Listener verification therefore checks direct job membership or a live, same-user descendant chain anchored to the retained, expected-package launcher, plus consistent loopback TCP snapshots. Credentials are withheld until ownership is verified. The shared wizard uses authenticated Gateway RPC, not a new cross-package handoff protocol. After configuration/health checks and registry publication, the connection manager takes over startup/reconnect and stops the owned runtime on disconnect, switch or shutdown, preserving profile data.

flowchart TD
    D{"Gateway package registered?"} -->|No| I["Windows App Installer: signature and consent"]
    D -->|Yes| V["Verify package health and qualified aliases"]
    I -->|Registration observed| V
    V --> P["Prepare dedicated Gateway profile"]
    P --> L["Companion-owned packaged launcher"]
    L --> N["Package-owned Node Gateway"]
    N --> O["Verify loopback listener ownership"]
    O --> W["Authenticated shared Gateway wizard"]
    W --> H["Restore reload; validate config and health"]
    H --> R["Stop setup runtime; publish Gateway record"]
    R --> M["Connection manager: start, reconnect, stop"]

Loading

Evidence

The sanitized source passed the full build, 9,237 Shared/Tray/SetupEngine/Connection tests, and all 17 strict Gateway MXC E2E tests. Regular suites had 35 skips; strict MXC had none.

Earlier live isolated UI proof showed completed support/package/profile rows followed by automatic entry into the shared Gateway wizard. Full current-head native interactive completion and normal-owner handoff remain unverified, so this PR is a draft.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• windows-11-arm64: native package/runtime behavior and ARM64 build.
• windows-winui-interactive: recommendation, permissions, progress and shared-wizard UX.
• windows-clean-installer-upgrade: missing-package acquisition; full signed clean-install/upgrade matrix outstanding.
• windows-wsl-gateway-e2e: shared onboarding and connection/pairing regression coverage.
• windows-wsl-mxc: real Gateway-to-Windows-node containment proof, without skips.

Validation

Commands ran on the same source tree preserved in sanitized commit 0207e1f1; only history was consolidated afterward.

Command	Result
.\build.ps1 -DevBuild -Configuration Release	Passed, all projects
dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore	4,013 passed; 33 skipped
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore	3,001 passed
dotnet test .\tests\OpenClaw.SetupEngine.Tests\OpenClaw.SetupEngine.Tests.csproj --no-restore	1,353 passed; 1 skipped
dotnet test .\tests\OpenClaw.Connection.Tests\OpenClaw.Connection.Tests.csproj --no-restore	870 passed; 1 skipped
.\scripts\validate-mxc-e2e.ps1 -NoBuild -Configuration Release -RuntimeIdentifier win-arm64 -ResultsDirectory .\TestResults\NativeSanitizedMxcE2E	17 passed; no skips
.\scripts\validate-docs.ps1	Passed; 49 Markdown files

An unrelated chat timing test failed once, then passed in isolation and in the full rerun. Earlier MXC attempts failed during WSL import/restart; the latest current-source Release run passed.

Rubber-duck review identified missing per-handshake ownership authorization and restart racing native finalization. Both were fixed, regression-covered and verified in a focused follow-up with no remaining high-confidence findings in that verification. Structured python .agents\skills\autoreview\scripts\autoreview --mode local remained blocked by its bundle-size limit; no clean structured review is claimed.

Real Behavior Proof

• Environment tested: Windows ARM64, isolated Companion data, Gateway MSIX 0.0.0.1, real WSL Gateway/MXC fixtures.
• PR head or commit tested: 0207e1f1 source tree for build/tests and strict MXC. Earlier native UI capture predates the final installer-path and handoff-guard changes.
• Exact steps or command run: strict MXC command above. Earlier isolated onboarding selected native setup, reviewed capabilities/permissions, completed Windows App Installer, and automatically entered the shared wizard after profile/runtime preparation.
• Evidence after fix, copied from current-source strict output with local paths omitted:

Test Run Successful.
Total tests: 17
     Passed: 17
Gateway MXC proof passed: MirroredWslSafeGatewayPort_IsListeningAndRecorded
Gateway MXC proof passed: RealGateway_SystemRun_ExecutesThroughWindowsNodeMxcSandbox
Gateway MXC proof passed: RealGateway_SystemRun_BlocksWritesToTrayDataDirectoryInMxcSandbox
MXC validation completed successfully.

• Observed result: real Gateway-to-Windows-node MXC execution and denied writes passed. Earlier native UI displayed completed support/package/profile rows, then OpenClaw onboard without an extra launch action.
• Screenshot or artifact links verified? N/A. Local-directory links and raw runtime artifacts are intentionally omitted.
• Not verified or blocked: current-head native interactive completion and final connection-manager handoff; full signed install/upgrade matrix; Store acquisition; actual MXC session provisioning. No new MCP commands are introduced; fresh manual MCP discovery/invocation proof was not collected.

Security Impact

• New permissions or capabilities? No new node commands; explicit selection of existing capability permissions.
• Secrets or tokens handling changed? Yes: dedicated native profiles and exact-device pairing. Tokens are not passed in command arguments; credential handoff requires listener ownership verification.
• New or changed network calls? Yes: loopback Gateway/wizard RPC. No automatic package download or new Store endpoint.
• Command or tool execution surface changed? Yes: package-qualified launchers and setup/config/health commands; no generic PATH/npm fallback.
• Data access scope changed? Yes: dedicated Companion-managed native profiles, without replacing the default profile or existing WSL gateways.
• Risk and mitigation: native execution uses the signed-in user's rights by design. Windows signing/consent, exact pairing, staged publication, loopback binding, ownership checks and cancellation cleanup remain required.

Compatibility and Migration

• Backward compatible? Yes for existing WSL/remote profiles and connection ownership.
• Config or environment changes? Yes: OPENCLAW_GATEWAY_MSIX_PATH replaces the machine-specific development installer path.
• Migration needed? No automatic profile migration.
• Required action: configure the local MSIX location before starting Companion when the package is absent. Installed healthy packages bypass acquisition. Store delivery and portable package selection are follow-ups.

Review Conversations

• I replied to or resolved every bot review conversation addressed by this PR.
• I left unresolved only conversations that still need maintainer judgment.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[karkarl]

Progress screenshots:

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed September 18, 2026, 3:39 PM ET / 19:39 UTC (Revision 2).

ClawSweeper review

What this changes

Adds guided native Windows Gateway package installation, dedicated profiles, supervised startup, and shared onboarding, while shortening optional wizard steps for native and WSL setup.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

⛔ Blocked before merge - 8 items remain

Keep open: this remains useful work absent from main, and both prior correctness findings remain unresolved. The new screenshots materially improve happy-path evidence, but upgrade validation and native credential-handoff safety remain incomplete.

Priority: P2
Reviewed head: 0207e1f1428b8024d8797a863420c8b26d2a9af1

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	Substantial implementation, regression coverage, and useful new screenshots are offset by two confirmed defects and unresolved native authorization and upgrade evidence.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	Security review found an item that needs attention.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	10 items	Pinned introduction and continuing need: The checkout matches the previously reviewed head. Its verified parent is the fetched main revision. NativeGatewayRuntime and NativeGatewaySetupService are absent at that main revision and v2026.9.4; the native package integration is still a distinct contribution. Explicit answer precedence remains broken: The new Answer/Acknowledge switch bypasses ResolveAnswer, whose first operation honors configured answers. Main called ResolveAnswer directly. The documented WizardAnswers configuration includes prompts now intercepted by this policy. Native dashboard authorization remains disconnected: The new native-record guard always returns false. App.TryResolveChatCredentials, both legacy ChatPage resolution paths, and ConnectionPage.OnSavedRowOpenDashboardAsync still call this WSL provenance service rather than the native runtime.
Findings	2 actionable findings	[P1] Preserve explicit WizardAnswers before applying optional defaults [P2] Route native dashboard and web-chat authorization to its runtime
Security	Needs attention	Establish ownership of the peer receiving credentials: Authorization can restart the genuine runtime and then return package-family proof during an existing WebSocket handshake. A listening-port snapshot does not by itself identify that socket's peer. Establish rejection before token transmission when an unrelated listener accepted the connection and subsequently released the port; this is a plausible unresolved boundary, not a demonstrated credential leak.

How this fits together

Companion setup prepares a local Gateway and collects capability and provider choices. The new native runtime verifies package and listener ownership before credentials are sent, then transfers ongoing operation to the connection manager.

flowchart TD
    A[Gateway choice and permissions] --> B[Verify or install Windows package]
    B --> C[Prepare dedicated profile]
    C --> D[Start and verify owned listener]
    D --> E[Shared onboarding wizard]
    E --> F[Validate configuration and health]
    F --> G[Publish saved Gateway]
    G --> H[Connection manager]

Loading

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Preserve explicit WizardAnswers before applying optional defaults (P1) - For recognized channel, search, skill, and setup-mode prompts, this switch returns the policy answer without consulting WizardAnswers. Existing headless configurations therefore silently receive skip/keep/default answers instead of their configured choices. ResolveAnswer previously gave configured values precedence. Apply optional defaults only when no explicit answer exists, and cover the runner path. This prior finding remains unresolved.
• Route native dashboard and web-chat authorization to its runtime (P2) - Every native record now fails this verifier, but App.TryResolveChatCredentials, legacy ChatPage resolution, and saved-row dashboard opening still use it. Consequently a successfully configured and paired native Gateway cannot open those surfaces. Keep the WSL rejection and route native consumers through fresh runtime ownership authorization instead of bypassing the guard. This prior finding remains unresolved.
• Resolve security concern: Establish ownership of the peer receiving credentials - Authorization can restart the genuine runtime and then return package-family proof during an existing WebSocket handshake. A listening-port snapshot does not by itself identify that socket's peer. Establish rejection before token transmission when an unrelated listener accepted the connection and subsequently released the port; this is a plausible unresolved boundary, not a demonstrated credential leak.
• Resolve merge risk (P1) - A listening-port ownership check may describe a newly restarted Gateway rather than the peer of an already-open handshake socket; rejection before credential transmission remains unproven.
• Resolve merge risk (P1) - Signed fresh-install and upgrade preservation of existing Gateway records, identities, and unrelated settings remains unverified.
• Resolve merge risk (P1) - On eligible devices the recommended native path hides WSL, while missing-package acquisition still requires an externally configured ARM64 development MSIX; ordinary users lack an in-product acquisition or recovery path.
• Complete next step (P2) - Resolve both repeated findings, establish native credential-transmission safety during listener replacement, and complete signed fresh-install/upgrade compatibility evidence.

Findings

• [P1] Preserve explicit WizardAnswers before applying optional defaults — src/OpenClaw.SetupEngine/SetupWizardRunner.cs:483-487
• [P2] Route native dashboard and web-chat authorization to its runtime — src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:300-301
• [medium] Establish ownership of the peer receiving credentials — src/OpenClaw.Connection/NativeGatewayEndpointSecurity.cs:22

Agent review details

Security

Needs attention: Package identity and exact-device pairing checks are present, but native authorization still needs proof that listener replacement cannot authorize the wrong connected peer.

Review metrics

Metric	Value	Why it matters
Production and test growth	production +3,183/-146 (net +3,037); tests +2,928/-15 (net +2,913)	The stated package, runtime, and onboarding ownership work explains the growth, but spans several independently sensitive boundaries.

Merge-risk options

Maintainer options:

1. Repair compatibility and establish handoff safety (recommended)
   Preserve explicit answers, authorize interactive native surfaces through the runtime, and establish upgrade and final credential-transmission safety before landing.
2. Keep the integration staged
   Retain the draft while native acquisition, upgrade preservation, and the disputed handshake boundary are validated.

Technical review

Best possible solution:

Preserve explicit setup choices, share runtime-backed authorization across native connection surfaces, and provide a usable acquisition/recovery path with verified upgrade preservation and credential handoffs.

Do we have a high-confidence way to reproduce the issue?

Yes for the two correctness findings: source traces show explicit WizardAnswers being bypassed and native interactive credentials always rejected. Neither was executed during this read-only review; the handshake replacement concern remains unproven.

Is this the best way to solve the issue?

Partly: reusing the shared wizard and separating runtime ownership is appropriate, but defaults must preserve explicit answers and every interactive credential consumer must use the correct runtime verifier.

Full review comments:

• [P1] Preserve explicit WizardAnswers before applying optional defaults — src/OpenClaw.SetupEngine/SetupWizardRunner.cs:483-487
  For recognized channel, search, skill, and setup-mode prompts, this switch returns the policy answer without consulting WizardAnswers. Existing headless configurations therefore silently receive skip/keep/default answers instead of their configured choices. ResolveAnswer previously gave configured values precedence. Apply optional defaults only when no explicit answer exists, and cover the runner path. This prior finding remains unresolved.
  Confidence: 0.99
• [P2] Route native dashboard and web-chat authorization to its runtime — src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:300-301
  Every native record now fails this verifier, but App.TryResolveChatCredentials, legacy ChatPage resolution, and saved-row dashboard opening still use it. Consequently a successfully configured and paired native Gateway cannot open those surfaces. Keep the WSL rejection and route native consumers through fresh runtime ownership authorization instead of bypassing the guard. This prior finding remains unresolved.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.95

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 84efd0731cda.

Labels

Label changes:

• add merge-risk: 🚨 security-boundary: Native credentials rely on listener revalidation that has not demonstrated rejection of a stale or unrelated connected peer before transmission.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• remove status: ⏳ waiting on author: Current PR status label is status: 📣 needs proof.

Label justifications:

• P2: This is a substantial new setup capability with bounded pre-merge defects, without evidence of a shipped urgent regression.
• merge-risk: 🚨 compatibility: The shared headless runner overrides configured answers, and signed install/upgrade preservation remains unverified.
• merge-risk: 🚨 auth-provider: Native dashboard and legacy web-chat credentials are still routed through a verifier that rejects every native record.
• merge-risk: 🚨 security-boundary: Native credentials rely on listener revalidation that has not demonstrated rejection of a stale or unrelated connected peer before transmission.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Authority-chain proof required: demonstrate that the real native handshake rejects an unrelated or stale connected peer before sending credentials, including listener replacement during runtime recovery. The inspected screenshots positively show installation, completion, and operator/node connection; the reported strict MXC run covers WSL tool containment. Neither establishes this final-effect boundary. Redact private details in additional evidence; updating the PR body triggers re-review, with a maintainer @clawsweeper re-review request available if needed.

Evidence

Security concerns:

• [medium] Establish ownership of the peer receiving credentials — src/OpenClaw.Connection/NativeGatewayEndpointSecurity.cs:22
  Authorization can restart the genuine runtime and then return package-family proof during an existing WebSocket handshake. A listening-port snapshot does not by itself identify that socket's peer. Establish rejection before token transmission when an unrelated listener accepted the connection and subsequently released the port; this is a plausible unresolved boundary, not a demonstrated credential leak.
  Confidence: 0.84

What I checked:

• Pinned introduction and continuing need: The checkout matches the previously reviewed head. Its verified parent is the fetched main revision. NativeGatewayRuntime and NativeGatewaySetupService are absent at that main revision and v2026.9.4; the native package integration is still a distinct contribution. (src/OpenClaw.Connection/NativeGateway/NativeGatewayRuntime.cs:31, 0207e1f1428b)
• Explicit answer precedence remains broken: The new Answer/Acknowledge switch bypasses ResolveAnswer, whose first operation honors configured answers. Main called ResolveAnswer directly. The documented WizardAnswers configuration includes prompts now intercepted by this policy. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:483, 0207e1f1428b)
• Native dashboard authorization remains disconnected: The new native-record guard always returns false. App.TryResolveChatCredentials, both legacy ChatPage resolution paths, and ConnectionPage.OnSavedRowOpenDashboardAsync still call this WSL provenance service rather than the native runtime. (src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:300, 0207e1f1428b)
• Credential authorization boundary: Native authorization can start or replace the runtime during a handshake, then returns package-family proof without process identity. The setup wizard similarly authorizes through the runtime after opening a connection. The remaining question is whether an already accepted socket from an unrelated listener is rejected if that listener yields the port before revalidation starts a genuine Gateway. (src/OpenClaw.Connection/NativeGatewayEndpointSecurity.cs:22, 0207e1f1428b)
• Security tests cover components, not that final transport case: Connection-manager tests inject FakeNativeGatewayRuntime; setup pairing tests inject host/runtime results; runtime tests inject TCP snapshots and processes. The native Windows tests exercise real process creation and ancestry, but do not exercise packaged Gateway credential transmission to a replaced endpoint. (tests/OpenClaw.Connection.Tests/NativeGatewayWindowsProcessHostTests.cs:15, 0207e1f1428b)
• New screenshots provide positive visible proof: All three prepared images from feat(setup): guide native Gateway installation and onboarding #1447 (comment) were inspected locally. They show Windows App Installer, native setup completion, and the same loopback Gateway connected with device-token pairing and six active node capabilities. The comment does not identify the capture revision; these images nevertheless add substantive happy-path evidence beyond the earlier review.

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)
• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• bkudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Preserve explicit headless answers and cover their precedence through the runner.
• Route dashboard and legacy web-chat authorization through the native runtime without weakening ownership checks.
• Add final-effect evidence for unrelated/stale peers during listener replacement, and document signed fresh-install and upgrade preservation.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (1 earlier review cycle)

• reviewed 2026-09-18T19:32:43.104Z sha 0207e1f :: blocked before merge. :: [P1] Preserve explicit WizardAnswers before applying optional defaults | [P2] Route native dashboard and web-chat authorization to its runtime

[natalie-aguinaldo]

Progress screenshots:

very small nit - what about swapping the order to "Verify or Install Gateway package" instead of install or verify? rationale is it'd check if a gateway package is already installed, verify it, otherwise, install it

[natalie-aguinaldo]

This looks great!