Build a Production-Grade Learning Platform Automation Framework

1. Layered scaffold and configuration

Scenario: you are building a real, local, reusable automation framework intended to back a growing test suite for a demo web app -- entirely on your own machine. Scaffold a TypeScript + Playwright project with separate src/config, src/fixtures, src/data, src/pages, and src/services folders. Implement environment-aware configuration (reading BASE_URL and TEST_ENV from process.env with sensible defaults) and confirm no secret or credential is hardcoded anywhere in the repository.

• The project has the five separate, layer-based folders described above
• Configuration reads from environment variables with working defaults, confirmed by running the suite with two different BASE_URL values
• A repository-wide search confirms no hardcoded secret, password, or API key exists anywhere in the project

2. Test-data builders, fixtures, and page/component objects

Implement at least 2 test-data builder functions with sensible defaults and overridable inputs, each generating genuinely unique data per call. Compose at least one fixture that depends on another fixture (for example, an authenticated-page fixture built from a test-user fixture). Implement at least 2 page objects and 1 component object for a UI piece reused across multiple pages.

• At least 2 data builders exist, each guaranteeing unique output per call and supporting partial overrides
• At least one fixture composes another fixture (a real dependency chain, not two independent, unrelated fixtures)
• At least 2 page objects and 1 genuinely reused component object exist

3. Service clients and a DB-validation adapter interface

Implement at least one service client wrapping related API calls behind business-intent-named methods (not raw HTTP verbs). Design (but do not implement against a real database) a DbValidationAdapter interface -- method signatures, argument types, and return shapes only -- documented with comments explaining what each method would verify in a real deployment, and provide an in-memory mock implementation for use in the framework's own tests. This adapter must never contain a real connection string or credential.

• At least one service-client method exists, named for business intent, wrapping a raw request internally
• A DbValidationAdapter interface is fully designed and documented, with an in-memory mock implementation -- no real database connection exists anywhere in the project
• A repository-wide search confirms no real database credential, connection string, or Supabase reference exists anywhere in the project

4. Domain assertions, tagging, and reliability policy

Write at least one custom, domain-level assertion function with a purpose-built failure message. Apply a consistent tag scheme (at minimum @smoke and one feature-area tag) across the suite's tests. Configure a deliberate retry count (1-2, documented) and a timeout set with a comfortable margin above observed run times, and confirm the full suite passes reliably in parallel.

• At least one custom domain assertion exists, with a failure message naming the actual business condition checked
• Every test carries at least one tag from a documented, consistent tag scheme
• The suite passes reliably, in parallel, with a documented retry count of at most 2

5. CI quality gates, sharding, and framework health

Add a GitHub Actions workflow that shards the suite across at least 2 parallel jobs, uploads the HTML report and trace artifacts on failure, and would genuinely block a merge if configured as a required status check (documented in the README, since the branch-protection setting itself lives in repository settings, not this file). Write a README section covering setup, architecture (mirroring the five-layer structure), the tagging scheme, and a framework-health checklist (flaky-rate tracking, CI runtime trend, documentation currency).

• The CI workflow shards the suite across at least 2 parallel jobs using Playwright's --shard flag
• The workflow uploads the HTML report as an artifact specifically on failure
• The README documents setup, the five-layer architecture, the tagging scheme, and a framework-health checklist