Promote refrakt.config.json from a site-only file into the unified root config defined in ADR-010. Add type-level support for plugins, plan, site, and sites, normalize the three valid input shapes (flat / singular site / plural sites) into a canonical internal form, and publish a JSON Schema so editors can autocomplete and validate the file.
Replace the lazy runPlugin import-on-demand pattern in packages/cli/src/bin.ts with a first-class discoverPlugins() helper that returns the full set of installed plugins. The helper has four consumers in v0.11.0 — CLI dispatch, refrakt --help, refrakt plugins list, and the new MCP server — and centralizing the logic eliminates three different implementations of the same scan.
Add three optional fields to the CliPluginCommand interface so plugin commands can declare structured input/output schemas and an MCP-friendly handler that bypasses argv parsing. Existing plugins keep working unchanged — the fields are purely additive.
Switch the CLI's plugin dispatch in packages/cli/src/bin.ts from blind import('@refrakt-md/<namespace>/cli-plugin') to a discoverPlugins() lookup. This produces a friendlier "did you mean?" error when a namespace is misspelled (since we know the full set of installed plugins) and centralizes plugin loading on the new helper.
Update all five framework adapter packages — @refrakt-md/sveltekit, @refrakt-md/astro, @refrakt-md/nuxt, @refrakt-md/next, @refrakt-md/eleventy — to accept a site?: string option. Each adapter resolves its target site via the shared normalizer from WORK-159, then reads contentDir, theme, target, packages, routeRules, icons, backgrounds from the resolved site entry instead of the top-level config. Single-site projects and the legacy flat shape continue to work without changes; multi-site repos pick a target per adapter.
Wire the @refrakt-md/plan CLI commands with the new schema fields from WORK-161 so the MCP server exposes them as cleanly typed tools. Each command gets a JSON Schema for its inputs and an mcpHandler that bypasses argv parsing and accepts a structured object directly.
Wire @refrakt-md/plan to the unified refrakt.config.json. plan init scaffolds the config (creating it or extending an existing one with a plan section), and plan serve / plan build / other plan commands read plan.dir from the loaded config instead of relying solely on the --dir flag and defaults. The plan section currently exposes only dir; specs path remains derived from dir (a child folder), and surfacing it as a config field can come later if real-world projects demand it.
Create the @refrakt-md/mcp package: stdio MCP server entry point, auto-detection of plan and site contexts from the unified config and the filesystem, and the initial set of core CLI-mirroring tools (refrakt.inspect, refrakt.contracts, refrakt.validate, refrakt.reference, refrakt.package_validate).
Wire plugin-contributed tools (notably the @refrakt-md/plan commands) into the MCP server via discoverPlugins(), and implement the read-only resources (refrakt://detect, refrakt://reference, refrakt://contracts, refrakt://rune/<name>, refrakt://plan/*) so agents that prefer pull semantics have first-class URIs.
The collection rune core — a sentinel-emitting schema plus a postProcess resolver that queries the registry (filter/sort/group/limit) and renders the built-in layouts, with the pinned $item bound-variable contract and the per-layout body interpretation.
The built-in adapter (in @refrakt-md/content) that turns site.entityRoutes into contributed pages: selects entities by type + filter, substitutes placeholders, renders an inline render string or a render-template partial per entity with $item bound, and back-fills sourceUrl.
Make plan entities embeddable so {% expand $item.id /%} renders their bodies in entityRoutes detail pages. The plan register hook currently sets sourceUrl only; add sourceFile and an extract that returns the entity rune's transformed body. This is the prerequisite the SPEC-071 dogfood depends on.
Wire refrakt's own plan/ as a sites.plan site and author its plan-site/ content, proving that entityRoutes + collection replace the bespoke plan serve. This is the milestone's proof-of-practice.
Surface the installed plugin set in two places: the top-level refrakt --help output (so users discover available namespaces without reading docs) and a dedicated refrakt plugins list command (canonical machine-readable output for tooling, including MCP clients debugging their setup).
Site-scoped commands (inspect, contracts, validate, scaffold-css, package validate) need to know which site they are operating on when the project declares multiple. Add a --site <name> flag that selects an entry from the normalized sites map; for single-site projects the flag is optional and resolves to the lone entry.
Move site/refrakt.config.json to a unified refrakt.config.json at the repo root, declaring plugins, the plan section, and sites.main (or whatever name we settle on) for the existing site. Validates the design against our own project and gives us a multi-site-ready structure for any future additions (separate plan dashboard site, blog, etc.).
create-refrakt currently writes a flat-shape site/refrakt.config.json for site projects and (via plan init) no config at all for plan projects. Update both paths to produce the new unified root-shape config — site projects get a sites.main section, plan projects get a plan section, and any combined scaffolds (future) declare both.
Document the unified refrakt.config.json at site/content/docs/configuration/. Cover the three valid shapes (flat / singular site / plural sites), each section (plugins, plan, site/sites), the multi-site workflow, and the migration story for existing flat-shape configs.
Document the new @refrakt-md/mcp server (registration, tool reference, resource reference) at site/content/docs/mcp/, update the existing plugin authoring docs to cover the new cli-plugin schema fields (inputSchema, outputSchema, mcpHandler), and add a brief pointer in the root CLAUDE.md so AI agents know the MCP server exists when registered.
The rich-table path: a table collection's body uses the sections content model (heading = column separator + label, body = per-cell markdoc template with $item), with collection owning the <table>/<thead> and row alignment.
Add a plan project type to create-refrakt that scaffolds a complete, runnable plan site: config (plugin + entityRoutes), a seed plan/, and a plan-site/ content dir (layout + dashboards), for a chosen adapter target.
SPEC-104 §6 + docs: document the bg guest body, the bare-surface guardrail, the sandbox preset (with the refrakt.config.json example), and the boot-frame layering; ship the music-blog backdrop pattern as a working showcase exercising the layout-cascade + SPEC-006 audio-bridge composition.
The static gallery (the visual-regression harness from WORK-409) transforms pages with merged.config — i.e. coreConfig plus the enabled plugins' configs — but never calls assembleThemeConfig. The site assembles core → plugins → theme so theme-level overrides reach the engine; the gallery does not, so it can only ever render base output.This is a latent gap in the regression net: any override a theme applies via mergeThemeConfig (tints, icon swaps, and — after WORK-425 — per-rune defaultElevation/defaultProminence deltas) is invisible in the gallery. The gallery shows what a plugin ships, not what a theme actually renders.Not a blocker for WORK-425. Under the agreed Option A, base surface defaults live in core + plugin configs, which the gallery already loads, so default data-elevation/data-prominence emission is gallery-verifiable today. This item only matters once a theme overrides those defaults (Lumina currently inherits the base defaults unchanged).
With WORK-604 landed, playlist's tracks field can declare emitTag: 'track' and receive one homogeneous, document-ordered array instead of a mix of list nodes and track tags.That deletes the interleaving machinery at plugins/media/src/tags/playlist.ts:316-353 — the listCursor consuming tracksData by list length, and the defensive tail for "a shape the resolver collected but this loop did not recognise".It does not delete adoptNestedTrack. See below.
The second proving set for SPEC-143: the storytelling entity runes whose sections arrive as already-rendered child runes (emitTag). Together with WORK-616 this covers both sides of the emitTag split, which is what proves the mechanism rather than one shape of it.Same gate (D7): no drift in contracts or the SEO baseline, per rune.recipe is the standing proof that the escape hatch is still needed (D3). It is not migrated, and it is not bent to fit.
Add a lint pass to refrakt package validate that checks a package's cli-plugin export for structural issues — missing namespace, missing descriptions, malformed inputSchema, namespace conflicts with already-installed plugins. Catches problems at package-publish time rather than at runtime when the MCP server tries to advertise the broken tool.
Add a small migration command that rewrites a flat-shape refrakt.config.json into the nested form (site.* and explicit plugins). Optional for users — the flat shape stays valid indefinitely — but useful for projects adopting the unified config or moving to multi-site.
The first core plain-presentational card rune — ordinary attributes, no $item/registry knowledge — shipped as the reference implementation for collection body templates. Proves the "cards are plain runes; the template wires entity fields into attributes" model.
Mark plan build and plan serve deprecated, pointing users at the site approach, once refrakt's own plan site proves the replacement. Keep the authoring CLI. Removing the bespoke render stack is a later release, out of scope here.
Once cancelled / superseded exist, review the plan corpus for items that should be retired rather than left dangling. The main pool is the 13 pending work items, all sourced from SPEC-008 (unbuilt runes): stat, math, concept, exercise, glossary, objective, prerequisite, quiz, partner, job, album, artist, video. A reviewed, per-item judgment pass — not an automated flip.
loadContent takes fourteen positional parameters (packages/content/src/site.ts:697) and is exported from @refrakt-md/content. WORK-575 adds an options-bag overload beside it rather than a fifteenth positional, which is the right move for that change and deliberately not a redesign.This item is the redesign question, deferred to where it belongs: a public function's shape is much cheaper to change before 1.0 than after.
WORK-628 ran @adobe/structured-data-validator over contracts/seo-baseline/. Its rich-result layer was mostly noise for refrakt. Its schema.org layer was the opposite: zero false positives. It checks that a type exists and that every property is in that type's domain. Over the baseline's history it caught the NonProfit type and the nested Offer.offers over-match. On today's baseline it caught three defects nobody had recorded (BUG-033), on rows whose comments say nothing checks them.SPEC-145 D25 keeps the ban on user schema because this check is too narrow to stand in for a reviewer. It is still a cheap net under the reviewer for first-party rows. This item adds it to CI as a maintainer-side check. Nothing ships to users.
Build the core Vite plugin that intercepts .md files and emits JS modules with rendered HTML, frontmatter, SEO data, and serialized tree. This is the Level 1 (static, per-file) integration — no cross-page awareness.
Implement virtual:refrakt/styles module that imports theme tokens, per-rune CSS, and package CSS. Supports tree-shaking to include only CSS for runes actually used in content.
Implement the canonical field:value selector grammar from SPEC-070 as a single shared module in @refrakt-md/runes, consumed by collection, entityRoutes (SPEC-069), and backlog. The existing plugins/plan/src/filter.ts folds into it, gaining glob/regex, url resolution, and case-consistency while preserving backlog behavior.
Implement the deferBody mechanism SPEC-070's prototype validated: a catalog flag plus a pre-transform pass in the content loader that captures a rune's pristine body as a source string and empties it, so postProcess can re-parse and transform it per entity with a bound variable. Capture must happen before the page transform — by schema-transform time Markdoc has already resolved the body's $item interpolations to undefined.
Add the Plugin.contributePages hook and a contribution phase in the content loader (after file-page registration, before aggregation) that collects ContributedPage[] and runs them through the normal pipeline — the underlying primitive both the entityRoutes adapter and third-party plugins build on.
refrakt edit cannot launch in a multi-site project: EditOptions is just port/contentDir/devServer/noOpen, and resolveSite() throws when multiple sites are declared, telling the user to pass --content-dir — which bypasses config resolution entirely, losing plugins, tints, icons, and route rules. Refrakt's own repo (sites main + plan) hits this. Add a --site flag and an in-editor site switcher so the editor works first-class against multi-site configs.
In block mode, registry-resolved runes — collection, relationships, aggregate, xref, expand, and data-bound sandbox — render as unresolved sentinel shells with no explanation. They resolve in core postProcess against coreData.registry, which the client-side block renderer never runs; RUNTIME_ONLY_TYPES in block-renderer.ts only placeholders nav*. The server already holds the registry and resolvers (the full-page iframe preview uses them), so render these blocks server-side; where that's not possible, show an honest placeholder instead of an empty shell.
Implement the level: 'pipeline' mode that runs the full four-phase cross-page pipeline at build time, enabling breadcrumbs, nav, glossary auto-linking, and other entity-dependent features.
With WORK-110 through WORK-114 complete, convert the 5 postTransform uses identified in SPEC-033 to their declarative equivalents. Validate identical HTML output before and after each migration.
Register a small set of author-facing markdoc functions — currency, date, number, join — in @refrakt-md/runes as the shared value-formatting layer, usable anywhere markdoc transforms run: collection cells, body templates, and entityRoutes render strings. Keeps formatting out of fields and out of any bespoke projection DSL.
Generalize SPEC-066's sourceFile + extract into the embed() contract: an entity is embeddable if it has embed() or (sourceFile + extract). expand and the entityRoutes adapter accept either, so external plugins can make entities embeddable without a source file on disk.
Implements SPEC-095: an explicit group-order attribute so authors can sequence groups over a non-enum field (e.g. category, plugin, edge kind), which today render in arbitrary insertion order.
editHints drive click-to-edit in the block editor; every rune without them is one where clicking a section silently does nothing. Coverage today is 93/130 runes (71.5%): business, design, docs, places, and storytelling are at 100%, but core is at 58% (35/60), plan at 45% (5/11), media at 60% (3/5), learning at 67% (2/3), and marketing at 80% (12/15). Close the gaps using the established SPEC-009 playbook (visible elements as refs/data-name, hints declared in the rune's config).
The engine grew a rich soft-lint system (posture demotion, escape-hatch lints, nesting validation, entity-id collisions) but the editor actively swallows it: runPreviewPostProcess in packages/editor/src/preview.ts collects PipelineWarnings into an array and drops it, and hook errors hit a bare catch {} ("degrade silently"). Authors only discover problems at build time. Pipe warnings through to the UI as a validation rail.This is the warning channel that SPEC-098's inline lints build on.
Execute ADR-019: move bento + bento-cell from @refrakt-md/marketing to core (@refrakt-md/runes + @refrakt-md/lumina) as Layout primitives, with a back-compat re-export shim from marketing. Not a blocker for WORK-350; target a future minor.
Deferred from WORK-409 (its final acceptance criterion). The harness runs end-to-end locally and in the pinned Playwright container; what's left is the CI automation, which needs a browser-backed runner to develop against — hence its own item, unassigned to a milestone until a browser CI environment is in place.
Every rune that declares sequence: names the container holding its items — except one. Steps builds its <ol> at plugins/marketing/src/tags/steps.ts:166 and pushes it straight into children two lines later, so the element carries no data-name, gets no BEM element class, and cannot be addressed from a layout tree.
runMigrateIds sorts colliding claimants by path and keeps the first (plugins/plan/src/commands/migrate-ids.ts:165), so on a branch it can renumber the entity already on main and leave the local draft holding the ID.The safety argument in the code — that it only acts when nothing references the ID — rests on a check that reads plan files only (migrate-ids.ts:170-182). Plan IDs are referenced from four published CHANGELOGs (runes 130, transform 120, lumina 80, content 51), where a renumber is permanent and invisible.
Export a thin initBehaviors() wrapper from @refrakt-md/vite/behaviors that frameworks can call after navigation to re-initialize interactive rune behaviors (accordion, tabs, datatable, etc.).
Internal-only cleanup that lands the rest of WORK-323 once WORK-331 has stopped emitting the dual-emit metas. Remove the now-dead legacy read/strip path so data-rune-fields is the engine's only field-data input. No external/contract benefit beyond Tier 1 — this is for a single internal representation and a smaller engine.
accordion's mainEntity, how-to's step and tool, and recipe's recipeIngredient and recipeInstructions are collections that still serialise as a bare object when they hold one item and an array when they hold two.Every other collection in the catalog has been declared: pricing's offers, playlist's track / hasPart, breadcrumb's and timeline's itemListElement. These five are the remainder.
Build the Astro framework adapter — the first non-SvelteKit target. Astro is MPA-first and SSG-focused, making it the simplest adapter to build and validate.
ADR-029 records three couplings as open questions rather than asserting them. Each is answerable by reading code and running existing tooling; none needs a design. This item answers all three and writes the answers back into the ADR, so the implementing spec is built on measurements rather than expectations.It is a research item. The deliverable is three findings, not a code change.
WORK-594 establishes the index against the one edge class whose extraction is already trustworthy, and finds almost nothing — because embedded source reaches 28 of this repository's 237 content pages. A page can be entirely about a subsystem without ever naming a file in it.This item is the three classes that between them reach the pages that matter.
This is the phase where the feature stops being retrospective. It is placed after WORK-595 only because an impact lookup that knows about snippet invocations but not about the guides is a lookup that misses the pages most worth updating.The CLI answers "what is stalest across the corpus?" — a survey, run occasionally. An agent editing code has a different and better-timed question: "I am about to change these files. What documents them?"
100 metas across 24 tag files are mapped in properties and emitted into children, where createComponentRenderable filters them straight back out (packages/runes/src/lib/component.ts:127-131). 133 other metas already omit that emission and render identically.Delete the emission. Nothing else.
schema, typeof and schemaOrgType on TransformResult / InlineTransformResult have zero callers across all 121 runes. SPEC-130 moved every rune to the declarative table on createContentModelSchema({ schema }); the imperative surface it replaced was never deleted.So schemaTags (component.ts:57-61) is always empty, isSeoMeta (:84) is always false, emptySeoMetas (:110-125) is always empty, and roughly 40 lines of the helper are unreachable.
resolveSequence's emit branch skips anything that is not a list, then replaces the field with only the emitted nodes (packages/runes/src/lib/resolver.ts:194):
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-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.
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'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:
Implement SPEC-158. IDENTITY_FIELDS (packages/transform/src/identity-fields.ts) becomes a list of paths, and findReservedFields resolves a wildcard segment. This adds three protections:
SPEC-145 D2a. A composed rune has no BEM block and ships no CSS, but it still needs an engine config: its modifiers, universal attributes and meta blocks have to render. Today RuneConfig.block is required. The engine builds ${prefix}-${config.block} unconditionally (packages/transform/src/engine.ts), so a config without one emits rf-undefined. A rune with no config at all leaks data-rune-fields into the HTML.Make block optional:
SPEC-145 D10a, landed ahead of composition so it can be proved inert.Markdoc keeps only the attributes a node's schema declares. A marker set on a node before a primitive transforms it is therefore dropped, unless every node and tag schema declares it. Declare data-owner and data-slot once, at config assembly, on every node and tag schema, never per rune. Teach the schema-table resolvers (packages/runes/src/lib/schema-table.ts) to admit a node past a boundary by data-owner plus data-slot. A primitive's own data-name on the same node is left alone.In the output, releaseOwnedNodes strips data-owner and keeps data-slot (D10a step 4, D10c).Nothing sets either attribute yet, so the gate is that nothing moves. The survival test runs the markers through every rune in D12's placement set. That set is "no peer schema, no requiresParent". Any rune that drops either attribute is a finding, named by the test.
The mechanism at the centre of SPEC-145. A definition is frontmatter (the input declaration: tag, attributes, content model, schema, registers) plus a Markdoc body (the output template). Slot names are the join between them.This item builds the definition → PluginRune path and the template's render. It covers only the vocabulary the two slices need:
Every rejection SPEC-145 decides at definition load or schema construction, in one place, so that a bad definition fails with its rune and the offending name rather than rendering silently wrong. Between them, D11 and D26 match every content-model field to exactly one slot.The bulk of this item is the error messages. Each check names the rune and the thing it rejected, and the tests assert the message as well as the throw.
SPEC-145's full worked example and its spike criterion. It is the first composed rune with a schema row: Person, which a first-party definition may declare under D25. It is also the first that uses sections with each and $each.heading, and a preamble with an image slot.character is the case WORK-617 was cancelled for. Its transform failed SPEC-143's D4 family test, so it is replaced rather than declared. The composed version drops the character-section child rune entirely.Like WORK-624, it ships beside the plugin (SPEC-147 D1). The reference is the storytelling character fixture in contracts/seo-baseline/. The gate is that every difference from it is explained, not that there are none (SPEC-147 D2). Two differences are already decided:
SPEC-145 D7. A composed rune has no layout, and the engine renders a declared blocks entry only through layout. So a composed rune can declare metaFields and blocks in full and get nothing, with no diagnostic.WORK-622 landed the generated config carrying both but left its "meta blocks render" criterion unchecked for this reason (#683). character's blocks.metadata (role and status as a definition list) needs it for WORK-625. Pulled into v0.40.0 on 2026-10-08 rather than dropping the block from the composed character. Placing a badge or deflist rune instead is the channel SPEC-145's authoring note rules out for attribute values.
Found by WORK-625, the composed character. A {% hint %} an author wrote before the first section was matched by no preamble field and dropped, with no error and no warning. The composed definition works around it with a catch-all body preamble field. SPEC-145 records the finding beside the character worked example.D11 promises against this silent loss but checks the other direction. It requires that every declared field is placed by a slot. Nothing checks that every authored node is matched by a field. So content can still vanish between the author's file and the content model, by another route.This applies to any content model, not just compositions. A tree-owning rune with a narrow preamble loses unmatched content the same way, so the fix belongs in the content-model resolver, not in the composition layer. First measure how many shipped runes drop content today, so the change can be staged as a warning before an error if needed.
SPEC-153 implementation note 3, the plugin side. In v0.40.0 a composed definition reached the pipeline only as a string passed to defineComposedRune. A plugin now declares runeDir (package-relative, resolved the way fileRoots resolves, D2). Every <rune>.md in it is loaded as a composed rune.Decisions:
SPEC-153 implementation note 4, the project side, and the step that opens composition to users. A project declares runes.dir in refrakt.config.json, following contentDir's shape, with a recommended default of runes (D4). The loader discovers every <rune>.md in it.Decisions:
Composition ships to users in this milestone, and SPEC-153 D9 makes the definition file the user-facing authoring surface. Today the only documentation is a PluginRune note in rune-authoring/authoring-overview.md. Add a page under site/content/extend/rune-authoring/ written from SPEC-145's "template vocabulary, in one place" table. The guide is the spine of that table rather than a summary of it.It covers:
WORK-631 added content-unmatched: validation reports an authored node that no content-model field matches, because the transform drops it. It shipped as a warning because the measurement found that four shipped runes drop real content today, all in the plan plugin. The plan site renders each entity through its rune ({% expand %}), so the loss reaches plan.refrakt.md.Measured over this repo's plan/ directory (907 files), as of WORK-631:
Two families of duplication, with different fixes.AST side — six byte-identical copies. extractText(node: Node) is defined identically in packages/runes/src/tags/form.ts, plugins/places/src/tags/map.ts, plugins/design/src/tags/{palette,typography,spacing}.ts and plugins/marketing/src/tags/comparison.ts.Renderable side — textContent is already exported and reimplemented anyway. @refrakt-md/runes exports it (seo.ts:23), and plugins/plan/src/pipeline.ts + plugins/storytelling/src/pipeline.ts define extractTextContent, while plugins/media/src/tags/track.ts defines a Tag-flavoured extractText.
Two spellings, each repeated past the point of being idiom.renderNodes(nodes, config) → RenderableNodeCursor. The full form appears 153 times, 81 of them as exactly new RenderableNodeCursor(Markdoc.transform(asNodes(resolved.X), config) as RenderableTreeNode[]). There are 160 as RenderableTreeNode[] casts in the tag files.bodyOnly() — { type: 'sequence', fields: [{ name: 'body', match: 'any', optional: true, greedy: true }] } is the entire content model for 49 of the 94 declared in the tag files, in four whitespace variants.
The two utilities with actual design in them, as opposed to the spellings in WORK-602.fieldMetas(attrs, spec) collapses the declare-then-name-again cycle into one declaration, returning a Record<string, Tag> usable directly as properties. plugins/plan/src/tags/work.ts goes from 36 lines of plumbing to about 13:
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 points:
RuneConfig.styles[…].transform is one of only two function-typed fields in the whole of RuneConfig (packages/transform/src/types.ts:301; the other is postTransform, which stays imperative by design). Unlike postTransform, it does not need to be a function: a declarative sibling already ships, and the function form is used by a closed set of three helpers.
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.
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).
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-153 implementation note 1: the packaging prerequisites everything else in that spec rests on. All three failures are invisible in the monorepo, so this step must not be assumed. Measured in SPEC-153:
SPEC-153 implementation note 2. It is the only gate that catches the measured breakages, and nothing like it exists today. A monorepo test resolves packages through workspace links, so it passes whatever the tarball contains.The harness packs a plugin, installs the tarball into a temporary fixture project outside the workspace, and loads it through the same loadPlugin() path a site uses. The first target is the plugins as they ship today. That proves the harness on known-good input, and proves WORK-626's fix against the tarball rather than the workspace. Shipping composed runes in a tarball is a later SPEC-153 step that reuses this harness.
SPEC-145 D27 (c). validateSchemaTable (packages/runes/src/lib/schema-table.ts) checks two things: that by names a declared attribute, and that a fallback exists. It never compares rows keys with that attribute's matches. So a misspelt row (podcasts:) or a newly added enum value silently selects the fallback, and {% playlist type="podcast" %} would publish MusicAlbum.D15 already requires an exact two-way correspondence for template variants. The schema by gets the same check. It needs no composition, and it applies to every hand-written table today (playlist, track, organization and others).
SPEC-147 lists lore as the simplest storytelling rune. It has a title, a body, an Article schema row (title → headline, category → articleSection) and a registered entity. It follows the pattern WORK-624 and WORK-625 set:
SPEC-147: realm (Place) and faction (Organization) share character's shape, sections plus a preamble, and each has a -section child rune that composition removes. Their media split maps to {% mediatext %}. Both follow WORK-625's pattern:
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.