v0.39.0 — Declarations, part two

SPEC-146 Problem 1, the present-tense half. findChildren (packages/runes/src/lib/schema-table.ts) matches a schema children key against data-rune as well as data-name / data-field, descends the whole subtree and applies every match. So playlist's children: { track } retypes an author's own {% track %} nested in an unrelated container as one of the playlist's tracks, and because the child row is applied with the author's node as root, the row's own properties resolve inside it. The SPEC records the result in the JSON-LD graph, not only in RDFa: an unrelated recording published as a track.The colliding rows are a closed set: playlist's musicRow/spokenRow and breadcrumb's breadcrumb-item carry their own properties and reach the graph; recipe/howto (step), pricing (tier), timeline and accordion carry text/generated only and mis-stamp RDFa.

SPEC-146 Problem 2. findAllByName stops dead at any nested data-rune, which is right for every rune today and wrong the moment content is placed inside a primitive on another rune's behalf (SPEC-145). Only node-sourced values are affected: properties from a node, text, and the node half of entities. Attribute-sourced values resolve through the field bag and are untouched by nesting.

SPEC-144's mechanism. A rune declares that it registers a named entity or an edge, and one core pipeline participant performs the registration in the existing Phase 2 (register) / Phase 3 (aggregate) slots. The registry, the relationship graph and the query runes (collection, relationships, aggregate) are unchanged. This only gives them a declarative way in.

The motivating case for SPEC-144. plugins/storytelling/src/pipeline.ts registers character, realm, faction, lore and plot through a generic walk and two field-list switch statements (extractEntityName, extractEntityData), expands character aliases in aggregate, and registers bond as an edge. All of that becomes a registers block on each rune.postProcess stays exactly as it is. Declaring sentinel resolution is out of scope for this milestone (see WORK-611).

The second reachable plugin in SPEC-144's reach table. plugins/design/src/pipeline.ts (92 lines) has the same shape as storytelling's, only smaller. Move its registration onto registers declarations and delete the hooks.Under the same D4 gate as WORK-612: a registry snapshot taken before, asserted after, with order included.

SPEC-143's mechanism, without migrating any rune. That happens in WORK-616 and WORK-617.createContentModelSchema gains an emits declaration carrying the renderable's identity (rune, tag, property), its properties in SPEC-140's data form (fieldMetas, which already takes no function values), and its slots:

SPEC-141 D5/D6, shipped first and on its own. snippet runs in two phases: preprocess, and a postProcess pass, wrapStandaloneSnippets in packages/runes/src/config.ts, which wraps a standalone <pre> in <figure class="rf-snippet">. The wrapper adds no information: data-source and data-lines are already on the <pre>, and .rf-snippet's CSS only resets the margins the figure itself introduced.Removing it makes snippet single-phase, so WORK-618 moves one concern into the tag module rather than half of one.Breaking output change. Downstream CSS or tooling selecting .rf-snippet or [data-source-path] must move to pre[data-source]. Authors who want chrome compose it: {% codegroup title="…" %}, or {% figure %} once BUG-028 lands in this milestone.

The first proving set for SPEC-143: the plan entity runes whose sections arrive as resolved entries (no emitTag). After SPEC-081 they build no structure; what is left is properties, title → header, description → blurb (omitted when empty), sections → body. That is exactly what the slot declaration expresses.

SPEC-141's main change. Replace the three whole-AST passes (walkAndReplaceIncludes, walkAndReplaceSnippets, walkAndReplaceData) and their hand-written order in config.ts with one walk that dispatches per tag, and move each preprocessor into the tag module that owns it: