System Requirements Document for playwright-pytest

1. Introduction

playwright-pytest is a web automation testing project. Its product intent is to deliver a working, runnable Python automation test suite that drives a target web application through a browser using Playwright, executes its checks with pytest, and organizes all automation code according to the Page Object Model (POM) structure.

The audience is the Test Automation Engineer — a technical practitioner who builds and maintains the suite, defines page objects that encapsulate page locators and actions, writes pytest test cases that exercise web workflows through those page objects, and runs the suite to verify results. Success means a working, runnable POM-structured automation project whose tests execute against the target web application.

The product is a developer-tooling artifact, not a consumer application. Its surface is a legible, honest presentation of the project's structure and its executable parts: the scaffold, the page objects, the test cases, and the results of running them.

2. System Overview

The current delivery is a first-party custom interface that presents and supports the Python + Playwright + pytest automation project organized in Page Object Model structure. The interface is the working surface for the Test Automation Engineer: it explains the project, exposes the runnable scaffold and configuration, presents the page object classes, presents the pytest test cases, and supports running the suite and observing pass or fail results.

Actors. The single accepted active human persona is the Test Automation Engineer. The target web application under test is an external system acted upon by the automation suite; it is not a persona and does not interact with the interface. The browser engine driven by Playwright is a system actor.

Accepted behavior. The project must be built in Python, must use Playwright for browser automation, must use pytest as the test runner, and must organize code following the Page Object Model structure. The suite must be runnable and its results observable.

Ownership. All five accepted destinations are first-party application pages with no access requirement: Landing, Project Setup, Page Objects, Test Cases, and Test Results. No application-owned identity, sign-in, or account management is part of this product.

Narrow exclusions. This document does not introduce test management platforms, CI/CD pipeline configuration, reporting dashboards beyond the run result surface, cross-browser matrix management, visual regression tooling, or any adjacent capability not present in the authoritative requirement thread.

2a. Product Interpretation and Delivery Boundary

The product is delivered as a first-party web interface that documents and operationalizes a Python automation testing project. The interface is openly reachable — there is no sign-in, no account, and no private per-user state. Every accepted destination is available directly, because the accepted work is a shared, inspectable artifact: the scaffold, the page objects, the test cases, and the run results.

The boundary between current and future work is narrow. Current work is exactly: a Python project using Playwright and pytest in Page Object Model structure, with a runnable suite whose results can be observed. Anything beyond that — additional frameworks, additional reporting layers, deployment pipelines, or hosted test infrastructure — is outside the accepted scope and is not part of this generation.

The target web application under test is owned externally. The suite drives it through Playwright; the interface does not own, host, or modify that application.

2b. Page Content and Component Coverage

Landing

• Information and state. The project identity and its thesis: a Python web automation suite built with Playwright and pytest, organized in Page Object Model structure. The page presents the split between the page-object abstraction and the executable test as the project's defining idea.
• Primary action. Enter the project — proceed to Project Setup to obtain the runnable scaffold.
• Supporting actions. Navigate to Page Objects, Test Cases, or Test Results directly.
• Domain entities. Project, Page Object, Test Case, Test Run.
• Component responsibilities.
  • Project wordmark and one-line statement of the Python + Playwright + pytest + POM stack.
  • A folder-structure diagram showing the pages/ and tests/ split.
  • A representative code panel showing a page object file with line numbers.
  • A micro-label identifying the stack: Python · Playwright · pytest.
  • A single primary control to begin at Project Setup.
• States.
  • Loading: static content; no asynchronous load required.
  • Empty: not applicable — the page is fully static content.
  • Success: the engineer reads the project thesis and proceeds to Project Setup.
  • Error: not applicable.
  • Recovery: not applicable.

Project Setup

• Information and state. The runnable Python scaffold: project directory layout, dependency declaration for Playwright and pytest, pytest configuration, and the Playwright browser installation step. The state reflects whether the scaffold is presented as complete and ready to run.
• Primary action. Obtain the runnable project scaffold and its setup instructions.
• Supporting actions. Copy the dependency and configuration content; proceed to Page Objects or Test Cases.
• Domain entities. Project scaffold, dependency manifest, pytest configuration, Playwright browser installation.
• Component responsibilities.
  • Directory tree of the POM project structure (pages/, tests/, configuration files).
  • Dependency and configuration content blocks with file paths.
  • Setup step sequence: install Python dependencies, install Playwright browsers, confirm pytest configuration.
  • Navigation onward to Page Objects and Test Cases.
