Note · what stops a bad change before it ships

The Local Safety Net

Every change reaches the same gate before it merges, whether it started as a customer request on our shared board or someone on the team typing directly into the codebase. Most of that gate is a checklist, run every time. A smaller, sharper part of it is enforced by code, before the edit is even made.

Our build process blueprint covers what happens to a request end to end. This one covers the layer underneath it: the gate every branch clears before it merges to the integration branch, and the handful of rules nobody can get wrong by accident, because the tooling itself refuses the edit.

Nothing merges without clearing the checklist

The same checks run on every branch, every time, and the path is the same whether a person or an automated run built the change.

Scope check

Every changed file has to map back to what the branch says it’s for. Anything that doesn’t gets split into its own change first, before the rest of the checklist even runs.

Types, lint, unit tests

Including a set of structural tests that check authorization coverage and route-permission wiring directly, alongside the business logic.

Production build

A full build every time. Some failures only show up once code is actually bundled for the client and the server separately.

Targeted regression

Automated browser tests scoped to exactly the product areas the diff touches, on top of a fixed baseline that always runs regardless of what changed.

Migration ledger

A database change has to already be applied to a staging database and recorded before the branch merges. An unapplied file sitting in version control fails the check.

Code review

Depth scales to what the change could actually break. More on that below.

Some rules are enforced by the tooling

A written rule only works if whoever’s making the change remembers to follow it. For a short list of ours, the tooling itself refuses to make the edit.

What gets blocked before the edit is even made

blocked a hand-typed query bypassing the generated schema

blocked a lint warning silenced instead of fixed

blocked a database change missing from the migration ledger

blocked a commit to the integration or production branch directly

blocked a push that targets the production branch

One narrower case, a hardcoded reference to a specific AI model version outside the one place it’s allowed to live, gets a warning instead of a hard block, since a pattern match can’t always tell a real violation from a false positive. A person still looks at that one.

That list stays short on purpose. It holds only the narrow set of rules reliable enough to enforce mechanically. Everything else in Section 01 still depends on actually being run, which is exactly why each one is a required step in the checklist.

Review scaled to what could actually break

A one-line copy fix and a change to how a session gets authenticated call for different scrutiny. Giving every change the expensive version would make it too costly to run consistently on the changes that need it.

Standard depth

Most changes: new UI, a new endpoint following an already-reviewed pattern, a test-only diff.
Still a full, independent AI review, in a single pass.

Extended, multi-pass depth

Authentication, session handling, or anything platform-wide.
A third-party integration: payments, identity providers, and the like.
A database policy change touching an existing table’s rows, or billing internals.

Even the deepest local tier stops short of the much larger, multi-agent review reserved for a release promotion. Cost stays matched to actual risk at every step.

Every database change ships in two safe steps

Additive first, destructive later. A person applies each one, and no script ever holds a production credential.

Additive first. A change that adds a column or a table ships alongside the code that will use it. Nothing that already exists changes shape yet.

Applied to staging. By a person, pasting the exact file a reviewer already saw. Builds never apply database changes.

Applied to production the same way. Verbatim, at a scheduled window, by a person. No automated path ever holds a production database credential.

Drift check. After every apply, an automated check confirms the repository, staging, and production all agree on what actually ran.

Destructive follow-up, later. Dropping the old column or table ships in a separate, later release, once nothing in production still depends on the old shape.

Keeping the product’s own AI honest about itself

The same in-app assistant that answers a customer’s “how do I—” question reads from a small set of internal product-description entries. Those go stale exactly the way any documentation does: quietly, and usually not until a customer gets the wrong answer.

internal product knowledge baseproduct drift

A branch changed how one of our own reporting views computes a number. The merge checklist resolved the change to the specific in-app help entries it touched and printed the published entries for review. One was still accurate. The other was updated in the same change.

checked via: an automated diff-to-topic mapping, reused from the same mapping that decides which regression tests a change needs

It’s a checklist. It tells a reviewer exactly what to look at, and a person decides whether the content is still true, every time.

The gate means nobody has to trust an AI to write good code unsupervised. It catches what supervision would have caught, every time, whether or not someone remembers to look.