If you want the fastest route through this catalog, start here and then come back to this post for detail.
Series: Start here · Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 6 · Part 7 · Part 8 · Part 9
This post is Part 9 in a Dev.to series grounded in the open-source Pain Tracker repo.
- Not medical advice.
- Not a compliance claim.
- This is about repeatable, local checks — not vibes.
If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor
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 testmake 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.
Next up
Part 10 is about keeping your docs truthful over time — especially for security and privacy boundaries.
Prev: Part 8 — Analytics without surveillance
Next: Part 10 — Maintaining truthful docs over time
Support this work
- Sponsor the project (primary): https://paintracker.ca/sponsor
- Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker
- Read the full series from the start: (link) ## What to read next
- Testing across the stack
- Quality gates and checks
Top comments (0)