Found by WORK-628, which ran @adobe/structured-data-validator over the SEO baseline. These are the only schema.org-layer findings on today's baseline, and every one of them is real. The baseline never recorded them as defects: SPEC-130 D5 leaves a schema row to the reviewer, and the rows that carry these properties say in their own comments that nothing checks them.
data-meta-rank is the channel by which density compaction is meant to drop secondary metadata. It is specified, it is styled, and no code path ever puts it on an element.
howto, recipe, steps and track each hand-roll a CSS counter that the sequence dimension already provides for them. The duplication is invisible because the output looks identical — but the two rules land at different specificities, so which one is actually in effect differs from rune to rune.
When two files claim an ID, runMigrateIds sorts the claimants by path and keeps the first (plugins/plan/src/commands/migrate-ids.ts:165). Which claimant is already published on the base ref plays no part, so on a branch the tool will happily renumber the entity that is already on main and leave the local draft holding the ID.The safety argument for that choice is stated in the code:
resolveSections has two branches. The emitTag branch (packages/runes/src/lib/resolver.ts:480-502) builds a tag node per section and returns — it never calls matchKnownSection:
The design plugin's postProcess (plugins/design/src/pipeline.ts) and the editor preview's client-side stand-in (packages/editor/app/src/lib/preview/block-renderer.ts) both deliver a sandbox's design-context tokens as a child element: <meta data-field="design-tokens" content="{…}">. The identity transform leaves it in place (it is not a modifier), so it ships inside <rf-sandbox>.The rf-sandbox behaviour never reads that child. It looks for the tokens on a host attribute, this.dataset.designTokens (packages/behaviors/src/elements/sandbox.ts:112), and otherwise falls back to RfContext.designTokens. Nothing in the repo sets either: no transform emits data-design-tokens, and no code assigns RfContext.designTokens. So this._tokens is always null and the iframe never receives a token set, whichever context the sandbox names.Found while fixing BUG-032. That fix makes the build pick the right token set per context. This bug is what keeps that set from reaching the page.
Found by WORK-634 (#695), which scaffolds a project in its tests.The starters ship content/docs/getting-started.md, but five of the six _layout.md files list the nav item as getting-started instead of docs/getting-started:
Found by WORK-634 (#695).packages/create-refrakt/template-html/build.ts calls loadContent without the plugins option. Its own comment (around line 127) says plugins should be passed through, matching the option shape createRefraktLoader uses for the Vite-based adapters. As a result:
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.
Three live pages point a file-ref at a line range that no longer contains the symbol it is labelled with — and no longer exists in the file at all. This is the exact failure SPEC-131 describes as its motivating case, observed rather than predicted.
For a rune whose primary syntax is a Markdown list, refrakt reference documents that a list is accepted and nothing about what goes in it. Three facts are lost, at two different points in the pipeline.
sandbox declares a context attribute ("Shared context scope for multiple sandboxes", packages/runes/src/tags/sandbox.ts:92), and the design plugin reads it to choose which design-context token set to inject. The sandbox transform never puts the value anywhere. The attribute is read nowhere in sandbox.ts (lines 142–155 read the others), and createComponentRenderable is called with no properties (:247), so the rune carries no data-rune-fields entry and no <meta data-field="context">.The consumers therefore always fall back: