Quality and testing
The suites that pin the product's behaviour, and the commands that run them. No internal results, only the layers and their purpose.
What it is
The repository carries several verification layers. The web workspace has guard scripts that reject mock data, unguarded project pages and broken front-door URLs, plus a Playwright end-to-end suite. The backend has a large set of verify guards and unit and route tests that pin allocator, configuration, proxy and route behaviour. Two lint scripts fail on tracked secret files and on shell usage that lacks a justification.
These are repository facts, not a quality score. The page lists the suites and the commands that run them so a reader can run the same checks and draw their own conclusion.
Why the layers are separate
A unit test can prove that the port formula returns 60000 for slot zero. It cannot prove that the browser reaches the project through the front door. An end-to-end test can prove that a flow works in a running stack, but it is slow and depends on Docker. Guards catch whole classes of regression cheaply. Keeping the layers distinct means a failure points at the layer that owns the behaviour.
Test suites by layer
Diagram: five layers run from web guard scripts through backend verify guards, unit and route tests, Playwright end-to-end tests and lint gates, with the commands that run them.
What is in each layer
Web guards. The web workspace runs JavaScript guard scripts for mock data, project-page API access and front-door URL handling, plus a guard against fabricated verification. They live in apps/web/tests.
Backend verify guards. The wrapper package contains a large family of verify-*.ts scripts. Each one exercises a behaviour against the running code and asserts the result. They are the closest thing to executable specification in the repository.
Unit and route tests. Files ending in .test.ts cover the allocator, the CLI configuration schema, proxy rules and route behaviour. They are fast and independent of Docker.
End-to-end. Playwright configuration files drive browser flows against a live stack.
Lint. The secret-file check and the shell-usage check fail the build rather than warning.
The verification loop
Diagram: a change is written, the narrowest layer runs, the output is inspected, a failure returns to the change, and a passing result is recorded with its evidence.
Running the checks
Install the workspaces
From my-supabase-app, run npm install. The monorepo installs both workspaces.
Run the web tests
npm test runs the web guard scripts and the Playwright configuration.
Run the lint gates
npm run lint runs the secret-file check and the shell-usage check.
Run a single guard
Execute the verify script for the behaviour you changed rather than the whole family.
Read the output
A green exit code is not the result. Read the assertions and the evidence the guard printed.
Failure and recovery
A guard that fails is information. The first step is to reproduce the failure and read the assertion, not to change the guard. A test that cannot run because Docker is unavailable is reported as not run, not as a pass. If a suite is slow or flaky, narrow it to the failing case and fix the case before widening the run again. A guard that depends on ambient state, such as a port that happens to be free or a stack that happens to be running, should make that dependency explicit; otherwise a green result says more about the machine than about the change.
Each layer also has a cost. The web guards and the unit tests run in seconds, the end-to-end suite needs Docker and a live stack, and the verify guards exercise real behaviour with real processes. Running the cheapest layer that can catch the mistake first keeps the loop short without pretending the other layers do not exist.
The verification loop assumes that a claim is only accepted after the code is run. That principle is why this site's own builder fails on a missing gate instead of printing a warning and continuing.