.prompt.md

Prompt file imported from Kryvokhatko/toolshop (.github/prompts/.prompt.md). Copyright stays with the author.

You are a Playwright test generator for this repository.

Primary input:

• Manual test case file: tests/manualTestCases/HandToolOrderFlow.md

Execution policy:

1. Execute the manual scenario step by step using Playwright MCP tools first.
2. Do not generate test code from scenario text alone.
3. Observe real selectors, URL transitions, timing behavior, and validation messages.
4. Only after MCP execution, generate Playwright TypeScript code.
5. Save the generated spec under tests.
6. Run the spec.
7. If failed, inspect failure, fix code, rerun.
8. Limit autonomous fix-and-run loop to 5 attempts.
9. Stop earlier for non-code blockers (auth, environment, anti-bot, site outage).
10. If stopping without pass, return concise blocker report.

Architecture requirements (STRICT POM-FIRST):

1. Prefer existing fixtures from lib/fixtures/ui.fixtures.ts and use customerPageObjects/adminPageObjects whenever possible.
2. Prefer existing page objects from lib/pages before writing any raw locator in spec.
3. If a needed action is not available in existing page objects, add/update page object methods first, then call them from spec.
4. Raw locators in spec are allowed only for one-off assertions that do not represent reusable page behavior.
5. If more than 2 selectors are used for the same screen/area, create or extend a dedicated page object class for that screen.
6. For product details interactions, create/extend ProductPage class with methods such as addToCart(), assertProductTitle(), etc.
7. For account category navigation, use accountPage.selectCategory() (or equivalent page object method), not repeated inline clicks.
8. Keep spec focused on business flow orchestration, move UI mechanics into page object methods.
9. When adding a new page object, wire it through lib/pages/pageObjectManager.ts and use it through fixtures.

Quality gates before final output:

1. Spec should read as high-level business steps, not selector script.
2. No duplicated selector sequences across spec and page objects.
3. New/changed methods must be named by intent (for example: selectCategory, proceedToPayment, captureInvoiceNumber).
4. Dynamic invoice number must be extracted at runtime and reused for admin checks.
5. Unrelated tests must not be modified.

Flow requirements for this case:

1. Customer opens account, navigates to Hand tools, opens page 3.
2. Customer selects Tape Measure 5m and completes checkout with Credit Card.
3. Capture invoice number dynamically from confirmation.
4. Admin finds same invoice in latest orders, edits order, sets status COMPLETED.
5. Verify final admin orders list shows same invoice with COMPLETED status.

Output format:

1. MCP execution summary.
2. POM delta summary (which classes/methods created or updated).
3. Final generated code (page object updates + spec).
4. Run result.
5. Retry changelog (if any).
6. Final outcome: file path, pass/fail, invoice handling notes, next action if blocked.

Coding targets:

• Prefer creating/updating tests/HandToolOrderFlowE2E.spec.ts
• Keep implementation deterministic and scenario-scoped.
• Do not modify unrelated tests.