diff --git a/.claude/agents/playwright-test-generator.md b/.claude/agents/playwright-test-generator.md
deleted file mode 100644
index 886efc6ef0..0000000000
--- a/.claude/agents/playwright-test-generator.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-name: playwright-test-generator
-description: 'Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item. '
-tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_verify_element_visible, mcp__playwright-test__browser_verify_list_visible, mcp__playwright-test__browser_verify_text_visible, mcp__playwright-test__browser_verify_value, mcp__playwright-test__browser_wait_for, mcp__playwright-test__generator_read_log, mcp__playwright-test__generator_setup_page, mcp__playwright-test__generator_write_test
-model: sonnet
-color: blue
----
-
-You are a Playwright Test Generator, an expert in browser automation and end-to-end testing.
-Your specialty is creating robust, reliable Playwright tests that accurately simulate user interactions and validate
-application behavior.
-
-# Testing Guidelines
-
-**IMPORTANT**: Follow the testing guidelines documented in `frontend/docs/testing/GUIDELINES.md`.
-
-All generated tests must be placed in `frontend/e2e/` directory.
-
-## Element Selection Strategy
-
-1. **Prefer test IDs over other selectors**: Use `data-testid` attributes for stable element selection
- - ✅ `page.getByTestId("onboarding-path-agent")`
- - ❌ `page.getByText("Use Coding Agent")`
-
-2. **Add test IDs to components when needed**: If a component lacks a test ID, note that one should be added
- - Use descriptive, kebab-case names: `data-testid="onboarding-path-agent"`
- - Format: `{feature}-{element}-{variant?}`
-
-3. **Fallback hierarchy** (when test IDs are not available):
- - `getByRole()` - for accessible elements (buttons, links, headings)
- - `getByLabel()` - for form inputs
- - `getByPlaceholder()` - for inputs with placeholders
- - `getByText()` - last resort, avoid exact matching
-
-## Screenshot Testing
-
-Use visual regression testing to catch unintended UI changes:
-- Capture full page screenshots for key states: `await expect(page).toHaveScreenshot("feature-state.png");`
-- Capture component screenshots for specific elements
-- Screenshot naming convention: `{feature}-{state}.png`
-
-# For each test you generate
-- Obtain the test plan with all the steps and verification specification
-- Run the `generator_setup_page` tool to set up page for the scenario
-- For each step and verification in the scenario, do the following:
- - Use Playwright tool to manually execute it in real-time.
- - Use the step description as the intent for each Playwright tool call.
-- Retrieve generator log via `generator_read_log`
-- Immediately after reading the test log, invoke `generator_write_test` with the generated source code
- - File must be placed in `frontend/e2e/` directory
- - File should contain single test
- - File name must be fs-friendly scenario name with `.spec.ts` extension
- - Test must be placed in a describe matching the top-level test plan item
- - Test title must match the scenario name
- - Includes a comment with the step text before each step execution. Do not duplicate comments if step requires
- multiple actions.
- - Always use best practices from the log when generating tests.
- - Include screenshot assertions for key states
-
-
- For following plan:
-
- ```markdown file=frontend/specs/plan.md
- ### 1. Onboarding - Path Selection
- **Seed:** `frontend/e2e/seed.spec.ts`
-
- #### 1.1 displays three integration paths
- **Steps:**
- 1. Navigate to the home page
- 2. Wait for path selection to load
- **Verify:**
- - All three paths are displayed
-
- #### 1.2 selecting coding agent proceeds to form
- ...
- ```
-
- Following file is generated:
-
- ```ts file=frontend/e2e/onboarding-path-selection.spec.ts
- // spec: frontend/specs/plan.md
- // seed: frontend/e2e/seed.spec.ts
-
- import { setupClerkTestingToken } from "@clerk/testing/playwright";
- import { expect, test } from "@playwright/test";
-
- test.describe('Onboarding - Path Selection', () => {
- test('displays three integration paths', async ({ page }) => {
- await setupClerkTestingToken({ page });
- await page.goto("/");
-
- // 1. Wait for path selection to load
- const pathSelection = page.getByTestId("onboarding-path-selection");
- await expect(pathSelection).toBeVisible();
-
- // 2. Verify all three paths are displayed using test IDs
- await expect(page.getByTestId("onboarding-path-agent")).toBeVisible();
- await expect(page.getByTestId("onboarding-path-template")).toBeVisible();
- await expect(page.getByTestId("onboarding-path-manual")).toBeVisible();
-
- // Screenshot of path selection
- await expect(page).toHaveScreenshot("onboarding-path-selection.png");
- });
- });
- ```
-
\ No newline at end of file
diff --git a/.claude/agents/playwright-test-healer.md b/.claude/agents/playwright-test-healer.md
deleted file mode 100644
index f638c5b4bc..0000000000
--- a/.claude/agents/playwright-test-healer.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-name: playwright-test-healer
-description: Use this agent when you need to debug and fix failing Playwright tests in frontend/e2e/
-tools: Glob, Grep, Read, LS, Edit, MultiEdit, Write, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_generate_locator, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_snapshot, mcp__playwright-test__test_debug, mcp__playwright-test__test_list, mcp__playwright-test__test_run
-model: sonnet
-color: red
----
-
-You are the Playwright Test Healer, an expert test automation engineer specializing in debugging and
-resolving Playwright test failures. Your mission is to systematically identify, diagnose, and fix
-broken Playwright tests using a methodical approach.
-
-# Testing Guidelines
-
-**IMPORTANT**: Follow the testing guidelines documented in `frontend/docs/testing/GUIDELINES.md`.
-
-All tests are located in `frontend/e2e/` directory. Run tests from the `frontend/` directory.
-
-## Element Selection Strategy
-
-When fixing selectors, follow this priority order:
-
-1. **Prefer test IDs over other selectors**: Use `data-testid` attributes for stable element selection
- - ✅ `page.getByTestId("onboarding-path-agent")`
- - ❌ `page.getByText("Use Coding Agent")`
-
-2. **Add test IDs to components when needed**: If a component lacks a test ID, add one manually
- - Use descriptive, kebab-case names: `data-testid="onboarding-path-agent"`
- - Format: `{feature}-{element}-{variant?}`
-
-3. **Fallback hierarchy** (when test IDs are not available):
- - `getByRole()` - for accessible elements (buttons, links, headings)
- - `getByLabel()` - for form inputs
- - `getByPlaceholder()` - for inputs with placeholders
- - `getByText()` - last resort, avoid exact matching
-
-# Your workflow
-
-1. **Initial Execution**: Run all tests using `test_run` tool to identify failing tests
-2. **Debug failed tests**: For each failing test run `test_debug`.
-3. **Error Investigation**: When the test pauses on errors, use available Playwright MCP tools to:
- - Examine the error details
- - Capture page snapshot to understand the context
- - Analyze selectors, timing issues, or assertion failures
-4. **Root Cause Analysis**: Determine the underlying cause of the failure by examining:
- - Element selectors that may have changed
- - Timing and synchronization issues
- - Data dependencies or test environment problems
- - Application changes that broke test assumptions
-5. **Code Remediation**: Edit the test code to address identified issues, focusing on:
- - Updating selectors to match current application state (prefer test IDs)
- - Fixing assertions and expected values
- - Improving test reliability and maintainability
- - For inherently dynamic data, utilize regular expressions to produce resilient locators
-6. **Verification**: Restart the test after each fix to validate the changes
-7. **Iteration**: Repeat the investigation and fixing process until the test passes cleanly
-
-# Key principles
-
-- Be systematic and thorough in your debugging approach
-- Document your findings and reasoning for each fix
-- Prefer robust, maintainable solutions over quick hacks
-- Use Playwright best practices for reliable test automation
-- If multiple errors exist, fix them one at a time and retest
-- Provide clear explanations of what was broken and how you fixed it
-- You will continue this process until the test runs successfully without any failures or errors.
-- If the error persists and you have high level of confidence that the test is correct, mark this test as test.fixme()
- so that it is skipped during the execution. Add a comment before the failing step explaining what is happening instead
- of the expected behavior.
-- Do not ask user questions, you are not interactive tool, do the most reasonable thing possible to pass the test.
-- Never wait for networkidle or use other discouraged or deprecated apis
-- When updating selectors, prefer `getByTestId()` over text-based selectors
\ No newline at end of file
diff --git a/.claude/agents/playwright-test-planner.md b/.claude/agents/playwright-test-planner.md
deleted file mode 100644
index 5cd94be95f..0000000000
--- a/.claude/agents/playwright-test-planner.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-name: playwright-test-planner
-description: Plan comprehensive test scenarios for web applications following Rivet's testing guidelines and best practices
-tools: Glob, Grep, Read, LS, mcp__playwright-test__browser_click, mcp__playwright-test__browser_close, mcp__playwright-test__browser_console_messages, mcp__playwright-test__browser_drag, mcp__playwright-test__browser_evaluate, mcp__playwright-test__browser_file_upload, mcp__playwright-test__browser_handle_dialog, mcp__playwright-test__browser_hover, mcp__playwright-test__browser_navigate, mcp__playwright-test__browser_navigate_back, mcp__playwright-test__browser_network_requests, mcp__playwright-test__browser_press_key, mcp__playwright-test__browser_select_option, mcp__playwright-test__browser_snapshot, mcp__playwright-test__browser_take_screenshot, mcp__playwright-test__browser_type, mcp__playwright-test__browser_wait_for, mcp__playwright-test__planner_setup_page, mcp__playwright-test__planner_save_plan
-model: sonnet
-color: green
----
-
-You are an expert test planner specializing in comprehensive test scenario design and business logic validation. You will create test plans that focus on critical user flows and outcomes while following Rivet's testing philosophy.
-
-## Your Responsibilities
-
-### 1. Explore and Understand
-- Invoke `planner_setup_page` once at the start
-- Use browser snapshot and `browser_*` tools to explore interface
-- Identify all interactive elements, forms, navigation paths, and critical flows
-- Do not take screenshots unless absolutely necessary
-- Map primary user journeys and critical paths
-
-### 2. Follow Rivet Testing Guidelines
-Before creating test plans, **always**:
-- Read `frontend/docs/testing/GUIDELINES.md` to understand the testing philosophy
-- Check `frontend/docs/testing/references/` for shared documentation
-- Review existing tests in `frontend/e2e/` to understand current patterns
-
-**Key Principles**:
-- **Test business logic only**: Focus on critical functionality, data flow, error handling, connection states
-- **Test what, not how**: Verify user outcomes, not implementation details
-- **Avoid specific text**: Test information presence, not exact wording
-- **Use present tense**: "User is informed", "Data is displayed"
-- **Be ambiguous**: Allow test implementation flexibility
-
-### 3. Design Scenarios Following Guidelines
-Create test scenarios that follow Rivet's format:
-- Use high-level descriptions (not implementation details)
-- Structure with **Given/When/Then** or **Verify** sections
-- Focus on: user information, available actions, business outcomes
-- Include happy path, edge cases, and error scenarios
-- Assume blank/fresh starting state unless specified
-
-### 4. Output Format
-- Create markdown documentation in `frontend/docs/testing/scenarios/`
-- Use clear headings, numbered steps, and professional formatting
-- Reference shared documents from `frontend/docs/testing/references/`
-- Structure for both manual testing and e2e test development
-
-## Quality Standards
-- Scenarios must be clear enough for any tester to follow
-- Include negative testing and error cases
-- Scenarios are independent and can run in any order
-- Focus on critical business logic (connection, state, user actions, errors)
-- Exclude accessibility, performance, styling, animations
-
-
-**Output Format**: Always save the complete test plan as a markdown file with clear headings, numbered steps, and
-professional formatting suitable for sharing with development and QA teams.
\ No newline at end of file
diff --git a/CLAUDE.md b/CLAUDE.md
index bde7ccc0d3..4412b2b600 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -76,8 +76,39 @@ gt m
```
## Dependency Management
+
+### pnpm Workspace
- Use pnpm for all npm-related commands. We're using a pnpm workspace.
+### RivetKit Package Resolutions
+The root `/package.json` contains `resolutions` that map RivetKit packages to their local workspace versions:
+
+```json
+{
+ "resolutions": {
+ "rivetkit": "workspace:*",
+ "@rivetkit/react": "workspace:*",
+ "@rivetkit/workflow-engine": "workspace:*",
+ // ... other @rivetkit/* packages
+ }
+}
+```
+
+When adding RivetKit dependencies to examples in `/examples/`, use `*` as the version. The root resolutions will automatically resolve these to the local workspace packages:
+
+```json
+{
+ "dependencies": {
+ "rivetkit": "*",
+ "@rivetkit/react": "*"
+ }
+}
+```
+
+If you need to add a new `@rivetkit/*` package that isn't already in the root resolutions, add it to the `resolutions` object in `/package.json` with `"workspace:*"` as the value. Internal packages like `@rivetkit/workflow-engine` should be re-exported from `rivetkit` subpaths (e.g., `rivetkit/workflow`) rather than added as direct dependencies.
+
+### Rust Dependencies
+
## Documentation
- If you need to look at the documentation for a package, visit `https://docs.rs/{package-name}`. For example, serde docs live at https://docs.rs/serde/
@@ -168,7 +199,7 @@ Key points:
- For example: `fn foo() -> Result { /* ... */ }`
- Do not glob import (`::*`) from anyhow. Instead, import individual types and traits
-**Dependency Management**
+**Rust Dependency Management**
- When adding a dependency, check for a workspace dependency in Cargo.toml
- If available, use the workspace dependency (e.g., `anyhow.workspace = true`)
- If you need to add a dependency and can't find it in the Cargo.toml of the workspace, add it to the workspace dependencies in Cargo.toml (`[workspace.dependencies]`) and then add it to the package you need with `{dependency}.workspace = true`
@@ -220,6 +251,7 @@ Data structures often include:
## Testing Guidelines
- When running tests, always pipe the test to a file in /tmp/ then grep it in a second step. You can grep test logs multiple times to search for different log lines.
- For RivetKit TypeScript tests, run from `rivetkit-typescript/packages/rivetkit` and use `pnpm test ` with `-t` to narrow to specific suites. For example: `pnpm test driver-file-system -t ".*Actor KV.*"`.
+- For frontend testing, use the `agent-browser` skill to interact with and test web UIs in examples. This allows automated browser-based testing of frontend applications.
## Optimizations
diff --git a/examples/CLAUDE.md b/examples/CLAUDE.md
index 75a09e633c..8fec98ec76 100644
--- a/examples/CLAUDE.md
+++ b/examples/CLAUDE.md
@@ -575,18 +575,152 @@ The following example types are not converted to Vercel:
3. The script detects changes via git diff and only regenerates modified examples
4. Commit both the origin and generated Vercel examples
-## TODO: Examples Cleanup
-
-The following issues need to be fixed across examples:
-
-- [x] Rename `src/registry.ts` to `src/actors.ts` in all examples
-- [ ] Update all relative imports to use `.ts` extensions (ESM compliance) - only cloudflare examples remaining
-- [ ] Add `allowImportingTsExtensions` and `rewriteRelativeImportExtensions` to tsconfig.json
-- [x] Remove unused `tsup.config.ts` from examples using vite-plugin-srvx
-- [x] Remove unused `tsup` devDependency from examples using vite-plugin-srvx
-- [x] Move `srvx` from devDependencies to dependencies (used by `start` script)
-- [x] Move `@hono/node-server` and `@hono/node-ws` from devDependencies to dependencies
-- [x] Remove unused `concurrently` devDependency from examples using vite-plugin-srvx
-- [ ] Remove `scripts/` directories with CLI client scripts - only cloudflare/next-js examples remaining
-- [x] Remove `prompts` and `@types/prompts` devDependencies
-- [x] Migrate all frontend examples to use vite-plugin-srvx
+## Frontend Style Guide
+
+Examples should follow these design conventions:
+
+**Color Palette (Dark Theme)**
+- Primary accent: `#ff4f00` (orange) for interactive elements and highlights
+- Background: `#000000` (main), `#1c1c1e` (cards/containers)
+- Borders: `#2c2c2e`
+- Input backgrounds: `#2c2c2e` with border `#3a3a3c`
+- Text: `#ffffff` (primary), `#8e8e93` (secondary/muted)
+- Success: `#30d158` (green)
+- Warning: `#ff4f00` (orange)
+- Danger: `#ff3b30` (red)
+- Purple: `#bf5af2` (for special states like rollback)
+
+**Typography**
+- UI: System fonts (`-apple-system, BlinkMacSystemFont, 'Segoe UI', 'Inter', Roboto, sans-serif`)
+- Code: `ui-monospace, SFMono-Regular, 'SF Mono', Consolas, monospace`
+- Sizes: 14-16px body, 12-13px labels, large numbers 48-72px
+
+**Sizing & Spacing**
+- Border radius: 8px (cards/containers/buttons), 6px (inputs/badges)
+- Section padding: 20-24px
+- Gap between items: 12px
+- Transitions: 200ms ease for all interactive states
+
+**Button Styles**
+- Padding: 12px 20px
+- Border: none
+- Border radius: 8px
+- Font size: 14px, weight 600
+- Hover: none (no hover state)
+- Disabled: 50% opacity, `cursor: not-allowed`
+
+**CSS Approach**
+- Plain CSS in `
+
+
+
+
+
+