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.

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.