stably 4.12.1 → 4.12.2

package/dist/playwright-cli.js

@@ -282,9 +282,15 @@ module.exports = defineConfig({
 `;
   fs.writeFileSync(wrapperConfigPath, wrapperConfig);
   const testArgs = argv.slice(cmdIndex + 1).filter((a) => !a.startsWith("--config=") && !a.startsWith("--session=") && !a.startsWith("-s=") && a !== "--headed");
+  // Resolve @playwright/test CLI binary to avoid version mismatch with playwright package
+  var _runBin = "npx", _runArgs = ["playwright", "test"];
+  try { var _ptPkg = require.resolve("@playwright/test/package.json", { paths: [cwd] });
+    var _ptCli = path.join(path.dirname(_ptPkg), "cli.js");
+    if (fs.existsSync(_ptCli)) { _runBin = process.execPath; _runArgs = [_ptCli, "test"]; }
+  } catch (_) {}
   let exitCode = 0;
   try {
-    execFileSync("npx", ["playwright", "test", "--config=" + wrapperConfigPath, ...testArgs], {
+    execFileSync(_runBin, [..._runArgs, "--config=" + wrapperConfigPath, ...testArgs], {
       stdio: "inherit",
       env: {
         ...process.env,

package/dist/stably-plugin-cli/skills/ai-to-programmatic-migration/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: ai-to-programmatic-migration
+description: Guide for refactoring tests that over-rely on AI methods (agent.act, aiAssert) into deterministic Playwright steps. Use when tests are flaky due to inconsistent AI behavior, slow due to AI inference overhead, or hard to debug because AI actions are unpredictable. Triggers on flaky AI test, slow agent.act, reduce AI usage, make test deterministic, migrate AI to playwright, improve test reliability, agent.act doing wrong thing.
+---
+
+# Migrate AI-Heavy Tests to Programmatic Playwright Steps
+
+Refactor tests that rely on large, monolithic AI method calls into smaller, deterministic Playwright steps. AI methods are kept only where they add genuine value.
+
+## When This Applies
+
+A test is a migration candidate when it:
+- Uses `agent.act()` to drive multi-step flows that could be expressed as simple clicks/fills/navigations
+- Is flaky because the AI interprets instructions inconsistently across runs
+- Is slow because AI inference adds overhead to every action
+- Fails in ways that are hard to diagnose (the AI did something unexpected mid-flow)
+
+## Approval Before Migrating
+
+This is a significant refactoring decision — you are making an opinionated judgment that AI is overused, and the user may disagree.
+
+**Check your system prompt for the current mode:**
+
+- **If "one-shot mode" appears in your system prompt:** Log your rationale (which AI methods you're replacing and why), then proceed automatically. Do not block on user input.
+- **Otherwise (chat mode):** Present your recommendation with evidence and get user approval before making changes.
+
+### Recommendation Template (chat mode)
+
+```
+I noticed that `agent.act('click the Submit button and wait for the dashboard')` in line 42
+fails inconsistently — sometimes it clicks the wrong button, sometimes it doesn't wait long enough.
+
+I'd recommend replacing it with deterministic Playwright steps:
+  await page.getByRole('button', { name: 'Submit' }).click();
+  await page.waitForURL('**/dashboard');
+
+This would make the test faster and more reliable. The AI call isn't adding value here since
+the selector is stable.
+
+Should I make this change? Or do you prefer keeping the AI method?
+```
+
+In either mode, do NOT silently refactor AI methods — always document what you changed and why.
+
+## Migration Workflow
+
+### 1. Understand the existing test's intent
+
+Read the test file. Extract the logical steps from the `agent.act()` prompts:
+- What pages does it visit?
+- What actions does it perform?
+- What does it verify?
+
+### 2. Explore the app manually using the browser
+
+Open a browser, walk through the flow step-by-step, snapshot at each stage, and record the exact selectors, link names, page titles, and UI patterns you encounter. This grounds your rewrite in reality rather than the AI prompt's assumptions.
+
+See the "Manual Exploration Workflow" section in the `debugging-test-failures` skill.
+
+### 3. Replace AI methods with Playwright equivalents
+
+| AI method usage | Replace with |
+|----------------|-------------|
+| `agent.act("click the Submit button")` | `page.getByRole('button', { name: 'Submit' }).click()` |
+| `agent.act("fill in the email field")` | `page.getByRole('textbox', { name: 'Email' }).fill('...')` |
+| `agent.act("navigate to Settings page")` | Click the nav element or `page.goto('/settings')` |
+| `agent.act("select Option B from dropdown")` | Open dropdown + click option programmatically |
+| `agent.act("verify the table has data")` | `await expect(page.locator('table tbody tr')).not.toHaveCount(0)` |
+
+### 4. Keep AI methods only where they earn their cost
+
+Preserve `aiAssert` or `agent.act()` when:
+- The check is inherently visual/subjective (e.g., "the dashboard looks loaded and has content")
+- The UI is highly dynamic and selectors are unstable (canvas, drag-drop, complex widgets)
+- Deterministic assertions would be brittle or impossible to write
+
+When using `aiAssert`, write tolerant prompts — verify the intent, not pixel-perfect details.
+
+### 5. Structure the rewritten test
+
+- **One `test.step()` per logical action** — not one giant step for the whole flow
+- **Extract repeated patterns into helper functions** — if multiple tests follow the same pattern, write one helper
+- **Set explicit timeouts** where flows are slow (use `test.setTimeout()` inside the test body)
+- **Handle conditional states** (e.g., login may or may not appear) with detection logic rather than hoping the AI handles it
+
+### 6. Verify the rewrite
+
+Run the migrated test end-to-end. If it fails, use the browser exploration workflow to diagnose. Run at least **twice** to confirm stability. Compare execution time against the original — migrated tests should be faster since they skip AI inference for routine actions.
+
+## Key Principles
+
+- **AI is expensive; use it deliberately.** Every `agent.act()` call adds latency and non-determinism. If a click is just a click, write it as a click.
+- **Explore before you write.** Never rewrite a test based solely on what the old AI prompt says the UI looks like. Open the browser and see the actual page.
+- **Migrate incrementally.** Replace one `agent.act()` block at a time, verify it works, then move to the next. Don't rewrite the entire test blind.
+- **The goal is reliability, not zero AI.** A test with 20 programmatic steps and 1 `aiAssert` at the end is better than either extreme.

package/dist/stably-plugin-cli/skills/browser-interaction-guide/SKILL.md

@@ -24,6 +24,34 @@ playwright-cli goto https://example.com
 
 `playwright-cli run-test` auto-starts a browser if needed and preserves the session after tests finish. You can immediately use `playwright-cli snapshot`, `playwright-cli click`, etc. to inspect page state. No need to run `playwright-cli open` before or after `run-test`.
 
+### Reset Browser Between Independent Test Verifications
+
+**CRITICAL:** When verifying that multiple independent tests pass, you **MUST** run `playwright-cli close` between each `run-test` call. Browser state (cookies, localStorage, auth sessions) persists across runs, so a stale or logged-in state from one test will contaminate the next — causing cascading login failures or unexpected behavior.
+
+**IMPORTANT: `playwright-cli close` must be its own separate Bash call.** Do NOT chain it with other commands (e.g., `playwright-cli close; playwright-cli run-test ...`). The browser is only fully terminated after the Bash command finishes, so chaining means the next command runs on the old browser with stale state.
+
+This does NOT apply when intentionally using `run-test` as a setup/seed mechanism to build state for subsequent interaction.
+
+```bash
+# CORRECT: Each command is a separate Bash call
+playwright-cli run-test tests/test-a.spec.ts
+playwright-cli close
+playwright-cli run-test tests/test-b.spec.ts
+playwright-cli close
+```
+
+```bash
+# WRONG: Chaining close with run-test in one command
+playwright-cli close; playwright-cli run-test tests/test-b.spec.ts  # ← run-test hits old browser
+playwright-cli close && playwright-cli run-test tests/test-b.spec.ts  # ← same problem
+```
+
+```bash
+# WRONG: Running independent tests without resetting
+playwright-cli run-test tests/test-a.spec.ts
+playwright-cli run-test tests/test-b.spec.ts   # ← may fail: stale state from test-a
+```
+
 ### Tool Decision Tree
 
 ```
@@ -50,7 +78,7 @@ For project selection (auth dependencies), see `playwright-config-auth` skill.
 
 | Error Type | Action |
 |------------|--------|
-| **Test code error** (assertion failed, locator not found) | Fix code, re-run with `playwright-cli run-test` |
+| **Test code error** (assertion failed, locator not found) | Test the locator interactively with `playwright-cli run-code` first (seconds vs minutes), then fix code and re-run with `playwright-cli run-test` |
 | **External service error** (timeout, network) | Retry up to 3 times |
 | **Same error 3+ times** | Flag as blocked service issue, do not keep retrying |
 
@@ -111,6 +139,36 @@ page.locator('table tbody tr').first().locator('button')
 - Empty text filters with indexes: `.filter({ hasText: /^$/ }).nth(5)`
 - Absolute indexes without context
 - CSS selectors based on implementation details
+- **Parent traversal with `.locator('..')`**: Don't chain `.locator('..')` from buttons or interactive elements to find siblings. The accessibility tree and DOM tree don't always align, so going "up" from a button may not reach the container you expect. Instead, start from a nearby label/text and traverse from there, or use a broader structural locator.
+
+### Snapshot Names vs textContent()
+
+Accessible names shown in snapshots are cleaned and trimmed. `textContent()` in test code returns raw text, which may include icon font ligatures (e.g., Material Icons: `keyboard_arrow_right`, `filter_alt`, `chevron_left`) and extra whitespace.
+
+```typescript
+// BAD — exact match fails because textContent includes icon text
+expect(await cell.textContent()).toBe('Settings');
+
+// GOOD — use contains/regex to handle icon ligatures and whitespace
+expect(await cell.textContent()).toContain('Settings');
+// or
+await expect(cell).toHaveText(/Settings/);
+```
+
+### Tri-State Checkboxes (Indeterminate)
+
+Checkboxes can have three states: checked, unchecked, and indeterminate (`checked="mixed"`). `isChecked()` returns `false` for indeterminate state, so don't use it to determine initial state.
+
+```typescript
+// BAD — isChecked() returns false for indeterminate, so this skips the click
+if (!await checkbox.isChecked()) await checkbox.click();
+
+// GOOD — click first, then verify the resulting state
+await checkbox.click();
+if (await checkbox.isChecked()) {
+  // Now fully checked — if you wanted unchecked, click again
+}
+```
 
 ### Use `.describe()` Method
 
@@ -155,6 +213,14 @@ playwright-cli goto 'https://${process.env.BASE_URL}/dashboard'
 playwright-cli fill e3 "${process.env.ACCOUNT_PASSWORD}"
 ```
 
+## Browser Interaction Strategy (Priority Order)
+
+1. **Standard Playwright methods** (`locator.click()`, `locator.fill()`) - First choice, fast and reliable
+2. **`agent.act()`** for complex/dynamic UI - Use for sliders, carousels, drag-drop, dynamic menus. Slower but more robust.
+3. **Custom JS `page.evaluate()`** - Last resort only when agent.act() is inconsistent
+
+Don't prematurely optimize with custom JS. Slower but reliable `agent.act()` is better than fast but brittle custom JS.
+
 ## Page State Snapshots
 
 Every `playwright-cli` command that changes page state (`open`, `goto`, `click`, `fill`, `run-test`, etc.) returns a snapshot file path in its output. **Read that snapshot file directly — do not call `playwright-cli snapshot` again.** Refs (e1, e2, etc.) are only valid from the most recent snapshot. After any command that returns a new snapshot, previous refs are stale.

package/dist/stably-plugin-cli/skills/bulk-test-handling/SKILL.md

@@ -71,6 +71,10 @@ Keep the user informed:
 - "Completed 6/18 tests. Moving to batch 2..."
 - "Batch 2 complete. 2 tests needed manual review..."
 
+### Between Tests (Browser Reset)
+
+**CRITICAL:** When verifying independent tests, run `playwright-cli close` after each `run-test` call before starting the next test. Browser state (cookies, auth, localStorage) persists between runs, causing cascading failures if not reset. **`playwright-cli close` must be its own separate Bash call** — do NOT chain it with other commands (e.g., `close; run-test`). The browser is only fully terminated after the Bash command finishes.
+
 ### Between Batches - Check Your System Prompt
 
 Your system prompt tells you which mode you're in:

package/dist/stably-plugin-cli/skills/debugging-test-failures/SKILL.md

@@ -57,6 +57,8 @@ Five types of issues cause test failures:
 
 **In `single`, `build`, `chat` modes**: Run `playwright-cli run-test` directly (no debug subagent available). Browser persists after test runs for inspection via `playwright-cli snapshot`.
 
+**IMPORTANT:** When verifying multiple independent tests, run `playwright-cli close` between each `run-test` call. Stale browser state (cookies, auth sessions, localStorage) from one test will contaminate the next, causing cascading failures — especially at login. **`playwright-cli close` must be its own separate Bash call** — do NOT chain it with other commands (e.g., `close; run-test`). The browser is only fully terminated after the Bash command finishes.
+
 ### When to Use Subagents
 
 - Verifying a test works after making changes
@@ -72,13 +74,74 @@ Five types of issues cause test failures:
 
 ## Debugging Workflow
 
-1. **Find failed tests**: Use Read/Glob to identify failing test files
-2. **Reproduce + diagnose**:
-   - Fix mode: Delegate to `debug-worker`
-   - Single/build/chat modes: Run `playwright-cli run-test` directly
-3. **Implement fix**: Make necessary code changes
-4. **Verify fix**: Use `playwright-cli run-test` for final verification
-5. **Group related failures**: Only group tests that share the same root cause
+1. **Run the test** and read the error output from `playwright-cli run-test`
+2. **Read `error-context.md`**: On failure, check `test-results/<test-name>/error-context.md`. This is the page accessibility snapshot at the moment of failure — it shows every visible element, their roles, names, and states. This tells you what the page *actually looked like* when things went wrong.
+3. **Classify the failure by symptom:**
+
+   | Symptom | Likely Cause | Typical Fix |
+   |---------|-------------|-------------|
+   | **Element not found** | Wrong selector, UI changed, element never rendered | Check error-context for actual element text/role, update selector |
+   | **Timeout waiting for element** | Page didn't reach expected state — auth redirect, skipped step, wrong page | Check error-context to see what page you're actually on |
+   | **Assertion failed** | Page loaded but content doesn't match expectations | Compare error-context to assertion, update expected value or fix app bug |
+   | **Test timeout exceeded** | Flow takes longer than allowed | Increase via `test.setTimeout()` inside test body |
+
+4. **Fix or explore**:
+   - If error-context clearly explains the issue (wrong text, element missing, on wrong page) → fix the code directly
+   - If error-context is insufficient → open the browser and explore manually (see below)
+5. **Verify**: Run the test again. Run at least **twice** to confirm the fix is stable.
+6. **One fix at a time**: Fix the first failure point, re-run. Do not speculatively rewrite multiple parts at once.
+7. **Group related failures**: Only group tests that share the same root cause
+
+## When to Open the Browser for Manual Exploration
+
+**Open the browser** (`playwright-cli open` or use the persisted session after `run-test`) when:
+- The error-context doesn't explain the failure — you can see the page state but not *why* the selector doesn't match
+- You need to discover interactive behavior (dropdowns, modals, hover states, animations) that a static snapshot can't capture
+- You're writing or rewriting a test for a flow you haven't seen before
+- The same test keeps failing after 2+ code fixes based on error-context alone
+- **AI methods behave unexpectedly** — when `agent.act()`, `page.extract()`, or `toMatchScreenshotPrompt()` do the wrong thing, you need to see the actual page to understand what the AI was "seeing" and adjust the prompt. You can't debug AI prompts from a text snapshot alone.
+
+**Don't open the browser** when:
+- The error-context clearly shows the issue — wrong selector text, element not present, on wrong page. Just fix the code directly.
+- It's a simple timeout that just needs a higher value
+- It's a known flaky pattern you already know the fix for
+
+### Manual Exploration Workflow
+
+1. Open the browser at the test's starting URL (or use the persisted session after a failed `run-test`)
+2. Walk through the flow step by step — snapshot, click, fill, navigate using refs
+3. At each step, compare what you see vs. what the test expects
+4. Record the correct selectors, text content, and page structure as you go
+5. Find the divergence point — where reality differs from the test's assumptions
+6. Fix the test to match what you observed
+
+### Use `run-code` to Debug Locators Interactively
+
+**If a locator fails on the first `run-test`, don't immediately retry `run-test`.** Open the browser and test the locator interactively with `playwright-cli run-code` — it gives results in seconds instead of waiting for a full test run (~2 minutes).
+
+```bash
+# Test a locator and see what it actually returns
+playwright-cli run-code "async page => {
+  const el = page.getByRole('button', { name: 'Submit' });
+  return { count: await el.count(), text: await el.first().textContent() };
+}"
+
+# Explore DOM structure around an element
+playwright-cli run-code "async page => {
+  let el = page.getByText('Filters', { exact: true });
+  for (let i = 1; i <= 5; i++) {
+    el = el.locator('..');
+    const buttons = await el.locator('button').count();
+    console.log('up' + i + ': ' + buttons + ' buttons');
+  }
+}"
+```
+
+This is especially useful for:
+- Discovering that `textContent()` includes icon font ligatures not shown in snapshots
+- Testing how many parent levels up you need to traverse to find a sibling element
+- Checking checkbox states (`isChecked()` returns `false` for indeterminate/mixed)
+- Verifying that a locator matches exactly one element, not zero or many
 
 ## Parallel Diagnosis
 
@@ -128,7 +191,9 @@ A failing test that catches a real bug is more valuable than a passing test that
 
 ## Best Practices
 
-- Reproduce first: Always try to reproduce failures before diagnosing
+- **Read error-context first**: Always check `test-results/<test-name>/error-context.md` before touching code. The page snapshot tells you what went wrong faster than reading stack traces.
+- **One fix at a time**: Fix the first point of failure, re-run. Don't rewrite the whole test speculatively.
+- **Verify twice**: Run the test at least twice after fixing to confirm stability.
 - Be specific: Identify actual file/function/selector locations
 - Use evidence: Base analysis on actual test runs, errors, code inspection
 - Respect annotations: If test is marked with `test.skip()`, do not touch it

package/dist/stably-plugin-cli/skills/playwright-cli/SKILL.md

@@ -231,6 +231,38 @@ playwright-cli run-test --help
 - Overrides `browser`/`context`/`page` fixtures to connect via CDP (no new browser launched)
 - Preserves browser state after the run (pages remain open for inspection)
 
+### Running Multiple Tests Sequentially (Verification)
+
+**CRITICAL:** When verifying that multiple independent tests pass, you **MUST close and reopen the browser** between each `run-test` call. Browser state (cookies, localStorage, auth sessions) persists between runs, and stale state from one test will contaminate the next.
+
+This applies when you are running separate test files to check they pass — not when intentionally using `run-test` as a setup/seed mechanism (see "Use run-test as a Setup/Seed Mechanism" above).
+
+**IMPORTANT: `playwright-cli close` must be its own separate Bash call.** Do NOT chain it with other commands (e.g., `playwright-cli close; playwright-cli run-test ...`). The browser is only fully terminated after the Bash command finishes, so chaining means the next command runs on the old browser with stale state.
+
+```bash
+# CORRECT: Each command is a separate Bash call
+playwright-cli run-test tests/login.spec.ts
+playwright-cli close
+playwright-cli run-test tests/checkout.spec.ts
+playwright-cli close
+playwright-cli run-test tests/settings.spec.ts
+```
+
+```bash
+# WRONG: Chaining close with run-test in one command
+playwright-cli close; playwright-cli run-test tests/checkout.spec.ts  # ← run-test hits old browser
+playwright-cli close && playwright-cli run-test tests/settings.spec.ts  # ← same problem
+```
+
+```bash
+# WRONG: Running independent tests without resetting — causes cascading failures
+playwright-cli run-test tests/login.spec.ts
+playwright-cli run-test tests/checkout.spec.ts   # ← may fail: browser still has login state from test 1
+playwright-cli run-test tests/settings.spec.ts   # ← may fail: stale cookies/auth from previous tests
+```
+
+**Why this matters:** The browser is a cloud VM that persists across commands. `playwright-cli close` terminates it, but only after the Bash call returns. If you chain `close; run-test`, the test runs on the old browser before it's terminated. Running `close` as its own Bash call ensures the old browser is fully gone before the next test starts with a fresh one.
+
 ### Key Differences from `npx playwright test`
 
 | Feature | `playwright-cli run-test` | `npx playwright test` |

package/dist/stably-plugin-cli/skills/stably-cli/SKILL.md

@@ -195,6 +195,11 @@ export default defineConfig({
 
 ## CI/CD: GitHub Actions
 
+### Important CI patterns
+
+- **Use `stably install`** instead of `playwright install` to set up browsers.
+- **Use `continue-on-error: true`** on test, fix, and PR steps so the pipeline can run fix/PR steps after failures — but **always add a final step that fails the workflow** if tests failed. Without `continue-on-error` on the fix/PR steps, a failure there blocks downstream steps.
+
 ### Self-healing test pipeline
 
 ```yaml
