System Requirements Document for qa-automation

1. Introduction

qa-automation is a QA automation testing tool. It exists so that a self-starting QA Automation Engineer can author automated test cases and suites, execute automated test runs, and inspect the pass/fail outcomes of those runs — without depending on a separate team, invitation, or provisioning process to get started.

The product's intent is narrow and deliberate: it is a working console for automating and running software tests. Its audience is the QA Automation Engineer — a power user who lives in dense interfaces, reads status codes, durations, pass counts and flake rates as first-class content, and judges a tool by whether it respects their keyboard and their eyes at 2am. The product is not a marketing site, a project-management suite, or a collaboration platform; it is the surface where tests are written, run, and read.

2. System Overview

qa-automation is delivered as a first-party web application with custom UI and application-owned identity. A QA Automation Engineer reaches an anonymous Landing surface that explains the tool's purpose, then either completes self-service enrollment on Sign Up or performs returning verification on Login. Once identity is established, the engineer works across three authenticated surfaces: Tests (browse and manage recurring automated test cases and suites), Test Editor (a focused workspace for authoring and editing a test case or suite), and Runs (execute automated test runs and review their pass/fail results).

The single accepted active human actor is the QA Automation Engineer. There are no other accepted human personas, and no differentiated permissions or role-based visibility are established — every authenticated surface is owned by the same actor for the same body of work.

Current delivery covers: anonymous product entry, self-service enrollment, returning verification, test/suite browsing and management, test authoring and editing, run execution, and pass/fail result review. Explicitly out of current scope: any capability not named above — including but not limited to team collaboration, role administration, invitation or provisioning flows, provider-owned identity, and any future-horizon work. Nothing in this document authorizes adjacent capabilities by category or convention.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is a first-party application with custom UI. All six surfaces — Landing, Login, Sign Up, Tests, Test Editor, Runs — are application-owned. No provider surface, external destination, or headless delivery is established by the source, and none is introduced here.

Access ownership. Identity is application-owned. The QA Automation Engineer is self-starting: no invitation, provisioning, provider, or pre-existing-account boundary is established, so enrollment is self-service. Landing, Login, and Sign Up are anonymously reachable — a protected destination cannot own the interaction that establishes access to itself, so the enrollment and verification interactions live on their own anonymous surfaces. Tests, Test Editor, and Runs require an established identity, because authored tests, suites, runs, and results are durable actor-specific state that must remain bound to the correct engineer and be resumable across sessions.

Current vs. future. Everything described in this document is current. No future-horizon requirements were accepted; the future section is therefore empty by source, not by omission.

Exclusions. No differentiated permissions, role-based visibility, or permission controls are established. No account-management capabilities beyond first-use enrollment and returning verification are accepted. No collaboration, sharing, commenting, or multi-actor workflow is accepted.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Full-bleed graphite field with a 1px grid at 5% opacity. Left column (grid columns 1–7) carries an oversized Space Grotesk headline set flush-left, broken across three lines so the last line runs longer than the first, with a single tangerine word inside it. Directly beneath, pinned to the baseline of the headline block, sits the primary CTA and a mono subline stating the product's live claim in tabular figures. Right side (columns 8–12) is a real, slightly rotated run-report panel — sparkline, mono duration column, green pass pills — bleeding off the right viewport edge at desktop and dropping below the headline on mobile. No centred stack, no sub-headline paragraph, no gradient.
• Primary actions. Proceed to Sign Up (primary CTA, tangerine). Proceed to Login (secondary, text-level).
• Supporting actions. None beyond the two access entries.
• Domain entities. None persisted; the run-report panel is a rendered representation of run output, not live data.
• Component responsibilities. Hero headline block; baseline-pinned CTA cluster; mono claim subline; rotated run-report panel with sparkline, duration column and pass pills; 1px grid field background; abstract flake map of scattered dots.
• States. Loading: none (static entry). Empty: not applicable. Success: engineer selects an access path. Error: not applicable. Recovery: not applicable.

Login

