Verification

One command, eighteen checks, and why it does not stop at the first failure.

The template ships eighteen automated checks under a single command. It is the same bar ApisKit itself is built under, not a reduced version for the buyer.

npm run verify:all       # while you work
npm run verify:release   # before you publish

Both run the same list. verify:release is verify:all --publicar and additionally runs the checks marked "only on release", which today are the browser tests, the only ones that start a server. Everything else runs in both, so the fast command is never accidentally the weaker command.

Why one command

Because separate verifiers get forgotten. If there are seven commands, three get run. The list lives in a single catalogue, in scripts/verify-all.ts, and adding a check means adding one entry to that array. By construction, a verifier cannot exist outside the gate.

Three things that make it trustworthy

It does not stop at the first failure. Every check runs and at the end you get a report with the state of each one. You see everything to fix in a single pass, instead of discovering it one at a time.

Nothing is counted as passed without running. A check that cannot run (missing credentials, deferred to release) is reported as OMITIDA with its reason, never as correct. The summary counts them separately and says out loud that they are not approved.

Some look at your data, not your code. A form check cannot see that a published page was left untranslated, or that two are fighting over the same address. That is audited against the real database.

What gets checked

Check	What it guarantees
Code quality	No TODO, FIXME, `any`, mocks or no-op code.
Error handling	No silenced errors or empty `catch`.
Runtime safety	No accesses that blow up at runtime.
Type consistency	Domain types do not contradict each other across layers.
Languages	English and Spanish symmetric, and every key used exists.
Theme colours	No raw colours: everything through tokens.
Build	The site builds end to end.
Types	Compiles with no type errors, tests included.
Lint	No lint warnings or errors.
Duplication	No copy-pasted blocks.
Unit tests	Isolated logic behaves as specified.
Vulnerabilities	No dependency with a known vulnerability.
Admin indexes	Firestore has the indexes the panel needs.
Support indexes	The ones support needs.
Published documentation	No broken, orphaned or untranslated page.
Docs indexes	The ones the documentation needs.
Integration tests	Routes answer correctly and leak no internal errors.
Browser tests	Full journeys really work.

The three index checks do not trust the file: declaring an index does not prove it exists. They run the real queries against your project and tell you which ones the database refuses.

What needs something external

Check	Needs
Indexes and published documentation	Firebase credentials in `.env.local`
Browser tests	`npm run verify:release`

Two orderings worth keeping

If you ever reorder the catalogue, preserve these two:

The build runs before the type check. A stale generated route type makes tsc fail for a reason that is not yours.
No check calls process.exit() mid-run, it sets process.exitCode. That way one failure does not truncate the report.

A verifier that has never failed proves nothing

It may be looking the wrong way. The verifiers in this template are tested by deliberately reintroducing the defect and confirming they turn red.

It is worth doing the same with yours. It is the only way to know that a green test means something.

Before you publish

npm run verify:release && npm run licenses

Green on both and the bar is met. Read the report, not just the exit code: a run can finish green and still list checks as OMITIDA, and a skipped check is not an approved check.