v0.34.0 — Content validation

Two separate proposals now depend on the same unverified assumption: that ctx.error(…) is a loud failure. Nobody has established what it does.packages/content/src/site.ts:301 gives preprocess hooks info / warn / error, all three pushing onto one preprocessWarnings array that "callers funnel through the standard pipeline-warnings surface". Whether an error-severity entry then fails a build, fails a test, prints to a console nobody reads, or is silently collected is not written down anywhere, and both dependent designs assume the strongest reading.

packages/runes/src/tags/error.ts is a leftover from refrakt's predecessor. It emits a bare <tr> of four <td>s from a Markdoc ValidationError, has never had a producer, and cannot be written by an author without crashing the build.Delete it.

SPEC-132 phase 1. Call the validator that already exists, at the point the tag set is already assembled, and turn its findings into the diagnostics the pipeline already carries.This is the whole mechanism. Everything after it is choosing which error ids to switch on.

SPEC-132 phase 2's gate. Before the attribute error ids are switched on, count what they would report across site/ and plan-site/ — and record the number, so the decision to proceed is made on evidence rather than optimism.

SPEC-132 phase 2. Add attribute-value-invalid, attribute-missing-required and attribute-type-invalid to WORK-556's allow-list, fix whatever WORK-557 found, and correct a severity inconsistency the spec surfaced.This is the half that makes rune schemas mean something: required and matches are declared on ~175 tags and enforced on none of them.

SPEC-132 D5. Users have content we cannot anticipate, and a framework that nags them about a diagnostic they disagree with — or worse, refuses to build — is one they turn off wholesale. Give them a narrow switch so they do not reach for a wide one.