• Information and state. Anonymous returning-verification surface. Centred 420px column on the graphite ground; brand mark sits at the top-left of the viewport rather than above the form. Fields for the engineer's credentials.
• Primary actions. Submit credentials to establish a session and resume access to tests, suites, runs, and results.
• Supporting actions. Navigate to Sign Up if the engineer has no account.
• Domain entities. Engineer identity (email/identifier, credential).
• Component responsibilities. Credential form; submit control; inline validation messaging; link to Sign Up.
• States. Loading: submit control in pending state during verification. Empty: blank fields with labels. Success: session established; engineer is taken to the authenticated work area. Error: invalid credentials shown inline without clearing entered identifier. Recovery: engineer corrects the field and resubmits; the path to Sign Up remains available.

Sign Up

• Information and state. Anonymous self-service enrollment surface. Same 420px centred column and top-left brand mark as Login.
• Primary actions. Submit enrollment details to create the engineer's account and establish a session.
• Supporting actions. Navigate to Login if the engineer already has an account.
• Domain entities. Engineer identity (identifier, credential, display name).
• Component responsibilities. Enrollment form; submit control; inline validation messaging; link to Login.
• States. Loading: submit control in pending state during account creation. Empty: blank fields with labels. Success: account created and session established; engineer lands in the authenticated work area with no tests yet. Error: validation or duplicate-identity failure shown inline. Recovery: engineer corrects the field and resubmits; the path to Login remains available.

Tests

• Information and state. Authenticated browse-and-manage surface for recurring automated test cases and suites. Dense hairline-skeleton table: 44px rows, 1px dividers, no shadows, no hover-lift. Right-aligned JetBrains Mono tabular numerals in their own columns. Persistent 40px top status bar carrying environment, branch and last-run time in mono. Persistent 56px left rail (icon + label, collapsed to icons under 768px).
• Primary actions. Create a new test case or suite (opens Test Editor). Open an existing test case or suite in Test Editor.
• Supporting actions. Search or filter the list; delete a test case or suite; navigate to Runs.
• Domain entities. Test case, test suite, suite membership, last-run status, last-run duration.
• Component responsibilities. Test/suite table with hairline dividers; row action cluster revealed on hover (row background shifts 4%); create control; search/filter control; top status bar; left rail.
• States. Loading: table skeleton with hairline rows. Empty: no tests yet — a single prompt to create the first test, with the create control as the only emphasized action. Success: rows render with name, suite, last-run status pill and mono duration. Error: list retrieval failure shown as an inline retryable message in the table region. Recovery: retry the retrieval; the create control remains available.

Test Editor

• Information and state. Authenticated focused workspace for authoring and editing a single test case or suite. Dense, keyboard-first layout on the same grid. The live cursor position in the editor is the one tangerine element on this screen. Test code is rendered as real UI with syntax colouring, not as a screenshot.
• Primary actions. Save the authored or edited test case or suite.
• Supporting actions. Edit test code; define suite membership; discard changes; return to Tests.
• Domain entities. Test case, test suite, test code body, suite membership.
• Component responsibilities. Code editing region with syntax colouring; save control; discard control; suite membership control; validation messaging; top status bar; left rail.
• States. Loading: editor region in a pending state while the test is retrieved. Empty: new test with an empty code body and a placeholder prompt. Success: save confirms and the test appears or updates in Tests. Error: validation failure (for example, an empty or malformed test body) shown inline against the offending region. Recovery: engineer corrects the body and saves again; unsaved changes are not silently discarded.

Runs

• Information and state. Authenticated surface for executing automated test runs and reviewing pass/fail results. Dense hairline-skeleton table of runs: 44px rows, 1px dividers, right-aligned mono numerals for run IDs, durations and pass counts. The 40px top status bar carries environment, branch and last-run time in mono. The one expressive moment in the product lives here: a 1px tangerine progress rule sweeping the full width of the active run row while a mono counter ticks upward, snapping to acid green on pass or desaturated coral on fail.
• Primary actions. Execute a run for a selected test case or suite.
• Supporting actions. Open a completed run's result detail; filter runs by status; navigate to Tests.
• Domain entities. Run, run status (running / passed / failed), run duration, pass count, fail count, per-test result, failure output.
• Component responsibilities. Run table with hairline dividers; run trigger control; active-run progress rule and mono counter; status pills at 2px radius; sparkline arc (40px) inside run rows; result detail region; top status bar; left rail.
• States. Loading: run table skeleton; active run row shows the sweeping progress rule and ticking counter. Empty: no runs yet — a prompt to execute the first run. Success: run completes; the row snaps to acid green or coral; pass/fail counts and duration render in mono. Error: a run that fails to execute shows a coral status with the failure output available in the result detail. Recovery: the engineer can re-execute the run; previously completed runs remain readable.

