Replace API-driven setup happy path with UI wizard walkthrough - #101
Merged
Merged
Conversation
…hrough The new spec drives the real SetupWizard through every step in a live browser session — WiFi scan → pick SSID → password → Update (often auto-advances) → Credentials (password + hotspot-off) → AI Models (OpenAI placeholder, overwritten by 80-chat's beforeAll with the real CLAWBOX_AI_API_KEY) → Local AI Skip → Telegram → completion overlay → desktop shell. This replaces 10-happy-path.spec.ts which only hit /setup-api/* routes directly. The new shape covers the same routes but also validates: - SetupWizard renders each step's data-testid - step-to-step transitions trigger on form submit - Ethernet banner + Connect-to-WiFi path - Middleware flips authenticated users from /setup to / Hotspot is toggled off on the credentials step because the fixture provider's hotspot password fields are a second tier of optional config; 20-settings covers the hotspot SSID/password path explicitly later. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Iterative fixes from the full-suite run:
- 10-setup-wizard: OpenAI tab defaults to Subscription; click API Key
first to show the token input. Bumped the post-Connect wait from 30s
to 90s on the credentials→ai-models transition (cold chpasswd
systemd unit is slow on first hit) and the post-AI-Connect wait from
30s to 120s (configure overlay animates across 22s of phases plus a
gateway restart/readiness poll). Drop the brittle
setup-completion-overlay assertion — the overlay flashes by too fast
on fast paths; just wait for the final `/` navigation.
- Telegram step: use `getByRole('textbox', { name: /Bot Token/i })`
instead of placeholder selectors, matching the actual ARIA label.
- 80-chat UI widget: the fresh-wizard path leaves `ui_chat_open` false
so the ChatPopup isn't auto-open when the test navigates to /. Flip
the pref via /setup-api/preferences before goto, which removes the
need to chase the mascot-click open handler.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
📝 WalkthroughWalkthroughReplaces a removed end-to-end install verification with a new Playwright SetupWizard spec that drives the UI through install (WiFi, credentials, hotspot, AI, optional Telegram), verifies post-setup status, and updates the chat test to preconfigure UI preferences before loading the app. Changes
Sequence Diagram(s)sequenceDiagram
participant Browser as Browser (Playwright)
participant SetupAPI as Setup API
participant Device as Device/System
participant AI as External AI Provider
participant Telegram as Telegram API
Browser->>SetupAPI: GET install logs & GET /setup status
alt needs-install absent & initial status
Browser->>Device: request WiFi scan (test SSID)
Device-->>Browser: scanned SSID list
Browser->>SetupAPI: POST /setup-api/wifi/connect (SSID + pass)
SetupAPI->>Device: configure wifi
Device-->>SetupAPI: wifi configured
end
Browser->>SetupAPI: POST /setup-api/credentials (user/password)
Browser->>SetupAPI: POST /setup-api/hotspot (toggle off)
Browser->>AI: provide/validate API key via UI
AI-->>SetupAPI: validation response
alt Telegram token present
Browser->>Telegram: attempt bot connect (via SetupAPI)
Telegram-->>SetupAPI: token validated
end
Browser->>SetupAPI: POST /setup-api/setup/complete
SetupAPI-->>Browser: redirect to /
Browser->>Browser: render desktop UI, assert shelf launcher visible
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@e2e-install/10-setup-wizard.spec.ts`:
- Around line 87-95: The current 8s probe on credentialsStep can race with the
wizard advancing and cause a hard assert on updateStep; replace the two-step
probe+branch with a single wait that races for either credentialsStep or
updateStep to become visible (e.g., Promise.race or awaiting both locators with
a shared longer timeout), then if updateStep wins, grab its Continue button
(updateStep.getByRole("button", { name: /Continue/i })) and click it, otherwise
proceed when credentialsStep is visible; update references to credentialsStep,
updateStep and continueBtn accordingly so the test no longer false-fails at the
8s boundary.
In `@e2e-install/80-chat.spec.ts`:
- Around line 133-137: The POST to `${BASE_URL}/setup-api/preferences` currently
ignores the response; update the code around that fetch call to verify the HTTP
response succeeded (check response.ok or status) and parse/inspect the response
body for a success flag, throwing or failing the test if the write failed;
specifically modify the fetch to capture the Response object returned from POST
to "/setup-api/preferences", assert response.ok (and/or expected JSON shape) and
include a clear error message if not successful so the test fails at this
operation instead of later with a misleading symptom.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ede21a75-3b17-41f5-89b3-26cf2b021f14
📒 Files selected for processing (3)
e2e-install/10-happy-path.spec.tse2e-install/10-setup-wizard.spec.tse2e-install/80-chat.spec.ts
💤 Files with no reviewable changes (1)
- e2e-install/10-happy-path.spec.ts
On CI the desktop renders the chat textbox with placeholder "Waiting for the Claw to wake up…" while the gateway WebSocket is still connecting. The textbox is disabled until connection completes. The local run happened to catch the textbox already enabled (prior test warmth), which masked this. Match either placeholder and add an explicit toBeEnabled wait so the test only fills after the gateway is ready. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
e2e-install/80-chat.spec.ts (1)
133-137:⚠️ Potential issue | 🟡 MinorAssert preference precondition write success immediately.
Line 133 posts critical UI preconditions but does not validate HTTP/application success. If this fails, the test will fail later with a misleading symptom.
Suggested fix
- await fetch(`${BASE_URL}/setup-api/preferences`, { + const prefRes = await fetch(`${BASE_URL}/setup-api/preferences`, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ ui_chat_open: 1, ui_mascot_hidden: 1 }), }); + expect(prefRes.ok).toBe(true); + const prefJson = await prefRes.json().catch(() => null); + expect(prefJson?.ok).toBe(true);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@e2e-install/80-chat.spec.ts` around lines 133 - 137, The POST to `${BASE_URL}/setup-api/preferences` does not check the response; capture the fetch response for the `${BASE_URL}/setup-api/preferences` call and assert success (e.g., response.ok / status === 200 and/or expected JSON success field) immediately after the request so the test fails with a clear error when the preference write fails; reference the existing fetch call using BASE_URL and the "/setup-api/preferences" endpoint to locate and update the code.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@e2e-install/80-chat.spec.ts`:
- Around line 133-137: The POST to `${BASE_URL}/setup-api/preferences` does not
check the response; capture the fetch response for the
`${BASE_URL}/setup-api/preferences` call and assert success (e.g., response.ok /
status === 200 and/or expected JSON success field) immediately after the request
so the test fails with a clear error when the preference write fails; reference
the existing fetch call using BASE_URL and the "/setup-api/preferences" endpoint
to locate and update the code.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: cb3a46c1-cd48-4e6d-8338-d91172869f5e
📒 Files selected for processing (1)
e2e-install/80-chat.spec.ts
Clawai proxy occasionally rejects the mapped model (deepseek-chat → deepseek-v4-flash) with "Model not allowed". When that happens the textbox stays disabled on "Waiting for the Claw to wake up…" forever. Skip the round-trip portion of the UI chat test with a clear reason message when the textbox never enables. The WebSocket handshake test above already verifies the transport itself. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
e2e-install/80-chat.spec.ts (1)
133-137:⚠️ Potential issue | 🟡 MinorAssert the preference POST succeeded.
This still drops the response, so a failed
/setup-api/preferenceswrite will only show up later as a misleading UI timeout.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@e2e-install/80-chat.spec.ts` around lines 133 - 137, The test currently POSTs preferences with await fetch(...) but ignores the response so failures surface later; capture and assert the response from the POST to /setup-api/preferences (e.g., assign the result of fetch to a variable), check response.ok and/or status (expect 200 or appropriate status), and if not ok, include the response body or statusText in the test failure to make the write error immediate; update the fetch usage in the test around the POST to verify success and surface error details.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@e2e-install/80-chat.spec.ts`:
- Around line 152-164: The current logic uses input.waitFor(...).then(() =>
input.isEnabled(...)) which only snapshots enabled state and can miss a
shortly-delayed enable; replace that flow by awaiting Playwright's retrying
assertion: use expect(input).toBeEnabled({ timeout: 60_000 }) to wait for the
textbox to become enabled and then only call test.skip if that assertion times
out; update the code around the becameEnabled variable and the existing
test.skip call so they rely on the expect-based wait (catch the assertion
failure and skip the test) instead of isEnabled().
---
Duplicate comments:
In `@e2e-install/80-chat.spec.ts`:
- Around line 133-137: The test currently POSTs preferences with await
fetch(...) but ignores the response so failures surface later; capture and
assert the response from the POST to /setup-api/preferences (e.g., assign the
result of fetch to a variable), check response.ok and/or status (expect 200 or
appropriate status), and if not ok, include the response body or statusText in
the test failure to make the write error immediate; update the fetch usage in
the test around the POST to verify success and surface error details.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0bee6e96-1d2e-447d-ab79-0c2ec2a77059
📒 Files selected for processing (1)
e2e-install/80-chat.spec.ts
This was referenced Aug 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
10-happy-path.spec.ts(API-driven) with10-setup-wizard.spec.ts— drives the real SetupWizard through every step in a live browser sessionTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit