Automation Framework Creation.

You are a senior QA architect with deep expertise in Playwright and TypeScript. Design a production-ready Playwright TypeScript test framework architecture for the application described below.

Application type: {{APPLICATION_TYPE}}
Application URL(s): {{APP_URLS}}
Team size and skill level: {{TEAM_SKILL}}
Test scope (e2e, component, visual, API): {{TEST_SCOPE}}
CI/CD platform: {{CI_PLATFORM}}
Environments to support: {{ENVIRONMENTS}}
Reporting requirements: {{REPORTING_REQUIREMENTS}}

Produce a detailed architecture covering all of the following:

1. **Folder structure** — annotated directory tree showing where tests, fixtures, page objects, helpers, test data, and config live.
2. **Configuration** — playwright.config.ts settings: browsers, base URL per environment, retries, timeout strategy, parallelism, and how environment-specific values are injected (dotenv, process.env, CI secrets — never hardcode URLs or tokens).
3. **Page Object Model** — how page objects are structured, what they expose, and what belongs in a page object vs a helper vs a fixture.
4. **Test data strategy** — how test data is created, isolated, and cleaned up. Note builder patterns, factories, or API-driven setup. Real credentials, PII, and production data must never appear in the framework.
5. **Authentication strategy** — storageState approach, fixture-based auth, and how to handle multiple user roles without repeating login steps.
6. **Reporting** — Playwright HTML report, CI artefact upload, and optional Allure integration.
7. **CI/CD integration** — {{CI_PLATFORM}} workflow snippet for running tests in parallel, caching node_modules, and uploading the report as an artefact.
8. **Anti-patterns to avoid** — at least 5 specific anti-patterns (e.g., hardcoded waits, brittle CSS selectors, shared state between tests) with a one-line explanation of each.

Format each section with a heading. State all assumptions explicitly. This is a design document for human review — the team must validate every decision against their actual constraints before implementing.

You are a senior QA architect with deep expertise in REST Assured and Java API testing. Design a production-ready REST Assured test framework architecture.

API type and domain: {{API_TYPE}}
Authentication mechanism: {{AUTH_MECHANISM}}
Build tool: {{BUILD_TOOL}} (Maven or Gradle)
Test runner: {{TEST_RUNNER}} (JUnit 5 or TestNG)
Team size and Java experience: {{TEAM_SKILL}}
Environments: {{ENVIRONMENTS}}
CI/CD platform: {{CI_PLATFORM}}
Reporting requirements: {{REPORTING_REQUIREMENTS}}

Produce a detailed architecture covering all of the following:

1. **Module and package structure** — annotated directory tree for src/test, showing where specs, request builders, response validators, test data, and config live.
2. **Base configuration** — RequestSpecification base setup; how base URL, auth headers, and timeouts are injected per environment via system properties or a config file. Do NOT hardcode secrets — show the System.getenv() / properties file pattern with a comment explaining where to set values.
3. **Request/Response builder pattern** — how to avoid duplicating endpoint setup using builder classes or static factory methods.
4. **Test data strategy** — how test objects are created (builders, factories, external JSON fixtures). Real credentials and PII must never appear in test data or committed fixtures.
5. **Assertions and schema validation** — Hamcrest matchers vs JSONPath; JSON Schema validation approach; asserting error response bodies, not just status codes.
6. **Test grouping and tagging** — JUnit 5 @Tag / TestNG groups for smoke, regression, contract tests; how CI runs subsets.
7. **CI/CD integration** — build tool command; {{CI_PLATFORM}} workflow snippet; environment variable injection; report upload.
8. **Anti-patterns to avoid** — at least 5 specific ones (e.g., hardcoded base URLs, one test class per endpoint, no schema validation, shared mutable state across tests).

Annotate all assumptions. This is a design for human review, not production-ready code.

You are a senior QA architect specialising in BDD and Cucumber frameworks. Design a production-ready BDD framework architecture.

Application type: {{APPLICATION_TYPE}}
Automation stack: {{AUTOMATION_STACK}} (e.g. Cucumber + Playwright + TypeScript, or Cucumber + Selenium + Java)
Team composition: {{TEAM_COMPOSITION}} (who writes feature files vs step definitions)
Feature domains: {{FEATURE_DOMAINS}}
CI/CD platform: {{CI_PLATFORM}}
Environments: {{ENVIRONMENTS}}

Produce a detailed architecture covering all of the following:

1. **Project structure** — annotated directory tree for features (by domain), step definitions, hooks, page objects/helpers, test data, and config.
2. **Feature file organisation** — naming conventions, domain grouping, tag strategy (@smoke, @regression, @wip), and guidelines for keeping scenarios readable by product owners.
3. **Step definition design** — how to scope step definitions (per domain or per page), how to share context between steps using dependency injection (not global state), and the anti-pattern of over-generic steps.
4. **Hooks and setup** — @Before/@After hooks for browser launch, test data seeding, screenshot on failure, and cleanup. How to scope hooks by tag to avoid running heavy setup for every scenario.
5. **Test data handling** — Scenario Outline and example tables for data-driven tests; external JSON fixtures. Note that credentials, PII, and production data must never appear in feature files or committed fixtures.
6. **Parallel execution** — how to run scenarios in parallel without cross-test state pollution; the specific shared-state risks in BDD that don't exist in unit tests.
7. **CI/CD integration** — command to run tagged subsets; {{CI_PLATFORM}} workflow snippet; report upload.
8. **Anti-patterns to avoid** — at least 5 BDD-specific anti-patterns (e.g., UI steps leaking into API scenarios, over-generic steps that test nothing specific, scenario duplication, testing implementation rather than behaviour).

Annotate all assumptions. This is a design for human review.

You are a senior QA automation and DevOps engineer. Design a CI/CD pipeline configuration and test reporting setup for an existing test framework.

Existing framework details: {{FRAMEWORK_DETAILS}}
Language and runtime: {{LANGUAGE_RUNTIME}}
CI/CD platform: {{CI_PLATFORM}}
Test command: {{TEST_COMMAND}}
Target environment(s): {{ENVIRONMENTS}}
Required secrets — names only, never paste actual values: {{SECRET_NAMES}}
Parallelism requirements: {{PARALLELISM}}
Reporting requirements: {{REPORTING_REQUIREMENTS}}
Failure notification requirements: {{NOTIFICATION_REQUIREMENTS}}

Produce all of the following:

1. **Pipeline workflow file** — complete {{CI_PLATFORM}} workflow (YAML or equivalent) that:
   - Triggers on pull request and on merge to main.
   - Installs dependencies with caching.
   - Injects environment variables from CI secrets (using the names from {{SECRET_NAMES}} — placeholder values only).
   - Runs {{TEST_COMMAND}} with the requested parallelism.
   - Always uploads the test report as a build artefact, even on failure (use if: always()).
2. **Parallelism / sharding** — if {{PARALLELISM}} > 1, show how to shard the run across matrix jobs.
3. **Reporting setup** — configuration for the requested report format (HTML, Allure, JUnit XML); how to view the report after a run.
4. **Failure notifications** — if {{NOTIFICATION_REQUIREMENTS}} requests Slack or email, provide a notification step triggered on failure using a secret webhook URL — never hardcode the URL.
5. **CI security checklist** — 5 CI/CD security practices for this setup: secrets masking, no hardcoded tokens, artefact retention limits, branch protection, dependency pinning.

Important: Replace all placeholder secret names with your actual CI/CD secrets store values before using this configuration. Never commit real tokens, passwords, or API keys to source control.