3. Functional Requirements

FR-1 — Anonymous product entry (explicit) As a QA Automation Engineer, I should be able to reach an anonymous Landing surface that explains what the QA automation testing tool does, so that I can decide whether to start.

• Trigger/input: the engineer opens the product without an established session.
• Observable result: the Landing surface renders with the product's purpose, a primary CTA to Sign Up, and a secondary path to Login.
• Access state: anonymous; no identity required.
• Failure/recovery: not applicable to a static entry.
• Continuation: the engineer proceeds to Sign Up or Login.

FR-2 — Self-service enrollment (required_inference) As a QA Automation Engineer, I should be able to complete self-service enrollment on Sign Up before creating or managing automated tests or suites, so that my authored work is bound to me and resumable.

• Trigger/input: the engineer submits enrollment details on Sign Up.
• Observable result: an account is created and a session is established; the engineer reaches the authenticated work area with no tests yet.
• Access state: anonymous entry on Sign Up; protected state remains unavailable until identity is established.
• Failure/recovery: validation or duplicate-identity failure is shown inline; the engineer corrects the field and resubmits, and the path to Login remains available.
• Continuation: the engineer creates their first test case or suite.

FR-3 — Returning verification (required_inference) As a QA Automation Engineer, I should be able to use returning verification on Login to resume access to my tests, suites, automated runs, and results.

• Trigger/input: the engineer submits credentials on Login.
• Observable result: a session is established and the engineer's previously authored tests, suites, runs, and results are available again.
• Access state: anonymous entry on Login; protected state remains unavailable until verification succeeds.
• Failure/recovery: invalid credentials are shown inline without clearing the entered identifier; the engineer corrects and resubmits, and the path to Sign Up remains available.
• Continuation: the engineer resumes work in Tests, Test Editor, or Runs.

FR-4 — Browse and manage tests and suites (required_inference) As a QA Automation Engineer, I should be able to browse and manage my recurring automated test cases and suites on Tests, so that I can see what exists and act on it.

• Trigger/input: the engineer opens Tests with an established session.
• Observable result: a dense hairline-skeleton table renders test cases and suites with name, suite, last-run status pill and mono duration; search and filter narrow the list; delete removes an entry.
• Access state: requires an established identity.
• Failure/recovery: a list retrieval failure shows an inline retryable message in the table region; retry restores the list, and the create control remains available.
• Continuation: the engineer opens an entry in Test Editor or creates a new one.

FR-5 — Author and edit a test case or suite (required_inference) As a QA Automation Engineer, I should be able to author and edit a test case or suite in the focused Test Editor workspace, so that I can build and refine my automated tests.

• Trigger/input: the engineer opens Test Editor from Tests or via the create control, and edits the test code body or suite membership.
• Observable result: the edited test case or suite is saved and appears or updates in Tests.
• Access state: requires an established identity.
• Failure/recovery: validation failure (for example, an empty or malformed test body) is shown inline against the offending region; the engineer corrects the body and saves again, and unsaved changes are not silently discarded.
• Continuation: the engineer returns to Tests or proceeds to execute a run.

FR-6 — Execute an automated test run (required_inference) As a QA Automation Engineer, I should be able to execute an automated test run for a selected test case or suite on Runs, so that I can verify my tests against the software under test.

• Trigger/input: the engineer triggers a run for a selected test case or suite.
• Observable result: the active run row shows a 1px tangerine progress rule sweeping its full width while a mono counter ticks upward; on completion the row snaps to acid green (pass) or desaturated coral (fail).
• Access state: requires an established identity.
• Failure/recovery: a run that fails to execute shows a coral status with the failure output available in the result detail; the engineer can re-execute the run, and previously completed runs remain readable.
• Continuation: the engineer reviews the run's results.

FR-7 — Review pass/fail results (required_inference) As a QA Automation Engineer, I should be able to review the pass/fail results of an automated run on Runs, so that I can judge whether the software under test is behaving correctly.

