v0.19.0 — Polish, composability & rollups

With the generic aggregate rune in place (WORK-294), plan-progress becomes thin sugar over aggregate — same pattern as backlog / decision-log / plan-activity wrapping collection. plan-progress's current rendering (the progress bar + per-status badge row) is exactly the aggregate composition; we just need plan-specific defaults baked in so the call site stays {% plan-progress /%}.

Review every declared contextModifiers entry across core and plugins, decide whether the pairing is meaningful, and either style it or remove it. The lone KNOWN_MISSING_SELECTORS context entry — Hero's feature → in-feature — is the first casualty: it has no sensible rendering, so the modifier comes out rather than getting CSS.

Turn RuneConfig.parent into a validated, self-declared requiresParent constraint (SPEC-084). A child rune that declares it must live inside a given parent, but appears outside it, surfaces a diagnostic instead of rendering silently-broken output. Crucially this is open-world: only a rune that self-declares a requirement is ever checked — the framework keeps no registry of allowed children, so third-party runes on either side just work.

The authoring-facing half of SPEC-084: a contract guide for rune authors plus a CLI audit. (The end-user catalog of concrete compositions lives separately in the "Compositions" docs category, WORK-346 — this item is the "how the contract works" reference, not the recipe book.)

Per SPEC-084's open-world styling rule, a container adapts its slot, not the specific guest. Containers that already expose a media zone (card, feature, hero, recipe) should size/clip any visual rune dropped into that zone — map today, chart/gallery/diagram/embed/sandbox next — via one name-agnostic selector, rather than per-pair styling. map-in-card is the proof case.

The plan sugars backlog, decision-log, and plan-activity lower to collection with bespoke card/table bodies that predate the bar rune. Rebuild their default bodies to compose from bar and give backlog a layout passthrough — while keeping the rollup faithful when the query mixes entity types.

When collection groups results, the per-item template can't see which group it belongs to or that group's size — so authors drop to aggregate for anything group-aware. Expose the group key (and count) on $item so grouped collections can render group context inline.

Two structural foundations from SPEC-085: give bento-cell the same zone structure as card, and stop modelling bento as a page-section.

Make {% bento-cell %} a first-class authoring path for full per-tile control (the dashboard use case), alongside the heading sugar. Today the bento-cell tag is registered but convertHeadings would swallow a hand-authored cell into the preceding heading's content, so explicit authoring doesn't actually work.

Land SPEC-085's sizing model and the placement/link affordances. One grid, one vocabulary: a 6-column default, proportional size presets, and precise cols/rows.

Close the one gap between "we have the data" and "we can chart it." Plan entities are already registered in the main site's registry, so {% aggregate type="work" group="status" %} returns real counts today — but aggregate can only render an inline integer or a body-zoned template, not a chart. Add a layout="chart" mode that renders the grouped counts as an SVG, reusing the rf-chart renderer from WORK-333. This is the SPEC-076 "chart layout" future extension, and the clean "data rune feeds viz rune" composition.

Today the rf-chart web component hardcodes its palette (a JS array of semantic token refs) and all geometry (bar width bw*0.75, point r:4, stroke/ font/ gridline sizes). A theme has no say over bar thickness, series colours, etc. Define a provider-agnostic theming contract — a --rf-chart-* custom-property surface — and make the built-in SVG renderer the reference implementation of it.

Implement the author-defined levels ladder for bento's heading-sugar path, per ADR-013. One attribute replaces the need for the removed sizing/span mode: a user who wants the old uniform-width grid writes levels="6,5,4,3,2,1".Queued deliberately — the design is settled in ADR-013; left to marinate before implementation.