• States.
  • Loading: static content; no asynchronous load required.
  • Empty: shown when no scaffold content is available — the page states that the scaffold is not yet present.
  • Success: the engineer has the complete scaffold and setup steps.
  • Error: a setup step is incomplete or a required configuration element is missing — the page identifies which step is unresolved.
  • Recovery: the engineer corrects the identified step and re-checks the scaffold.

Page Objects

• Information and state. The Page Object classes that encapsulate target-page locators and actions. Each page object corresponds to a page or region of the target web application and exposes actions the tests call.
• Primary action. Read and use a page object class to drive a target page.
• Supporting actions. Navigate between page object classes; proceed to Test Cases to see how they are consumed.
• Domain entities. Page Object class, locator, page action, target page.
• Component responsibilities.
  • List of page object classes with their file paths.
  • Per-class detail: the target page it represents, its locators, and its exposed actions.
  • Code panel showing the class definition.
  • Navigation to Test Cases.
• States.
  • Loading: static content; no asynchronous load required.
  • Empty: shown when no page object classes exist — the page states that no page objects are defined yet.
  • Success: the engineer locates the page object and its actions.
  • Error: a page object is malformed or references an unresolvable locator — the page identifies the affected class.
  • Recovery: the engineer corrects the class and re-checks it.

Test Cases

• Information and state. The pytest test cases that drive web workflows through the Page Object classes. Each test case states the workflow it exercises and the page objects it uses.
• Primary action. Read and use a test case to exercise a web workflow.
• Supporting actions. Navigate between test cases; proceed to Test Results to run and observe outcomes.
• Domain entities. Test case, workflow under test, referenced page object, assertion.
• Component responsibilities.
  • List of test cases with their file paths and the workflows they cover.
  • Per-case detail: the page objects it drives and the assertions it makes.
  • Code panel showing the test function.
  • Navigation to Test Results.
• States.
  • Loading: static content; no asynchronous load required.
  • Empty: shown when no test cases exist — the page states that no tests are defined yet.
  • Success: the engineer locates the test case and understands the workflow it covers.
  • Error: a test case references a page object that does not exist — the page identifies the broken reference.
  • Recovery: the engineer corrects the reference and re-checks the test case.

Test Results

• Information and state. The outcome of running the suite: which tests passed and which failed, with the pytest run summary. The state reflects the most recent run.
• Primary action. Run the suite and observe pass or fail results.
• Supporting actions. Inspect an individual test's outcome; return to Test Cases to review the failing test.
• Domain entities. Test run, test outcome (pass/fail), run summary, failure detail.
• Component responsibilities.
  • Run control that starts the suite.
  • Run summary showing counts of passed and failed tests.
  • Per-test outcome list with pass and fail markers.
  • Failure detail for failing tests, including the assertion or error that caused the failure.
  • Navigation back to Test Cases.
• States.
  • Loading: shown while the suite is executing — the page indicates that a run is in progress.
  • Empty: shown before any run has been performed — the page states that no results are available yet and offers the run control.
  • Success: all tests pass — the page shows a clean pass summary.
  • Error: one or more tests fail — the page shows the failing tests and their failure detail.
  • Recovery: the engineer reviews the failure detail, returns to Test Cases or Page Objects to correct the cause, and runs the suite again.

3. Functional Requirements

FR-1 — Build the automation suite in Python (explicit) As a Test Automation Engineer, I should build the web automation testing code in Python, so that the suite runs on the Python runtime.

• Trigger/input: the engineer authors the project source.
• Observable result: the project source is Python and executes on a Python interpreter.
• Access state: no access requirement.
• Failure/recovery: if the code does not run on Python, the engineer corrects the source.
• Continuation: the engineer proceeds to configure Playwright and pytest.
• Acceptance: the project's automation code is written in Python and runs under a Python interpreter.

FR-2 — Use Playwright for browser automation (explicit) As a Test Automation Engineer, I should use Playwright as the browser automation library, so that the suite drives a real browser against the target web application.

• Trigger/input: the engineer authors browser interactions.
• Observable result: browser interactions are performed through Playwright against the target web application.
• Access state: no access requirement.
• Failure/recovery: if a browser interaction fails, the engineer inspects the failure and corrects the interaction or the locator.
• Continuation: the engineer proceeds to write page objects and tests.
• Acceptance: browser automation is performed through Playwright.

FR-3 — Use pytest as the test runner (explicit) As a Test Automation Engineer, I should use pytest as the test runner, so that the suite's test cases are discovered, executed, and reported by pytest.

• Trigger/input: the engineer runs the suite.
• Observable result: pytest discovers and executes the test cases and reports pass or fail outcomes.
• Access state: no access requirement.
• Failure/recovery: if pytest does not discover or execute a test, the engineer corrects the test's naming, location, or configuration.
• Continuation: the engineer observes the results.
• Acceptance: test cases are discovered and executed by pytest, and outcomes are reported by pytest.

FR-4 — Organize code following the Page Object Model structure (explicit) As a Test Automation Engineer, I should organize the automation code following the Page Object Model structure, so that page locators and actions are encapsulated in page objects separate from the tests that use them.

• Trigger/input: the engineer authors page objects and test cases.
• Observable result: page locators and actions live in page object classes; test cases drive those classes rather than addressing the page directly.
• Access state: no access requirement.
• Failure/recovery: if a test addresses the page directly instead of through a page object, the engineer moves the interaction into the appropriate page object.
• Continuation: the engineer proceeds to run the suite.
• Acceptance: the project separates page object classes from test cases, and tests exercise web workflows through the page objects.

FR-5 — Establish the Python environment (required_inference) As a Test Automation Engineer, I should have a working Python environment for the project, so that the suite's dependencies and code can be installed and executed.

• Trigger/input: the engineer sets up the project.
• Observable result: a Python environment exists in which the project's dependencies are installed and the suite can run.
• Access state: no access requirement.
• Failure/recovery: if the environment is missing or incomplete, the engineer installs the missing runtime or dependencies.
• Continuation: the engineer installs Playwright browsers and confirms pytest configuration.
• Acceptance: the project runs in a Python environment with its dependencies available.

FR-6 — Install Playwright and set up browsers (required_inference) As a Test Automation Engineer, I should install Playwright and its browser binaries, so that the suite can launch a browser and drive the target web application.

• Trigger/input: the engineer performs the Playwright installation and browser setup step.
• Observable result: Playwright is installed and a browser binary is available for the suite to launch.
• Access state: no access requirement.
• Failure/recovery: if a browser binary is unavailable, the engineer runs the browser installation step again and confirms the binary is present.
• Continuation: the engineer runs the suite.
• Acceptance: Playwright is installed and a browser can be launched by the suite.

FR-7 — Configure pytest (required_inference) As a Test Automation Engineer, I should configure pytest for the project, so that the suite's test cases are discovered and executed consistently.

• Trigger/input: the engineer authors the pytest configuration.
• Observable result: pytest discovers the project's test cases according to the configuration and executes them.
• Access state: no access requirement.
• Failure/recovery: if test discovery does not match the project layout, the engineer adjusts the configuration.
• Continuation: the engineer runs the suite and observes results.
• Acceptance: pytest configuration causes the project's test cases to be discovered and executed.

FR-8 — Follow the Page Object Model project structure (required_inference) As a Test Automation Engineer, I should lay out the project in a Page Object Model structure, so that page objects and tests are separated into distinct, navigable locations.

• Trigger/input: the engineer creates the project directories and files.
• Observable result: page object classes and test cases reside in separate, identifiable locations within the project.
• Access state: no access requirement.
• Failure/recovery: if page objects and tests are intermixed, the engineer reorganizes them into their respective locations.
• Continuation: the engineer adds page objects and test cases.
• Acceptance: the project layout separates page objects from test cases.

FR-9 — Define page objects that encapsulate locators and actions (required_inference) As a Test Automation Engineer, I should define page object classes that encapsulate the target page's locators and actions, so that tests interact with the page through a stable abstraction.

• Trigger/input: the engineer authors a page object class for a target page or region.
• Observable result: the page object exposes locators and actions for that target page, and tests can call those actions.
• Access state: no access requirement.
• Failure/recovery: if a locator does not resolve against the target page, the engineer corrects the locator in the page object.
• Continuation: the engineer writes test cases that use the page object.
• Acceptance: page object classes exist that encapsulate locators and actions for target pages, and tests drive the page through them.

FR-10 — Write pytest test cases that drive web workflows through page objects (required_inference) As a Test Automation Engineer, I should write pytest test cases that exercise web workflows through the page object classes, so that the target application's behavior is verified.

• Trigger/input: the engineer authors a test case that calls page object actions and asserts an expected outcome.
• Observable result: the test case exercises a web workflow through page objects and produces a pass or fail outcome.
• Access state: no access requirement.
• Failure/recovery: if the test fails, the engineer inspects the failure detail and corrects the test, the page object, or the expectation.
• Continuation: the engineer runs the suite and observes results.
• Acceptance: test cases exist that drive web workflows through page objects and assert expected outcomes.

FR-11 — Run the suite and observe pass or fail results (required_inference) As a Test Automation Engineer, I should run the suite and observe which tests pass and which fail, so that I know whether the target application behaves as expected.

• Trigger/input: the engineer starts a run of the suite.
• Observable result: the run completes and reports per-test pass or fail outcomes with a run summary.
• Access state: no access requirement.
• Failure/recovery: if one or more tests fail, the engineer reviews the failure detail, corrects the cause in the test or page object, and runs the suite again.
• Continuation: the engineer returns to the test cases or page objects to address failures, or concludes the run when all tests pass.
• Acceptance: running the suite produces observable per-test pass or fail outcomes and a run summary.

4. User Personas

Test Automation Engineer

Product context. The Test Automation Engineer is the sole active human actor for this product. They work in a Python codebase that drives a browser through Playwright and executes checks through pytest, with all page interaction logic separated into page objects. Their working material is source files, file paths, locators, and test output — not marketing content or dashboards.

Primary goal. A working, runnable POM-structured automation project whose tests execute against the target web application and report honest pass or fail results.

Distinct accepted responsibilities.

• Building the web automation testing code in Python.
• Using Playwright as the browser automation library to drive the target web application.
• Using pytest as the test runner that discovers, executes, and reports the test cases.
• Organizing the automation code following the Page Object Model structure, so that page locators and actions are encapsulated separately from the tests that use them.
• Establishing the Python environment, installing Playwright and its browsers, and configuring pytest so the suite is runnable.
• Defining page object classes that encapsulate target-page locators and actions.
• Writing pytest test cases that exercise web workflows through those page objects.
• Running the suite and observing which tests pass and which fail.

Relevant inputs and decisions. The engineer decides which target pages warrant a page object, which locators identify elements on those pages, which actions a page object should expose, which workflows a test case should exercise, and what outcome each test should assert. The engineer reads failure detail to decide whether the fault lies in the test, the page object, or the expectation.

Interactions with other accepted participants. The engineer is the only accepted human participant. The target web application under test is an external system the engineer's suite acts upon; it does not interact back with the interface. The browser engine driven by Playwright is a system actor the engineer's code commands.

Observable success. The project runs under Python, drives a browser through Playwright, executes its test cases through pytest, separates page objects from tests in the Page Object Model structure, and reports per-test pass or fail outcomes when the suite is run.

Source-backed constraints. The implementation language must be Python; browser automation must use Playwright; the test framework must be pytest; code organization must follow the Page Object Model structure. No permissions, account requirements, or role-based visibility apply — the accepted destinations carry no access requirement.

5. Core User Flows

Flow 1 — Understand the project and its structure

1. The Test Automation Engineer opens the Landing page.
2. The page presents the project identity: a Python web automation suite built with Playwright and pytest, organized in Page Object Model structure.
3. The engineer reads the folder-structure diagram showing the pages/ and tests/ split, and the representative page object code panel.
4. The engineer understands the separation between the page-object abstraction and the executable test.
5. Next step: the engineer proceeds to Project Setup to obtain the runnable scaffold.

Flow 2 — Obtain the runnable scaffold and set up the environment

1. The engineer opens the Project Setup page.
2. The page presents the project directory layout, the dependency declaration for Playwright and pytest, the pytest configuration, and the Playwright browser installation step.
3. The engineer obtains the scaffold and follows the setup sequence: install Python dependencies, install Playwright browsers, confirm pytest configuration.
4. Observable result: a Python environment exists in which the project's dependencies are installed and a browser binary is available for the suite to launch.
5. Failure/recovery: if a setup step is incomplete or a required configuration element is missing, the page identifies which step is unresolved; the engineer corrects that step and re-checks the scaffold.
6. Next step: the engineer proceeds to Page Objects to review or define the page object classes.

Flow 3 — Define a page object that encapsulates a target page

1. The engineer opens the Page Objects page.
2. The page lists the page object classes with their file paths and, per class, the target page it represents, its locators, and its exposed actions.
3. The engineer selects or authors a page object class for a target page or region of the target web application.
4. The engineer defines the locators that identify elements on that target page and the actions the page object exposes.
5. Observable result: the page object class encapsulates the target page's locators and actions, and is available for tests to call.
6. Failure/recovery: if a locator does not resolve against the target page, the page identifies the affected class; the engineer corrects the locator in the page object and re-checks it.
7. Next step: the engineer proceeds to Test Cases to write a test that uses the page object.

Flow 4 — Write a pytest test case that drives a web workflow

1. The engineer opens the Test Cases page.
2. The page lists the test cases with their file paths and the workflows they cover, and per case, the page objects it drives and the assertions it makes.
3. The engineer authors a test case that calls page object actions to exercise a web workflow and asserts an expected outcome.
4. Observable result: the test case exercises the workflow through page objects and is discoverable by pytest.
5. Failure/recovery: if the test case references a page object that does not exist, the page identifies the broken reference; the engineer corrects the reference and re-checks the test case.
6. Next step: the engineer proceeds to Test Results to run the suite.

Flow 5 — Run the suite and observe results

1. The engineer opens the Test Results page.
2. If no run has been performed, the page states that no results are available yet and offers the run control.
3. The engineer starts a run of the suite.
4. Observable result: while the suite executes, the page indicates that a run is in progress; when the run completes, the page reports per-test pass or fail outcomes and a run summary showing counts of passed and failed tests.
5. Failure/recovery: if one or more tests fail, the page shows the failing tests and their failure detail, including the assertion or error that caused the failure. The engineer reviews the failure detail, returns to Test Cases or Page Objects to correct the cause, and runs the suite again.
6. Continuation: when all tests pass, the page shows a clean pass summary and the engineer concludes the run; otherwise the engineer repeats the correction-and-rerun cycle.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Adham Dannaway, and the headline idea is craft where design meets code — the POM split, rendered in ink and acid green. The visual thesis is dual-nature composition: the page object (abstraction) and the pytest case (execution) are two halves of one craft, mirrored.

Color tokens (dark mode)

No blue anywhere. No gradients. Green and coral read as test semantics, not decoration.

Typography

• Headings: Space Grotesk 500/600, tight tracking (−0.02em), sentence case, oversized. Hero wordmark runs 56px on mobile to 128px on desktop; section headings sit at a deliberate 1.6× jump above body.
• Body: IBM Plex Mono 400/500 carries all body copy, labels, code, file paths, and test output. Uppercase at 11–12px with 0.12em letterspacing for micro-labels such as PAGE OBJECTS and TEST CASES. Mono is never used for long prose.
• Scale: 1.333 modular — 128 / 80 / 48 / 32 / 24 / 16 / 13.
• Display clamp: hero 56px @375 → 128px @1280; section 32px @375 → 48px @1280; body 15px @375 → 16px @1280; mono micro-label 11px fixed; code 13px @375 → 14px @1280.
• Line height: 1.05 for display, 1.5 for body, 1.6 for code blocks.

Shape language