• Trigger/input: the engineer opens a completed run's result detail.
• Observable result: run status, duration, pass count, fail count, per-test results and failure output render with right-aligned mono tabular numerals and status pills.
• Access state: requires an established identity.
• Failure/recovery: if result detail cannot be retrieved, an inline retryable message appears; retry restores the detail, and the run list remains readable.
• Continuation: the engineer returns to Tests or Test Editor to act on a failure.

4. User Personas

QA Automation Engineer

Product context. The QA Automation Engineer is the sole accepted active human actor for qa-automation. They are a power user of developer tooling: they live in dense interfaces, read status codes and durations the way designers read type, and judge a tool by whether it respects their keyboard and their eyes at 2am. They are self-starting — no invitation, provisioning, or pre-existing-account boundary is established for them, so they enroll themselves.

Primary goal. To automate and run software tests: to author automated test cases and suites, execute automated test runs, and inspect the pass/fail outcomes of those runs.

Distinct accepted responsibilities. The engineer owns the full lifecycle of their own automated testing work: enrolling themselves (FR-2), verifying their identity to resume (FR-3), browsing and managing their test cases and suites (FR-4), authoring and editing test code and suite membership (FR-5), executing runs (FR-6), and reviewing pass/fail results and failure output (FR-7). These are recurring responsibilities, not one-off tasks — the engineer returns to the same body of tests, suites, runs, and results across sessions.

Relevant inputs and decisions. The engineer supplies enrollment details and credentials; test code bodies and suite membership; the selection of which test case or suite to run; and the judgment of whether a pass/fail outcome is acceptable. Their central decision is whether a failing result requires a change to the test or to the software under test.

Interactions with other accepted participants. None. The QA Automation Engineer is the only accepted active human persona. There is no collaboration, sharing, commenting, or multi-actor workflow in current scope, and no differentiated permissions or role-based visibility are established.

Observable success. Automated test suites can be created, run, and their pass/fail outcomes inspected. Concretely: the engineer can enroll, author a test, execute it, and read a green pass or coral fail with duration and counts in mono tabular figures — and can return later to the same tests, suites, runs, and results.

Source-backed constraints. The engineer's work is keyboard-first and density-tolerant; the interface is judged on precision and speed rather than on decoration. No demographic, biographical, or permission attributes are established by the source.

5. Core User Flows

Flow A — First-time enrollment and first test

1. The QA Automation Engineer opens qa-automation with no established session and lands on Landing. The surface explains the tool's purpose and presents the primary CTA to Sign Up and a secondary path to Login.
2. The engineer selects the primary CTA and arrives at Sign Up, an anonymous surface with a 420px centred form and the brand mark at the top-left of the viewport.
3. The engineer enters enrollment details and submits. The submit control enters a pending state while the account is created.
4. Observable result: the account is created and a session is established. The engineer reaches the authenticated work area with no tests yet.
5. Failure/recovery: if validation fails or the identity already exists, the error is shown inline; the engineer corrects the field and resubmits. The path to Login remains available if they realize they already have an account.
6. The engineer opens Tests. The table is empty and shows a single prompt to create the first test, with the create control as the only emphasized action.
7. The engineer selects create and arrives at Test Editor, a new test with an empty code body and a placeholder prompt.
8. The engineer writes the test code body and defines suite membership. The live cursor position in the editor is the one tangerine element on the screen.
9. The engineer saves. Observable result: the save confirms and the test appears in Tests with its name, suite, and last-run status.
10. Failure/recovery: if the body is empty or malformed, validation is shown inline against the offending region; the engineer corrects it and saves again. Unsaved changes are not silently discarded.
11. Next step: the engineer proceeds to execute a run (Flow C).

Flow B — Returning verification and resuming work

1. The QA Automation Engineer opens qa-automation with no established session and lands on Landing.
2. The engineer selects the secondary path to Login, an anonymous surface with a 420px centred form and the brand mark at the top-left of the viewport.
3. The engineer enters their identifier and credential and submits. The submit control enters a pending state during verification.
4. Observable result: a session is established and the engineer's previously authored tests, suites, runs, and results are available again.
5. Failure/recovery: invalid credentials are shown inline without clearing the entered identifier; the engineer corrects and resubmits. The path to Sign Up remains available.
6. The engineer opens Tests and sees their existing test cases and suites in the dense hairline-skeleton table, with last-run status pills and mono durations.
7. Next step: the engineer opens an entry in Test Editor to refine it, or proceeds to Runs to execute or review.

