fix(skills): correct cloud-browser stop body and cdpUrl resolution

[Alezander9]

Two bugs surfaced by an agent testing Way 3 end-to-end

Both verified against the canonical v3 spec at https://docs.browser-use.com/cloud/openapi/v3.json (UpdateBrowserSessionRequest, BrowserSessionItemView).

1. Stop body — {state: "stop"} → {action: "stop"}

The v3 PATCH /browsers/{id} schema requires:

{ "action": "stop" }

Field name was wrong (state vs. action); enum value happened to match. Fixed in three places: cloud-browser.md Stop section, Swap section, and the workspace stop() helper.

2. cdpUrl resolution — pass through → /json/version

BU's cdpUrl is the HTTP discovery endpoint (e.g. https://cdpN.browser-use.com), not a WebSocket URL. Same shape as Chrome's :9222. The v0.1.0 Way 2 polish (PR #44) landed exactly this fix for raw Chrome; cloud-browser docs missed the same step.

Fix: fetch(${cdpUrl}/json/version) → use webSocketDebuggerUrl. Applied at three call sites: BROWSER.md inline Way 3 example, cloud-browser.md Connect section, and the workspace provision() helper (now does the resolution once internally and returns wsUrl directly so callers can session.connect({ wsUrl })).

Cleanups while here

• Drop the snake_OR_camelCase double-accept (body.cdp_url ?? body.cdpUrl). The v3 OpenAPI spec is unambiguously camelCase — old comment claiming "some regions return snake_case" wasn't backed by spec or any test. Use straight destructuring: const { id, cdpUrl, liveUrl } = await r.json().
• Inline comments in cloud-browser.md provision body: profile_id/proxy_country_code → profileId/proxyCountryCode to match the v3 request schema.

Scope

Docs only — no source code changes. Two .md files:

• packages/bcode-browser/skills/BROWSER.md — Way 3 inline example.
• packages/bcode-browser/skills/cloud-browser.md — Provision, Connect, Stop, Swap, workspace helper, helper usage example.

+26 / −26 lines.

Verified

• bun typecheck clean.
• bun test from packages/bcode-browser/: 8 pass + 5 chrome-gated skip — skills materialization regression tests still cover that on-disk skill files contain no literal {{SKILLS_DIR}} and the substituted target paths land intact.

Why no test for the API call shape

Mocking BU's HTTP responses to assert {action:"stop"} lands in the body would test the test, not the agent. The actual contract is between the agent's snippet and BU's API server — both are now lined up against the published OpenAPI schema. Agent retest will catch any remaining drift faster than a unit-mock would.

Stacks

Independent of #45 (BU_CDP_WS env var). Both can land in either order.

[cubic-dev-ai]

No issues found across 2 files