Build a CI test pipeline

CI should reject broken changes quickly and retain enough evidence to diagnose slower failures.

Run formatting, types, and unit tests first. Cache dependencies safely, then run integration and browser jobs. Upload reports and traces only when useful, pin tool and service versions, and cancel superseded runs on the same branch.

Design the pipeline as evidence stages:

1. Static checks catch formatting, type, and import failures without starting services.
2. Unit tests catch deterministic domain regressions in seconds.
3. Integration tests start pinned databases and prove adapters, migrations, and HTTP contracts.
4. Browser tests prove a small set of critical journeys in the built application.
5. Performance smoke tests run only in a controlled environment with explicit thresholds.

Fast feedback does not require one serial job. Static and unit checks can run together if both are cheap. Slower jobs can start after their required artifact exists and run in parallel when they use isolated services. Make readiness explicit; “the process started” is weaker than “the health endpoint answers and the database accepts connections.”

Give every job a timeout and a distinct failure story. A product assertion, dependency-install failure, unavailable container runtime, and server-readiness timeout need different evidence. Retain unit reports, service logs, and Playwright traces on failure. Do not upload large artifacts from every green run unless they serve a real audit need.

Pin runtime and service versions, but update them deliberately. Cache packages by the dependency manifest rather than a broad branch name. Cancel superseded runs for the same branch so old browser jobs do not consume capacity or publish stale results.

Write a pipeline outline for the Books app with commands, required services, readiness checks, timeouts, and retained artifacts. For every job, state whether a failure means the product is wrong or the test environment is unavailable, and what evidence lets you tell.