Flow C — Executing a run and reviewing results

1. The QA Automation Engineer, with an established session, opens Runs. The 40px top status bar shows environment, branch and last-run time in mono.
2. The engineer selects a test case or suite and triggers a run.
3. Observable result: the active run row shows a 1px tangerine progress rule sweeping its full width while a mono counter ticks upward. Under prefers-reduced-motion the progress rule becomes a static filled bar and the counter updates without transition.
4. On completion the row snaps to acid green (pass) or desaturated coral (fail). Pass counts, fail counts and duration render right-aligned in JetBrains Mono with tabular figures.
5. Failure/recovery: if the run fails to execute, the row shows a coral status and the failure output is available in the result detail. The engineer can re-execute the run; previously completed runs remain readable.
6. The engineer opens the completed run's result detail and reviews per-test results and failure output.
7. Failure/recovery: if result detail cannot be retrieved, an inline retryable message appears; retry restores the detail, and the run list remains readable.
8. Next step: if a test failed, the engineer returns to Test Editor to correct the test, or to Tests to manage the suite. If all tests passed, the engineer returns to Tests to continue authoring.

Flow D — Managing an existing test or suite

1. The QA Automation Engineer, with an established session, opens Tests.
2. The engineer searches or filters the list to locate a test case or suite. Rows are 44px with hairline dividers; hovering a row shifts its background by 4% and reveals a right-edge action cluster.
3. The engineer opens the entry in Test Editor.
4. The engineer edits the test code body or suite membership. The live cursor position is the one tangerine element on the screen.
5. The engineer saves. Observable result: the change is confirmed and the entry updates in Tests.
6. Failure/recovery: if validation fails, it is shown inline against the offending region; the engineer corrects it and saves again. Unsaved changes are not silently discarded.
7. Alternatively, the engineer deletes the entry from the row action cluster. Observable result: the entry is removed from the list.
8. Next step: the engineer proceeds to Runs to execute the updated test, or continues managing other entries.

6. Visuals, Colors and Theme

Muse and headline. Systematic product craft after Rasmus Andersson — a QA console with graphite ground, tangerine signal and editorial numerals. The muse is a tool-builder's language: warm paper or deep graphite ground, one hot non-blue accent, tabular numerals used as ornament, hairline borders, keyboard-first density. QA automation is a power-user surface where pass/fail counts, run durations and flake rates are the content — so making numerals the visual signature is both characteristic of the muse and genuinely functional.

Colour tokens — dark mode

Typography

• Headings: Space Grotesk 500/600 at tight tracking (−0.03em), set oversized and flush-left. The landing hero uses weight 500 at display scale so it reads as engineered signage rather than advertising.
• UI labels and eyebrows: Inter Tight 600, uppercase, +0.08em tracking, 11–12px.
• Numeric data: JetBrains Mono with tabular figures — run IDs, durations, pass counts, coverage %. Never proportional.
• Body: Inter Tight.
• Scale: 1.333 modular, mobile→desktop via clamp(): display 44→104px, h1 32→56px, h2 24→36px, h3 18→24px, body 15→17px, label 11→12px, mono data 13→15px.
• Line-height: 1.02 for display, 1.5 for body, 1.2 for data rows.

Shape language