@@ -208,34 +213,47 @@ jobs:
       - uses: actions/setup-node@v4
         with: { node-version: '20' }
       - run: npm ci
-      - run: npx stably install --with-deps
+      - name: Install browsers
+        run: npx stably install --with-deps
       - name: Run tests
         id: test
-        run: npx stably --env staging test || echo "TEST_FAILED=true" >> "$GITHUB_ENV"
+        continue-on-error: true
+        run: npx stably --env staging test
         env:
           STABLY_API_KEY: ${{ secrets.STABLY_API_KEY }}
           STABLY_PROJECT_ID: ${{ secrets.STABLY_PROJECT_ID }}
       - name: Auto-fix failures
-        if: env.TEST_FAILED == 'true'
+        if: steps.test.outcome == 'failure'
+        continue-on-error: true
         run: npx stably --env staging fix
         env:
           STABLY_API_KEY: ${{ secrets.STABLY_API_KEY }}
           STABLY_PROJECT_ID: ${{ secrets.STABLY_PROJECT_ID }}
-      - name: Re-run tests after fix
-        if: env.TEST_FAILED == 'true'
-        run: npx stably --env staging test
+      - name: Create PR with fixes
+        if: steps.test.outcome == 'failure'
+        continue-on-error: true
+        run: |
+          if [ -n "$(git status --porcelain)" ]; then
+            BRANCH="stably-fix/$(date +%Y%m%d-%H%M%S)"
+            git config user.name "github-actions[bot]"
+            git config user.email "github-actions[bot]@users.noreply.github.com"
+            git checkout -b "$BRANCH"
+            git add -A
+            git commit -m "fix: auto-repair failing tests"
+            git push origin "$BRANCH"
+            gh pr create \
+              --title "fix: auto-repair failing tests" \
+              --body "Automated PR from Stably Fix after test failures in run #${{ github.run_number }}." \
+              --base "${{ github.ref_name }}" \
+              --head "$BRANCH"
+          fi
         env:
-          STABLY_API_KEY: ${{ secrets.STABLY_API_KEY }}
-          STABLY_PROJECT_ID: ${{ secrets.STABLY_PROJECT_ID }}
-      - name: Commit fixes
-        if: env.TEST_FAILED == 'true' && github.event_name == 'push'
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Fail if tests failed
+        if: steps.test.outcome == 'failure'
         run: |
-          git config --local user.email "action@github.com"
-          git config --local user.name "GitHub Action"
-          # Adjust paths to match your project's test directories
-          git add 'tests/' 'e2e/' '**/*.spec.ts' '**/*.test.ts' 2>/dev/null || true
-          git diff --staged --quiet || git commit -m "fix: auto-repair failing tests [skip ci]"
-          git push
+          echo "::error::Tests failed"
+          exit 1
 ```
 
 ## Troubleshooting

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "stably",
-  "version": "4.12.1",
+  "version": "4.12.2",
   "packageManager": "pnpm@10.24.0",
   "description": "AI-powered E2E Playwright testing CLI. Stably can understand your codebase, edit/run tests, and handle complex test scenarios for you.",
   "main": "dist/index.mjs",
@@ -84,6 +84,7 @@
   },
   "devDependencies": {
     "@playwright/test": "^1.58.2",
+    "playwright": "1.59.0-alpha-1771104257000",
     "@stablyai/codegen-agent-constants": "workspace:*",
     "@stablyai-internal/api-client": "workspace:*",
     "@stablyai-internal/playwright-cli": "0.4.0",
@@ -106,7 +107,6 @@
     "dotenv-cli": "^11.0.0",
     "execa": "^9.5.3",
     "node-pty": "1.2.0-beta.10",
-    "playwright": "1.57.0",
     "terser": "^5.44.1",
     "tsup": "^8.5.0",
     "tsx": "^4.20.5",