Don’t take our word for how this is built

These values are injected by the build platform from the commit that triggered the deployment. They are not editable into agreement with anything else on this page, which is the reason to publish them: a commit hash beside a build time is a check on every other number here.

Commit

9f3030d

Branch

main

Environment

production

Compiled

2026-08-19 05:44 UTC

Commit message: docs: record Search Console Domain property verification and the load-bearing apex TXT record

Read from the verify script in package.json, in the order they run. Each one’s purpose is taken from the first paragraph of its own header comment, so a guard whose job changes updates this page by being edited. The same chain runs as prebuild: there is no way to produce a deployment that skipped it.

1. 01

   typecheck

   The TypeScript compiler over the whole project, with no emit.

2. 02

   verify:pricing

   Proves the numbers on /pricing rather than trusting them.

3. 03

   check:margin

   Fails the build if the two pricing engines disagree about the margin floor.

4. 04

   check:cutlist

   Fails the build if the two pricing engines disagree about the cut-size allowances.

5. 05

   check:cpq-parity

   Holds the browser engine against fixtures/cut-list-parity.json.

6. 06

   check:client

   Fails the build if any page or component constructs a Supabase client in its module body.

7. 07

   check:secrets

   Two rules about every module in this repo that reads a credential from the environment, enforced before every build.

8. 08

   check:health-honesty

   Fails when /api/health can report health it did not measure.

9. 09

   check:proof

   Fails the build if lib/customer-proof.ts publishes a customer quotation whose permission artifact is not committed to this repository.

10. 10

    check:claims

    Fails the build when a published claim is stated as a literal in a file that does not own it, or when a claim this project has already retired comes back.

11. 11

    check:corrections

    Fails the build when the corrections record points at something that is not there.

12. 12

    check:engineering

    Fails the build when /security#engineering describes engineering practice this repository no longer follows.

13. 13

    check:hosts

    Fails when next.config.mjs and lib/constants.ts disagree about the domain.

14. 14

    check:api-reference

    Fails when the marketing surface documents an API the server does not serve.

15. 15

    check:diagram

    Fails the build if any docs/<name>.png was rendered from a different docs/<name>.mmd than the one currently checked in, if any diagram source states a perishable status, or if any published copy under public/ has drifted from the file in docs/.

16. 16

    check:logo

    Generates public/logo.png — the organization logo that Google reads out of the Organization JSON-LD on every page, and the only raster form of the brand mark this repository ships.

17. 17

    check:schema

    Concatenates the real migrations into public/schema.sql, and fails the build if the published file has drifted from them.

18. 18

    check:coverage

    Runs the backend test suite with coverage and publishes the result as public/coverage.json, and fails the build if the published result no longer describes the code that is checked in.

19. 19

    check:pipeline

    Publishes the CI workflows as fetchable artifacts, and fails the build if the published copies have drifted from .github/workflows.

20. 20

    check:evidence-tracing

    Fails when a route that reads an artifact off disk can render somewhere the artifact will not be.

21. 21

    check:nav

    Fails when a destination in the header navigation is not an anchor in the header's markup.

22. 22

    check:phone

    The published telephone number has to be one number, in two notations, and it has to be a number a caller can actually reach.

23. 23

    check:canonical

    Fails when a route ships no canonical URL, or ships one that contradicts the sitemap.

24. 24

    check:links

    Link audit — does every href on this site go where it says it goes?

25. 25

    check:social

    Does the profile we link to actually belong to us?

4 migrations, 15 tables, 4 row-level security policies and 35 check constraints. CI applies all of them to an empty Postgres 16 on every push, then applies them again over the previously deployed set and diffs the two resulting schemas — because a migration that succeeds by both routes and leaves two different schemas behind is the failure that reaches production.

The counts above are a summary of something you can read. Open the full migration history — every create table, every policy and every constraint, in the order Postgres applies them, generated from the migration files rather than written alongside them.

The margin floor is a constraint, not a variable

The most reasonable objection to a 50% manufactured-goods margin floor enforced in a pricing engine is that it is a number in a JavaScript file, and anything that writes to the database directly can ignore it. It cannot. Below is the SQL, extracted from the migration that ships it — a row violating either constraint is rejected by Postgres before any application code is involved.

• margin_rules_at_or_above_code_floor0003_commercial_schema

  check ("min_margin" >= 0.50 and "min_margin" <= 0.9999)

• quotes_applied_margin_floor_range0003_commercial_schema

  check ("applied_margin_floor" is null or ("applied_margin_floor" >= 0.50 and "applied_margin_floor" <= 0.9999))

A separate CI job stands up Postgres, applies every migration, and then attacks the isolation from two directions: once against the policies directly over a raw connection, and once through the application’s own query path, because a database that would refuse a cross-tenant read still does nothing if the application never tells it which tenant is asking.

The gates are flags on the test runner, not a target in a document: below any of them the command exits non-zero and the pipeline stops. There is no path that prints a number and carries on. What follows is the last run of that command — not the promise, the result.

Generated from the run below, not fetched from a badge service. /coverage.svg

Lines

97.96%

gate 90% — the build fails below it

Branches

87.87%

gate 80% — the build fails below it

Functions

94.4%

gate 90% — the build fails below it

409/409 tests passed across 50 suites in 9.1s, with 0 failing and 0 skipped. Run on 2026-08-06 00:33 UTC by node v22.22.0 --test --experimental-test-coverage, invoked as npm --prefix backend run test:coverage.

Branches sits below lines and functions on purpose. A branch here is usually an error path against somebody else’s API, and driving that to parity means writing mocks that assert the shape of a failure nobody has observed.

Every file on the coverage run, and how far it is covered

48 files, in the order the runner reports them, with the lines each one leaves uncovered. Long run-lists are truncated here; the artifact carries them whole.

5 jobs across 2 workflows, 40 steps in total, read out of .github/workflows rather than described. The workflows themselves are served verbatim at /pipeline.yml — comments included, because the comments are where the reasoning is.

Parsed from the committed report files, including the URL each one actually requested and the time it ran. A perfect score with no stated date and no stated URL is a screenshot, not a measurement.

Accessibility is the one category where a shortfall is a defect rather than a trade-off, and it is the reason these runs exist. Performance varies by route: the homepage ships an interactive pricing engine and pays for it.

The request path from a browser through to Postgres, including where the tenant identity is set and which boundary each credential stops at. A build check compares this against the deployment configuration it describes.

The full request-flow diagram

The picture above is a summary. This is the whole path: every middleware in the order it runs, both pricing engines and the fixture that holds them together, the row-level-security boundary, and the one SECURITY DEFINER function that is allowed to answer whose record an inbound webhook belongs to.

Full size (4440 × 8666)Read the Mermaid source

What the diagram does not state is which of the three system-of-record providers can transact today. That changes when a credential is set on a deployment, and a diagram re-rendered by hand is the wrong carrier for a fact that moves — it was wrong about all three for a day before anyone checked. The live answer is derived per request and published on the integrations page.

Inside the pricing engine

The diagram above stops at the boundary of the CPQ engine. This one is inside it: a single call to calculateQuote(), the margin gate that runs before any price exists, the five component costs and the two different rounding modes they use, the cut list derived from the finished opening alone, and the fixture that pins two engines which are forbidden from importing each other.

Full size (3836 × 7280)Read the Mermaid source

The two engines are duplicated on purpose and the duplication is the risk. One is bundled into the browser so the public calculator answers without a network round trip; the other reads rate cards and must never reach a browser, because a rate card is a customer’s commercial position. They cannot import from each other, so what holds them together is the row of checks along the bottom — a fixture neither engine imports, held against both on every build. It pins the answers rather than the constants, because identical constants once produced a 30.1″ opening cut to 29.00″ in the browser and 28.85″ on the server.