Sharp corners everywhere — 2px radius on interactive controls at most, 0 on panels and images. Panels are defined by 1px hairlines (#262B33) and internal ruled rows, not by elevation. The one soft gesture is a 1px acid-green cursor bar that travels between the two hero halves. Buttons read as terminal keys: rectangular, hairline border, mono label, hover fills solid green with ink text. No pills, no blobs, no soft shadows.

Layout

A strict two-column split is the page's spine. At 1280px the hero is a 50/50 vertical split: the left half is the design side (light #F2F1EC panel, oversized Space Grotesk headline, a single annotated diagram of pages/ → tests/); the right half is the code side (ink #0E1013, a real POM code panel with line numbers and a green pass tick). The split line is a 1px hairline running the full viewport height and continuing as a ruled divider between every subsequent section — sections are separated by hairline rules with mono section numbers (01 / 02 / 03) in the left margin, never by cards.

Content below the hero is a 12-column grid with a 4-column mono rail for file paths and metadata. Each page — Project Setup, Page Objects, Test Cases, Test Results — gets a full-width ruled band with the label in the rail and the substance in the main column. At 768px the split stacks but the hairline divider and mono rail persist. At 375px the rail collapses above its content as a mono label, everything is single-column, and no element is wider than the viewport.

Imagery

The interface is the imagery. No stock photography, no 3D renders, no illustration. Visual material is: real POM code (pages/login_page.py, tests/test_login.py), a folder-tree diagram drawn in 1px hairlines and mono labels, a pytest run summary rendered as a real terminal block with green dots and one coral F, and a Playwright trace screenshot used once as a small framed inset inside the Test Results band. Diagrams are schematic and monochrome except for the single green or coral semantic mark. Anything that is not a real artifact of the project is cut.

7. Signature Design Concept

The split-screen hero as the POM thesis. The public entry is a full-bleed 50/50 split, not a centred SaaS hero.

• Left half — the design side. A warm off-white #F2F1EC panel carrying the wordmark playwright-pytest set in Space Grotesk at clamp(56px, 9vw, 128px), stacked on three lines flush-left: playwright- / pytest / POM. Beneath it, a 1px ruled annotation line points to a hairline folder diagram of pages/ and tests/. At the bottom of this half, a mono scroll hint reads 01 / SETUP.
• Right half — the code side. An ink #0E1013 panel carrying a real code block (pages/login_page.py, 14 lines, line numbers in muted #8B93A1, one green pass tick in the gutter) and a mono micro-label PYTHON · PLAYWRIGHT · PYTEST. Pinned to the bottom-left of this half is the only control: a rectangular mono RUN SUITE key.
• The split line. A 1px acid-green cursor bar sits on the split line and sweeps between the halves on a 6s loop, lighting a 1px green border on whichever half it crosses while the other dims to 60% opacity.

There is no centred headline, no subtext, and no button in the middle. Type is the hero image; the two halves are the literal POM thesis — abstraction versus execution — rather than a decorative layout. At 375px the split stacks: headline panel first at 56px, code panel beneath at 13px mono, and the cursor bar becomes a horizontal 1px line between them.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject. The 50/50 split itself: the design half (off-white panel, oversized stacked wordmark, folder diagram) and the code half (ink panel, real POM code block with line numbers and a green pass tick), divided by a full-height 1px hairline.
• Input → transformation → outcome thesis. The 1px acid-green cursor bar travels along the split line between the two halves on a 6s ease-in-out loop. As it crosses a half, that half gains a 1px green border and the other dims to 60% opacity. The outcome is the POM thesis made visible: abstraction and execution in continuous dialogue, neither subordinate to the other.
• Motion vocabulary. One purposeful loop only — the cursor sweep. Scroll reveals are single-shot 200ms opacity + 8px translate on section bands, staggered by 60ms. Hovering a file path in the mono rail highlights the corresponding code line on the right half, making the split's dialogue interactive. No bounce, no parallax theatre, no particles, no marquees or tickers.
• Composed first frame. The cursor bar parked at the centre of the split line, both halves at full opacity, the stacked wordmark flush-left on the off-white panel, the code block's line numbers and green pass tick visible on the ink panel, and the RUN SUITE key pinned bottom-left of the code half.
• Reduced-motion state. Under prefers-reduced-motion, the cursor bar parks in the centre and stops sweeping, hover-highlight becomes a static underline, and scroll reveals are instant. The split, the wordmark, the code block, and the RUN SUITE control remain fully readable and operable.

9. Non-Functional Requirements

NFR-1 — Implementation language (explicit) The automation code must be written in Python. Rationale: explicit hard constraint in the authoritative requirement thread.

NFR-2 — Browser automation library (explicit) Browser automation must use Playwright. Rationale: explicit hard constraint in the authoritative requirement thread.

NFR-3 — Test framework (explicit) The test framework must be pytest. Rationale: explicit hard constraint in the authoritative requirement thread.

NFR-4 — Code organization (explicit) Code organization must follow the Page Object Model structure. Rationale: explicit hard constraint in the authoritative requirement thread.

NFR-5 — Runnable suite (required_inference) The project must be runnable end to end: the environment installs, the browser launches, pytest discovers and executes the test cases, and results are observable. Rationale: the accepted outcome is a working, runnable automation project whose tests execute against the target web application.

NFR-6 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit. No other element may cover any part of them. Rationale: explicit direction constraint; readable text and controls take precedence over cropping gestures.

NFR-7 — Reduced-motion support (explicit, from the creative direction) Under prefers-reduced-motion, the cursor bar parks in the centre, hover-highlight becomes a static underline, and reveals are instant. Rationale: explicit direction constraint.

NFR-8 — No blue or indigo accent (explicit, from the creative direction) The palette is ink, acid green, and coral only. No blue or indigo accent, and no gradients. Rationale: explicit direction constraint; the generic indigo/blue-on-white SaaS template is forbidden for this project.

10. Tech Stack

• Language: Python (explicit — required by the authoritative requirement thread).
• Browser automation: Playwright (explicit), including Playwright browser installation and setup (required_inference).
• Test runner: pytest (explicit), including pytest configuration for test discovery and execution (required_inference).
• Code organization: Page Object Model structure, separating page object classes from test cases (explicit).
• Frontend presentation layer: React with a component-based page structure, styled to the creative direction's tokens (Space Grotesk headings, IBM Plex Mono body, ink/acid-green/coral palette, hairline-ruled bands) [Default — not specified by user].
• Backend service layer: Python with FastAPI to serve the project scaffold, page object, test case, and run-result content [Default — not specified by user].
• Storage: file-system-backed project content for scaffold, page objects, and test cases; run results held for the most recent run [Default — not specified by user].
• Containerization: Docker and docker-compose for a reproducible environment in which the suite and its browser dependencies run [Default — not specified by user].

11. Assumptions and Constraints

Assumptions.

• A-1: The target web application under test exists and is reachable by the suite; it is owned externally and is not modified by this project. (Assumption — the authoritative thread names web automation testing but does not name a specific target application.)
• A-2: The Test Automation Engineer has a working Python environment available, or can create one, as a prerequisite for running the suite. (required_inference)
• A-3: The suite runs against a single target web application per project configuration. (Assumption — not specified by the user.)
• A-4: The frontend presentation layer, backend service layer, storage, and containerization choices are defaults, not user-specified requirements, and may be substituted without changing accepted product behavior. (Default — not specified by user.)

Constraints.

• C-1: The implementation language must be Python. (explicit)
• C-2: Browser automation must use Playwright. (explicit)
• C-3: The test framework must be pytest. (explicit)
• C-4: Code organization must follow the Page Object Model structure. (explicit)
• C-5: No blue or indigo accent may be used; the palette is ink, acid green, and coral only, with no gradients. (explicit, from the creative direction)
• C-6: Headings and body must use Space Grotesk and IBM Plex Mono respectively; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are excluded. (explicit, from the creative direction)
• C-7: Radii above 2px, soft shadows, pill buttons, and decorative illustration or stock photography are excluded. (explicit, from the creative direction)
• C-8: Code panels are monochrome with green/coral semantic marks only; rainbow syntax highlighting is excluded. (explicit, from the creative direction)
• C-9: Marquees, tickers, and bouncy or springy motion are excluded; the cursor sweep is the only continuous loop. (explicit, from the creative direction)
• C-10: Readable text and controls must not be cropped, clipped, covered, or run off an edge at any viewport. (explicit, from the creative direction)

12. Glossary

• Page Object Model (POM): A code organization pattern in which each target page or region is represented by a class that encapsulates that page's locators and actions, separate from the tests that use them.
• Page Object: A class that encapsulates the locators and actions for a target page or region of the web application under test.
• Locator: An identifier used by Playwright to find an element on a target page.
• Page Action: An operation a page object exposes for tests to call, such as a click, a fill, or a navigation.
• Test Case: A pytest test function that exercises a web workflow through page objects and asserts an expected outcome.
• Test Run: A single execution of the suite, producing per-test pass or fail outcomes and a run summary.
• Run Summary: The pytest report of a run, showing counts of passed and failed tests.
• Target Web Application: The externally owned web application that the automation suite drives through Playwright.
• Test Automation Engineer: The sole accepted active human persona; builds and maintains the Python Playwright and pytest suite in Page Object Model structure.
• Scaffold: The runnable Python project structure, dependency declaration, pytest configuration, and Playwright browser setup that make the suite executable.