Part 9 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/offline-first-without-a-backend-a-local-first-pwa-architecture-you-can-trust-3j15
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 full reading path around this trust layer, start with Documentation Integrity / Verifiable Trust: Start Here.
If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor
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 How ProofVault turned trust from a documentation claim into a reproducible release artifact 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 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.
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.
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)
Top comments (0)