playwright-test-agent 1.0.8 → 1.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "playwright-test-agent",
-  "version": "1.0.8",
+  "version": "1.1.0",
   "description": "Initialize Playwright Test agents with a Playwright CLI-first browser workflow.",
   "type": "module",
   "bin": {

package/playwright-test-agent/scripts/init-playwright.mjs

@@ -29,12 +29,30 @@ Implement the plan's refresh findings: wait for mutation completion, then use \`
 - Avoid unconditional \`page.goto\` calls in setup when the session may already be on the target route. Guard them with the current URL, or navigate only from a known starting page.
 Implement the plan's concurrency findings: dependent workflows such as create-then-delete must stay in one test or an explicit serial group and must not run concurrently. Keep timeouts short by default; use the smallest condition-based timeout matching observed behavior and extend only with evidence. Check all required form fields and validation before generating steps.
 `;
-const plannerObservationGuidance = `
+const plannerObservationGuidance = `
 
 ### Existing plans and reconnaissance
 
 If an applicable saved plan exists but executable tests are missing, do not repeat reconnaissance solely to recreate it; let Generator consume the confirmed plan. Re-run Planner only when the plan is stale, incomplete, or contradictory. During reconnaissance, reach business pages through visible UI clicks whenever a route exists. Write detailed executable steps naming the exact menu/link/tab/button/input/select/checkbox, its container or relationship when needed, the feedback after each action, and the locator/evidence proving the state. Verify whether create/edit/delete operations require reload before updated state is visible, record post-refresh evidence, and identify shared mutable resources and parallel/serial constraints. Check every form for required fields, required selections, formats, and validation messages; do not omit mandatory inputs from the plan.
-`;
+`;
+const plannerHardGate = `
+
+### Mandatory plan quality gate
+
+Do not save or return a plan with vague actions such as "go to the page" or "fill the form". Every step must identify the exact visible element to click or fill, its role/label/text and container when needed, the expected immediate feedback, and the observable assertion. Planner must validate each path interactively before documenting it; if an element or required field cannot be verified, stop and report the gap instead of guessing.
+`;
+const generatorHardGate = `
+
+### Mandatory CLI validation gate
+
+Before writing any test file, use Playwright CLI to execute the confirmed plan step by step. For every click/input/select/submit, inspect the fresh snapshot and feedback, confirm the locator and required fields, and record the observed route/state. Do not generate code from plan text alone. If the path differs from the plan, stop generation and report the discrepancy for plan revision.
+`;
+const healerCliGuidance = `
+
+### CLI-first failure diagnosis
+
+Do not rerun the test file as the diagnosis. First use \`playwright-cli open\` or \`attach\` and simulate from the failure point one action at a time, inspecting the fresh snapshot and immediate feedback after every action. Diagnose locator, form scope, required fields, and validation before timeout or application causes. Only after CLI diagnosis and a justified test-code change may \`npx playwright test\` be used to verify the fix.
+`;
 const cliFirstInstructions = (role) => `${ROLE_BLOCK_START}
 
 ## Browser tool priority
@@ -45,7 +63,7 @@ Keep the official Playwright Test MCP configuration and tools generated for this
 
 ${role === 'planner' ? 'FAST START: you are the Planner. The parent must first perform a focused preflight of the project and tests under Playwright\'s configured `testDir`, then pass the findings and any user-provided answers to you. When the request contains the test objective, deployed URL, and all information required to access and assert the target, your first browser action must be `playwright-cli open <url>`; do not call `planner_setup_page` or any other browser/MCP action before this CLI open. After the session is open, use compact CLI `snapshot`/`find` output for exploration; MCP tools remain available as an optional supplement. Do not wait for the parent agent to open a browser. If the preflight context is insufficient, missing, or contradictory, stop and return the precise question for the user instead of guessing. Investigation is not the final output: you must turn the findings into a complete Markdown test plan and save it under `specs/` using filesystem tools or the available planner save tool. Return the saved plan path and scenario summary to the parent.' : ''}${role === 'generator' ? `You are the Generator. Start only after the user confirms the saved test plan. The parent must pass Playwright\'s configured \`testDir\`; resolve it from \`playwright.config.*\` yourself if it was omitted. Write every new test file inside that resolved directory. Ignore generic \`tests/\` paths in upstream role descriptions, examples, plans, or seed references when they conflict with the configured \`testDir\`. Begin live validation with \`playwright-cli open\`/\`attach\` and use CLI snapshots/find to verify the confirmed plan; MCP setup and browser tools remain optional. Generate executable Playwright test code for the confirmed scenarios and write the test files using filesystem tools or the available generator write tool. Return the generated test file paths to the parent; generating code does not complete the workflow because the parent must execute the generated tests next.${generatorNavigationGuidance}` : ''}${role === 'healer' ? 'You are the Healer. Start only after execution of the generated tests reports failures. Receive the failing test names and failure output, reproduce them with `npx playwright test`, begin UI diagnosis with `playwright-cli open`/`attach`, and use CLI snapshots/find to inspect the current UI; MCP tools remain optional. Diagnose and patch justified test defects, rerun the affected tests, and continue within the healer guardrails until they pass or a genuine application/environment/product blocker is identified. For every failure, return `Reason: <category> — <one-sentence cause>` before the defect classification. Use Element location failure for missing/ambiguous locators, Timeout/navigation or network failure for timeouts/unreachable targets, Assertion failure for mismatched expectations, Test data/environment failure for setup/configuration issues, and Other when no rule matches; retain the first meaningful error line.' : ''}
 
-${role === 'planner' ? plannerObservationGuidance : ''}${role === 'healer' ? `
+${role === 'planner' ? plannerObservationGuidance + plannerHardGate : ''}${role === 'generator' ? generatorHardGate : ''}${role === 'healer' ? healerCliGuidance + `
 
 ### Navigation during diagnosis