How changes ship, and how we test them

Changing the database safely (migrations)

Every change to the database's structure is a numbered SQL file that can be run twice without harm. The schema is 79 SQL files applied in a fixed order by a script that records each file's checksum. Every file is idempotent — create if not exists, create or replace, drop policy if exists — and a test applies the whole set twice and asserts the second pass changes nothing. A changed file re-applies; a renamed function is dropped first. There is no ORM and no generated migration.

Tests

The tests build the real database in memory (the real migrations in PGlite, an in-process PostgreSQL), load the demo workspaces, and query as each person with the security rules switched on (RLS active) — over 2,300 assertions, no network. Several security suites build the same fixture twice, with and without their fix, so a green result cannot be miscredited. A route test checks that every link the shell renders points at a route that exists; an architecture test enforces the module manifest; a Playwright smoke covers the public pages against production.

Scheduled jobs

A daily sweep for the AI assistants and a daily sweep of workspaces (crons), each behind a shared secret; if the secret isn't set, the job refuses to run (fails closed).

Browser protection

The site is locked down against common browser attacks, can't be embedded in other sites, and tells browsers to always use an encrypted connection (strict CSP, frame-ancestors none, HSTS preload, nosniff, scoped Permissions-Policy, from next.config.ts).

Watching for errors

Errors in people's browsers are sent to an endpoint that records them; server logs are Vercel's.