metaFields and groupByHeadingThe two utilities with actual design in them, as opposed to the spellings in WORK-602.
metaFields(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:
Tracking started Sep 28 — check back for trends.
metaFields' spec is data: a bare string, or { from: [...], default } — no entry accepts a functionJSON.parse(JSON.stringify(...)) unchangedfrom resolves only the declared roots (attrs.*, file.*); an unknown root is rejected at call time rather than resolving to emptyconfig.variables.file express their created / modified fallback without a closuremetaFieldsmetaFields is adopted where a rune's metas are all plain attrs reads mapped into properties; runes needing a meta outside properties, or conditionally, keep the explicit formgroupByHeading is adopted at the seven loop sites, with each rune's per-item parser left rune-specificrefrakt contracts --check and npm run seo:baseline:check report no driftnpm test passes unchangedmetaFields writes into the same flat key space as refs (ADR-008), so the collision check has to keep working against a computed object rather than a literal — worth a test, since the current check reads Object.keys of both and a generated object is the case nobody has exercised.
Key order matters for data-rune-fields, which is JSON.stringifyd: iterate the spec in declaration order so the bag's key order stays stable and the contracts diff stays empty.
groupByHeading shares only the traversal. parseColorEntry, parseNameValue, parseFontEntry and parseLocationItem stay where they are — the loop is the duplication, not the parsing.
metaFields produces the properties object, so it lands after the children emission is gone rather than having to reproduce itproperties and refs share