Compact and machined: 6px radius on controls, 10px on panels, 2px on tags and status pills so they read as printed labels rather than candy. Hairline 1px borders (#2A2D31) do all the separation work; there are no drop shadows anywhere. Vertical rules and 1px horizontal row dividers form a visible skeleton, and the only curved element on the page is the 40px sparkline arc inside run rows.

Layout

A 12-column grid on a strict 4/8-pt spacing scale, with a persistent 56px left rail (icon + label, collapsed to icons under 768px) and a 40px top status bar showing environment, branch and last run. Content sits in dense rows, not cards: the Tests and Runs tables use 44px row height, right-aligned mono numerals, and hairline dividers rather than alternating fills. Marketing pages keep the same grid but let one column run 9 wide for oversized type. Everything is flush-left ragged-right; nothing is centred except the auth forms, which sit in a 420px column on the graphite ground with the brand mark at the top-left of the viewport rather than above the form.

Imagery

The interface is the imagery: real test-code blocks, run logs with syntax colouring, diff views, sparklines and coverage heat strips rendered as actual UI rather than screenshots. Decorative graphics are schematic — a 1px grid field, node-graph diagrams of test suites, and a single abstract "flake map" of scattered dots on the landing page. No stock photography, no 3D renders, no gradient blobs, no illustrated people.

Forbidden

Blue or indigo primaries on white — no #0057FF, #2563EB, #4F46E5 or neighbours anywhere, including focus rings and link colours. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui as heading or body families. Centred SaaS hero with headline, sub-paragraph, blue button and gradient blob. A grid of identical hover-lift cards with soft drop shadows. Gradient meshes, glassmorphism, frosted panels or blurred colour blobs. Illustrated people, mascots or stock photography of "teams collaborating". Rounded-pill everything: pills are reserved for status tags only, at 2px radius. Decorative motion longer than 200ms, bounce easing, or parallax scroll effects.

7. Signature Design Concept

The landing hero is a run report, not a pitch.

The public entry is a full-bleed graphite field (#141517) with a 1px grid at 5% opacity. The left column (grid columns 1–7) holds an oversized Space Grotesk headline set flush-left at 44px mobile → 104px desktop, broken across three lines so the last line runs longer than the first, with a single tangerine word (#FF6A2B) inside it. Directly beneath, pinned to the baseline of the headline block rather than centred under a sub-paragraph, sits the primary CTA and a mono subline reading the product's live claim in tabular figures.

The right side (columns 8–12) is not an illustration: it is a real, slightly rotated run-report panel — sparkline, mono duration column, green pass pills — bleeding off the right edge of the viewport at desktop and dropping below the headline on mobile. No centred stack, no sub-headline paragraph, no gradient.

The concept recomposes only accepted content and controls: the headline states the product's purpose, the CTA is the accepted path to Sign Up, the secondary path to Login sits alongside it, and the run-report panel renders the product's defining state — a completed run with pass pills and durations. Nothing on this surface introduces a new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The rotated run-report panel on the right (columns 8–12): sparkline, mono duration column, green pass pills, bleeding off the right viewport edge at desktop and dropping below the headline on mobile.
• Input → transformation → outcome thesis. On first paint of the route, the hero performs a single 200ms fade-and-4px-rise; the sparkline inside the run-report panel draws its path over 400ms on mount. The outcome is a composed first frame in which the product's defining state — a completed run with pass pills and durations — is legible immediately, with no entrance choreography beyond that single fade-and-rise.
• Motion vocabulary. Fast and functional: 140ms cubic-bezier(0.2, 0, 0, 1) on hover, focus and state colour changes. No bounce, no float, no parallax. The one expressive moment in the product is reserved for the live run on Runs: a 1px tangerine progress rule that sweeps the full width of the run row while a mono counter ticks upward, then snaps to acid green or coral on completion.
• Composed first frame. Graphite field with 1px grid at 5% opacity; oversized flush-left Space Grotesk headline with one tangerine word; CTA and mono claim subline pinned to the headline baseline; rotated run-report panel bleeding off the right edge with its sparkline already drawn.
• Reduced-motion state. Under prefers-reduced-motion, the hero renders as a static composed frame with no fade-and-rise and no sparkline draw; on Runs, the progress rule becomes a static filled bar and the counter updates without transition.

9. Non-Functional Requirements

NFR-1 — Keyboard-first density (explicit, from creative direction) The authenticated surfaces must be operable keyboard-first, with dense 44px rows and hairline dividers rather than card layouts. Rationale: the accepted audience is a power user who judges the tool by whether it respects their keyboard.

NFR-2 — Numeric legibility (explicit, from creative direction) All numeric data — run IDs, durations, pass counts, coverage percentages — must be set in JetBrains Mono with tabular figures and right-aligned in their own column. Rationale: numerals are the product's content and its visual signature; proportional figures would break the vertical rhythm the interface depends on.

NFR-3 — Status colour separation (explicit, from creative direction) Running state (tangerine #FF6A2B) and failed state (desaturated coral #E5484D) must remain visually distinct at all times. Rationale: confusing "running" with "failed" is a correctness failure in a QA tool.

NFR-4 — Reduced-motion support (explicit, from creative direction) Under prefers-reduced-motion, the live-run progress rule must become a static filled bar and the counter must update without transition; the hero must render as a static composed frame. Rationale: the direction specifies a usable static arrangement for reduced motion.

NFR-5 — Readable text and controls stay whole (explicit, from creative direction) Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, as long as they cover no readable text or control. Rationale: the direction states this rule takes precedence for readable text and controls.

NFR-6 — No drop shadows (explicit, from creative direction) Hairline 1px borders (#2A2D31) do all separation work; there are no drop shadows anywhere, and hover changes only the row's background by 4%. Rationale: the shape language is machined and flat by design.

NFR-7 — Session continuity (required_inference) An established session must persist the engineer's authored tests, suites, runs, and results so that returning verification resumes the same body of work. Rationale: authored work is durable actor-specific state that must remain bound to the correct engineer.

NFR-8 — No differentiated permissions (explicit, from planning scope) No role-based visibility, permission controls, or differentiated access over shared product state are established. Every authenticated surface is owned by the same actor for the same body of work. Rationale: the source establishes a single active human persona with no differentiated control.

10. Tech Stack

• Frontend: React (web application with custom UI).
• Backend: Python / FastAPI.
• Storage: appropriate persistent storage for engineer identity, test cases, test suites, suite membership, runs, and per-test results.
• Containerization: Docker / docker-compose for local and deployment packaging.
• Orchestration: Kubernetes only if deployment requires it.

No source-specified technology choices were provided beyond the product's nature as a QA automation testing tool; the above are the minimal stack items needed to deliver the accepted behavior.

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference) — The QA Automation Engineer is self-starting: no invitation, provisioning, provider, or pre-existing-account boundary is established, so enrollment is self-service on Sign Up.
• A-2 (required_inference) — Authored tests, suites, runs, and results are durable actor-specific state that must remain bound to the correct engineer and be resumable across sessions; this is why Tests, Test Editor, and Runs require an established identity.
• A-3 (required_inference) — Landing, Login, and Sign Up are anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself.
• A-4 (basic_default) — The run-report panel on Landing is a rendered representation of run output, not live data.

Constraints

• C-1 (explicit) — The product is a QA automation testing tool. No adjacent capabilities are authorized by category or convention.
• C-2 (explicit) — The active human persona catalog is closed at exactly one persona: the QA Automation Engineer. No additional personas may be added.
• C-3 (explicit) — The page contract is closed and ordered: Landing, Login, Sign Up, Tests, Test Editor, Runs. No page may be added, removed, merged, split, renamed, reordered, or have its access changed.
• C-4 (explicit) — Landing, Login, and Sign Up have no access requirement; Tests, Test Editor, and Runs require login.
• C-5 (explicit) — No differentiated permissions, role-based visibility, or permission controls are established.
• C-6 (explicit) — The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-7 (explicit) — The forbidden list in Section 6 is binding: no blue/indigo primaries, no forbidden font families, no centred SaaS hero, no hover-lift card grids, no gradient meshes or glassmorphism, no illustrated people or stock photography, no rounded-pill everything, no decorative motion longer than 200ms, no bounce easing, no parallax.

12. Glossary

• QA Automation Engineer — The sole accepted active human persona; the self-starting user who authors, executes, and reviews automated tests.
• Test case — A single automated test authored by the engineer in Test Editor.
• Test suite — A named collection of test cases with defined membership.
• Run — A single execution of a test case or suite, with a status (running / passed / failed), duration, pass count, fail count, and per-test results.
• Pass state — A completed run in which all tests passed; rendered in acid green (#C6F24E).
• Fail state — A completed run in which one or more tests failed; rendered in desaturated coral (#E5484D).
• Flake rate — The proportion of runs in which a test's outcome changes without a corresponding change to the test or the software under test.
• Self-service enrollment — First-use identity establishment on Sign Up, with no invitation or provisioning.
• Returning verification — Identity verification on Login that resumes access to previously authored tests, suites, runs, and results.
• Tabular figures — Numeric glyphs of uniform width, set in JetBrains Mono, so digits align vertically down a column.
• Hairline skeleton — The interface's separation system: 1px borders and row dividers instead of shadows or alternating fills.
• Top status bar — The persistent 40px bar on authenticated surfaces carrying environment, branch and last-run time in mono.
• Left rail — The persistent 56px navigation rail (icon + label, collapsed to icons under 768px).