Quality gates that earn trust: checks you can run, not promises you can’t

#cicd #codequality #softwaredevelopment #testing

Part 9 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/start-here-paintracker-crisiscore-build-log-privacy-first-offline-first-no-surveillance-3h0k

Series:
Start here
· Part 1
· Part 2
· Part 3
· Part 4
· Part 5
· Part 6
· Part 7
· Part 8
· Part 9
· Part 10

This post is Part 9 in a Dev.to series grounded in the open-source Pain Tracker repo.

For the broader catalog route, start with Start Here: PainTracker and the CrisisCore Build Log.

If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor

For the trust and release path specifically, read this sequence:

This works best as Part 1 of a 2-post trust-and-verifiability pair.
Read next: Maintaining truthful docs over time

This pair also sits inside a broader Documentation Integrity / Verifiable Trust
reading path with
ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify
and
Preview Mode First.

Not medical advice.
Not a compliance claim.
This is about repeatable, local checks — not vibes.

In health-adjacent apps, regressions aren’t “bugs”

A broken export is frustrating.
A broken “locked vs unlocked” boundary is dangerous.
A broken keyboard path is exclusion.

So the question isn’t:

“do you have tests?”

It’s:

“do you have a routine that makes regressions harder to ship?”

Pain Tracker answers that with a set of quality gates that are runnable locally.

The one command gate: `npm run check`

The repo defines a CI-style gate in package.json:

npm run check

It runs (in order):

TypeScript typecheck
ESLint
Vitest
Vite build

There’s also a faster gate:

npm run check:quick

That’s the everyday loop: fail fast, fix small.

A Makefile exists, but Windows folks should use npm scripts

The repo also provides a Makefile with convenient targets:

make test
make check

But if you’re on Windows and not using WSL/Git Bash, the npm scripts are the safest bet.

(That’s not ideology — it’s just avoiding shell portability foot-guns.)

Security checks are a separate lane

“Has tests” is not the same as “doesn’t leak.”

Pain Tracker has explicit security checks in package.json:

npm run security-full

And the Makefile wraps a subset as:

make check-security

What matters is the posture:

security checks are opt-in commands you can run
they’re not implied by marketing copy

Accessibility checks should be automated, too

Pain Tracker includes an automated accessibility scan command:

npm run accessibility:scan

This runs Playwright against a dedicated a11y spec:

e2e/accessibility.spec.ts

Even if you don’t catch everything automatically, this catches obvious regressions early.

What “good” looks like

A good gate has three properties:

1) It’s runnable locally
2) It’s fast enough to be used
3) It fails loudly and early

If your team only runs checks “before a release,” you’re basically using hope as a tool.

The same idea applies to agent workflows, too:
Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants)
shows what it looks like when plan review and invariant checks become part of
the gate instead of post-hoc cleanup.