Bugs

The shared stacked-layout contract (packages/lumina/styles/layouts/split.css) assumes media-first source order: top is plain DOM order, bottom flips visually via a generic column-reverse. But hero, feature, and step emit content-first DOM (text before media — the right reading order for their classic media-beneath-text presentation). Result: both stacked labels lie — the default top rendered media at the bottom, and an explicit bottom hoisted it to the top. Found in SPEC-101 review (PR #432); pre-existing.

create-refrakt writes a $schema URL derived from its own package version:

extractHeadings in packages/runes/src/util.ts builds a heading's id by joining only the text child nodes, stripping ?, collapsing whitespace runs to -, and lowercasing. It does not strip any other punctuation, and inline code inside a heading contributes nothing at all — a code node is not a text node, so it is skipped.The result is ids that nobody writing a link would guess:

Thirteen rune reference pages carry a hand-written ## Attributes table. Two of them disagree with the rune's actual schema.

site/content/plan/docs/plan-entities.md documents the attributes of {% spec %}, {% work %}, {% bug %}, {% decision %}, and {% milestone %}. All five tables are incomplete, and two of the omissions are attributes the project's own mandatory workflow depends on.Measured against refrakt reference <rune> --format json --site plan:

spacing and inset are universal attributes — every one of the 45 block runes that carries universals accepts both. Neither has a page that says what it does.Found while checking whether /runes/surfaces was a sound link target for SPEC-128 D1's axis accordion. It is, for most axes, but not all.

refrakt reference answers "which runes are there?" differently depending on which way you ask. Two symptoms, one question, so they are filed together.Found by WORK-547's survey, which reads reference dump as the rune set and got a set that matches neither reference <name> nor check-rune-docs.mjs.

{% data %} resolves where through resolveString, which handles string literals and Variable nodes. Anything else — a Function node, most obviously — returns the empty string, and applyWhere treats an empty expression as no filter. So a where the rune cannot understand renders the entire source instead of erroring.

{% data %} throws result is empty after projection (no rows to render) whenever the projection chain ends with zero rows. That fires on a filter which is correct and simply has no matches — a normal thing to ask of real data.The check cannot be relaxed on its own, because it is the only thing standing between an author and a silently wrong page. Measured against a two-row source with headers name,scope: