The only code that rejects a malformed benchmark cell is invoked by no workflow, and Sync Benchmarks is two echo statements

[FumingPower3925]

scripts/build-data.ts counts validationErrors and consults that count in exactly one place:

if (validateOnly) process.exit(validationErrors > 0 ? 1 : 0)

validateOnly is set only by --validate-only, i.e. bun run validate. No workflow runs it. CI runs build, check and test; Cloudflare runs bun run build. On the plain build path a malformed benchmark cell is warn()ed, marked "excluded:invalid", written to the JSON and the process exits 0.

So a corrupt or malformed v1.6.0 cell disappears from the published dashboard silently, with every check green. The validation code exists, is correct, and is never executed by anything automated.

Fix: add bun run validate to the CI workflow, before or alongside build. It is the cheapest possible change and it converts a silent exclusion into a red check.

Second, related finding: the Sync Benchmarks workflow is two echo statements. It has permissions: contents: read, performs no checkout, holds no secret and makes no network call, and it has been green on every run because green is unconditional. Nothing in GitHub Actions verifies that a published benchmark tree was actually ingested.

That matters right now for a specific reason: v1.5.9, v1.5.10 and v1.5.11 all shipped and none of them ever reached results/, which currently holds v1.5.5 through v1.5.8 and nothing newer. Three releases published no benchmark data and no check anywhere went red. Either Sync Benchmarks should do the ingestion it is named for, or it should be deleted and the manual step documented in the release process, so the gap is visible rather than implied-covered.

[FumingPower3925]

Closing on the runs, not the diff

#69 is merged, and both halves are now verified by real executing jobs, including the half that could only be tested after merge.

The pre-merge gate rejects a bad cell. Throwaway pull request #68, with two asserted injections (a real cell's env.arch flipped from x86_64 to arm64, plus a synthetic cell at schema_version: "4.1"). CI run 34917866394 failed in 17 seconds at the validation step with 4 validation errors, and Build, check and test were never reached. Negative control on the same tree: the site build itself exits 0, which is the point. One corrupt cell must not take the deploy down, and that is exactly why the gate has to be a separate check rather than a side effect of building.

The gate passes on real data, and says how much it looked at. This pull request's own run 34917943651: 9 cell(s) examined in 4 version(s), 0 validation error(s), 0 warning(s). The old line printed 0 validation error(s) whether it checked everything or nothing, so the count is now part of the output and the job exits 2 on zero cells.

Sync Benchmarks catches a publish that never landed. This is the half that could not be proven before merge, so it was dispatched after. Two acceptance runs against the real tree:

dispatch	expectation	run	result
v1.5.8 / 20260829 / x86_64, a cell that is published	green	34918300153	success
v1.5.11 / 20260907 / x86_64, a release that never published	red	34918352653	failure

And the red case failed for the right reason, not an incidental one:

attempt 1: results/v1.5.11/20260907/x86_64/run-1/summary.json not on disk yet; re-fetching main
... attempts 2 through 5 ...
::error:: publish dispatched for v1.5.11/20260907/x86_64/run-1 but no summary.json is committed under results/v1.5.11/20260907/x86_64
Tree actually present for that version:
  (results/v1.5.11 does not exist)

That is the exact silence this issue was filed about. v1.5.9, v1.5.10 and v1.5.11 each shipped without reaching results/, and nothing went red. It would now.

A second dead branch found along the way

validateEnv() was exported and called by nothing. It is the check for a cell whose env.json disagrees with its own path, which is the mislabelled-architecture corruption that was scrubbed by hand in d3424f4. It is now wired, as errors that do not null the cell, so the dashboard renders exactly what it rendered before and only the gate reddens.

That makes three separate things in this repository that looked like coverage and were not: the validator nothing invoked, the workflow that was two echo statements, and an exported check with no caller.