playwright 1.56.1 → 1.57.0

package/lib/agents/{healer.md → playwright-test-healer.agent.md}

@@ -1,13 +1,10 @@
 ---
-name: healer
+name: playwright-test-healer
 description: Use this agent when you need to debug and fix failing Playwright tests
-color: red
 model: sonnet
+color: red
 tools:
-  - ls
-  - grep
-  - read
-  - write
+  - search
   - edit
   - playwright-test/browser_console_messages
   - playwright-test/browser_evaluate
@@ -24,8 +21,8 @@ resolving Playwright test failures. Your mission is to systematically identify,
 broken Playwright tests using a methodical approach.
 
 Your workflow:
-1. **Initial Execution**: Run all tests using playwright_test_run_test tool to identify failing tests
-2. **Debug failed tests**: For each failing test run playwright_test_debug_test.
+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
@@ -56,23 +53,3 @@ Key principles:
   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
-
-<example>
-  Context: A developer has a failing Playwright test that needs to be debugged and fixed.
-  user: 'The login test is failing, can you fix it?'
-  assistant: 'I'll use the healer agent to debug and fix the failing login test.'
-  <commentary>
-    The user has identified a specific failing test that needs debugging and fixing, which is exactly what the
-    healer agent is designed for.
-  </commentary>
-</example>
-
-<example>
-  Context: After running a test suite, several tests are reported as failing.
-  user: 'Test user-registration.spec.ts is broken after the recent changes'
-  assistant: 'Let me use the healer agent to investigate and fix the user-registration test.'
-  <commentary>
-     A specific test file is failing and needs debugging, which requires the systematic approach of the
-     playwright-test-healer agent.
-  </commentary>
-</example>

package/lib/agents/playwright-test-plan.prompt.md

@@ -0,0 +1,9 @@
+---
+agent: playwright-test-planner
+description: Create test plan
+---
+
+Create test plan for "add to cart" functionality of my app.
+
+- Seed file: `${seedFile}`
+- Test plan: `specs/coverage.plan.md`

package/lib/agents/{planner.md → playwright-test-planner.agent.md}

@@ -1,13 +1,10 @@
 ---
-name: planner
+name: playwright-test-planner
 description: Use this agent when you need to create comprehensive test plan for a web application or website
 model: sonnet
 color: green
 tools:
-  - ls
-  - grep
-  - read
-  - write
+  - search
   - playwright-test/browser_click
   - playwright-test/browser_close
   - playwright-test/browser_console_messages
@@ -26,6 +23,7 @@ tools:
   - playwright-test/browser_type
   - playwright-test/browser_wait_for
   - playwright-test/planner_setup_page
+  - playwright-test/planner_save_plan
 ---
 
 You are an expert web test planner with extensive experience in quality assurance, user experience testing, and test
@@ -38,7 +36,7 @@ You will:
    - Invoke the `planner_setup_page` tool once to set up page before using any other tools
    - Explore the browser snapshot
    - Do not take screenshots unless absolutely necessary
-   - Use browser_* tools to navigate and discover interface
+   - Use `browser_*` tools to navigate and discover interface
    - Thoroughly explore the interface, identifying all interactive elements, forms, navigation paths, and functionality
 
 2. **Analyze User Flows**
@@ -63,48 +61,7 @@ You will:
 
 5. **Create Documentation**
 
-   Save your test plan as requested:
-   - Executive summary of the tested page/application
-   - Individual scenarios as separate sections
-   - Each scenario formatted with numbered steps
-   - Clear expected results for verification
-
-<example-spec>
-# TodoMVC Application - Comprehensive Test Plan
-
-## Application Overview
-
-The TodoMVC application is a React-based todo list manager that provides core task management functionality. The
-application features:
-
-- **Task Management**: Add, edit, complete, and delete individual todos
-- **Bulk Operations**: Mark all todos as complete/incomplete and clear all completed todos
-- **Filtering**: View todos by All, Active, or Completed status
-- **URL Routing**: Support for direct navigation to filtered views via URLs
-- **Counter Display**: Real-time count of active (incomplete) todos
-- **Persistence**: State maintained during session (browser refresh behavior not tested)
-
-## Test Scenarios
-
-### 1. Adding New Todos
-
-**Seed:** `tests/seed.spec.ts`
-
-#### 1.1 Add Valid Todo
-**Steps:**
-1. Click in the "What needs to be done?" input field
-2. Type "Buy groceries"
-3. Press Enter key
-
-**Expected Results:**
-- Todo appears in the list with unchecked checkbox
-- Counter shows "1 item left"
-- Input field is cleared and ready for next entry
-- Todo list controls become visible (Mark all as complete checkbox)
-
-#### 1.2
-...
-</example-spec>
+   Submit your test plan using `planner_save_plan` tool.
 
 **Quality Standards**:
 - Write steps that are specific enough for any tester to follow
@@ -113,23 +70,3 @@ application features:
 
 **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.
-
-<example>
-  Context: User wants to test a new e-commerce checkout flow.
-  user: 'I need test scenarios for our new checkout process at https://mystore.com/checkout'
-  assistant: 'I'll use the planner agent to navigate to your checkout page and create comprehensive test
-  scenarios.'
-  <commentary>
-    The user needs test planning for a specific web page, so use the planner agent to explore and create
-    test scenarios.
-  </commentary>
-</example>
-<example>
-  Context: User has deployed a new feature and wants thorough testing coverage.
-  user: 'Can you help me test our new user dashboard at https://app.example.com/dashboard?'
-  assistant: 'I'll launch the planner agent to explore your dashboard and develop detailed test
-  scenarios.'
-  <commentary>
-    This requires web exploration and test scenario creation, perfect for the planner agent.
-  </commentary>
-</example>

package/lib/common/config.js

@@ -69,6 +69,11 @@ class FullConfigInternal {
     this.globalSetups = (Array.isArray(userConfig.globalSetup) ? userConfig.globalSetup : [userConfig.globalSetup]).map((s) => resolveScript(s, configDir)).filter((script) => script !== void 0);
     this.globalTeardowns = (Array.isArray(userConfig.globalTeardown) ? userConfig.globalTeardown : [userConfig.globalTeardown]).map((s) => resolveScript(s, configDir)).filter((script) => script !== void 0);
     userConfig.metadata = userConfig.metadata || {};
+    const globalTags = Array.isArray(userConfig.tag) ? userConfig.tag : userConfig.tag ? [userConfig.tag] : [];
+    for (const tag of globalTags) {
+      if (tag[0] !== "@")
+        throw new Error(`Tag must start with "@" symbol, got "${tag}" instead.`);
+    }
     this.config = {
       configFile: resolvedConfigFile,
       rootDir: pathResolve(configDir, userConfig.testDir) || configDir,
@@ -91,6 +96,7 @@ class FullConfigInternal {
       quiet: takeFirst(configCLIOverrides.quiet, userConfig.quiet, false),
       projects: [],
       shard: takeFirst(configCLIOverrides.shard, userConfig.shard, null),
+      tags: globalTags,
       updateSnapshots: takeFirst(configCLIOverrides.updateSnapshots, userConfig.updateSnapshots, "missing"),
       updateSourceMethod: takeFirst(configCLIOverrides.updateSourceMethod, userConfig.updateSourceMethod, "patch"),
       version: require("../../package.json").version,

package/lib/common/expectBundle.js

@@ -22,17 +22,11 @@ __export(expectBundle_exports, {
   EXPECTED_COLOR: () => EXPECTED_COLOR,
   INVERTED_COLOR: () => INVERTED_COLOR,
   RECEIVED_COLOR: () => RECEIVED_COLOR,
-  asymmetricMatchers: () => asymmetricMatchers,
   expect: () => expect,
-  matcherUtils: () => matcherUtils,
-  mock: () => mock,
   printReceived: () => printReceived
 });
 module.exports = __toCommonJS(expectBundle_exports);
 const expect = require("./expectBundleImpl").expect;
-const mock = require("./expectBundleImpl").mock;
-const asymmetricMatchers = require("./expectBundleImpl").asymmetricMatchers;
-const matcherUtils = require("./expectBundleImpl").matcherUtils;
 const EXPECTED_COLOR = require("./expectBundleImpl").EXPECTED_COLOR;
 const INVERTED_COLOR = require("./expectBundleImpl").INVERTED_COLOR;
 const RECEIVED_COLOR = require("./expectBundleImpl").RECEIVED_COLOR;
@@ -44,9 +38,6 @@ const printReceived = require("./expectBundleImpl").printReceived;
   EXPECTED_COLOR,
   INVERTED_COLOR,
   RECEIVED_COLOR,
-  asymmetricMatchers,
   expect,
-  matcherUtils,
-  mock,
   printReceived
 });