The DEPLOY1 quality gate dataset: what our checks actually measure
Every change to this repository passes the same quality gate: typecheck, workspace manifest check, lint, format, tests and build. This dispatch documents exactly what each gate covers.
OPEN DATASET
Benchmark artifacts
Raw measurements referenced by this dispatch are published as machine-readable tables below and in the paper body.
The point of a machine-readable dataset is that you can check it, not that it looks impressive. This one describes the checks that run before anything in this repository ships.
The gates
| Gate | What it measures | Failure means |
|---|---|---|
| Typecheck | Strict TypeScript across every workspace | A type contract was broken |
| Manifest check | Workspace dependency declarations | Declared and actual dependencies diverged |
| Lint | ESLint rules, including type-aware rules | Code violates a project convention |
| Format | Prettier | Formatting drifted from the committed style |
| Tests | Vitest suites per workspace | Behaviour regressed |
| Build | Vite site build and the blog generator | The deployable artifact cannot be produced |
Why the order matters
Typecheck runs first because it is the cheapest way to catch a broken contract. Tests run after formatting so a failure is easier to read. The build runs last because a build failure after passing tests usually means an environment or configuration problem, not a logic problem.
Reading the output
Each gate is independently runnable, so a local run can isolate a single check. CI runs them as separate jobs, which means a red build tells you exactly which gate failed without needing to bisect a monolithic script.
Keeping it honest
A gate that is routinely disabled is worse than no gate at all. If a check cannot pass, the fix is to change the code or the rule deliberately — not to relax the check so the pipeline turns green.