WORK-554 established, by planting one and observing, that an error-severity PipelineWarning causes nothing to happen anywhere:
Tracking started Sep 17 — check back for trends.
This item originally carried two independent changes. The visibility half — the dev server showing nothing, and the per-adapter reporting that SPEC-135 D5 collapses into a single seam — is now WORK-575, sourced to SPEC-135.
They were split because only one of them is contentious. Making diagnostics visible changes nothing for any consumer; making a build fail changes behaviour for every downstream adapter. Bundled, the uncontroversial half inherited the other's review burden — which is what this item's own Approach already said when it told you to "do the second even if the first is rejected".
What stays here: the exit code, its opt-out, and the docs that describe the consequence.
SPEC-135 D4 also removes the urgency. A pre-merge gate no longer depends on this item, because refrakt validate is a command with its own exit code and no downstream consumers. Whether a build should fail is still a real question — it is just no longer the only route to catching errors before merge.
Counted on a clean build at the time WORK-554 ran:
| Site | error | warning |
|---|---|---|
site/ | 0 | 35 |
plan-site/ | 0 | 0 |
So flipping errors to fail the build would not break either dogfooded site today. That is the cheap moment to do it; it gets more expensive as soon as the first error-severity diagnostic starts firing routinely.
The 35 warnings in site/ are a separate matter and explicitly not in scope — they are warning, and this item does not propose promoting them.
PipelineWarning produces a non-zero exit from a production build, on at least the SvelteKit reference adaptersite/ and plan-site/ still build greensite/content/extend/plugin-authoring/pipeline.md — written by WORK-554 to say "none of them changes the outcome of anything" — is updated to match the new realityformatPipelineSummary already computes errorCount and every caller discards the return. Once WORK-575 has moved those callers onto a single reporter at loadContent, the change is in one place: surface the count, and let the build fail on it.
Take the opt-out from WORK-559 rather than inventing one. A global "don't fail" boolean is the kind of switch that gets set during a migration and never unset; a per-error-id disable is already being built for SPEC-132 and expresses the real intent — this finding, not yet — rather than all findings, forever.
Do not fold this into SPEC-132. That spec's D3 deliberately declines to assert that validation fails the build, and it lands its findings as diagnostics either way. Keeping the two separate is what lets SPEC-132 ship without inheriting this item's downstream-compatibility argument.
Know where the failure would land. The repository has one workflow, release.yml, on push to main, and the site build runs inside its deploy step, gated on published == 'true'. So a failing build does not fail a PR check — there is no PR check — it breaks the release deploy, after merge, on the job that publishes the site. That is loud, but late, and it blocks releases rather than changes.
This does not argue against the item; it argues for pairing it with somewhere pre-merge to run. SPEC-135 raises that as an open question, and its refrakt validate gives a gate that does not require this item at all.
ctx.error is not load-bearingpackages/content/src/format.ts — formatPipelineSummary, where errorCount is computed and droppedpackages/sveltekit/src/plugin.ts — the isBuild guard that hides diagnostics in dev