6.1.5 Epic-5 rows in the builder — custom-field / label / component conditions (dynamic field entries, per-type editors, stale states)
Estimate: 28m · Depends on: 6.1.2, 6.1.4, 5.4.8
The builder rows for the Epic-5 surfaces, on the 6.1.2 dynamic registry entries.
Build: the field picker grows the project's dynamic entries (custom fields under a labelled group with their type glyphs — the 5.3.4 glyph map; Labels; Components); per-type value editors reuse the owners' vocabulary — CF select options (archived marked, the 5.3.5 grammar), CF user → the member picker, CF number/date/text → the 6.1.4 editors, labels/components → the 5.4.8 MultiSelectPicker fed by their bounded reads; the stale/unknown-value row state (deleted referent in a shared URL → the designed notice, condition matches nothing); definitions changing under an open builder degrade gracefully (a removed field's row goes stale, not crashed).
Acceptance criteria
- Every CF type + labels + components is buildable end-to-end (pick field → operators per type → designed editor → live results via the indexed joins); the dynamic entries track the project's definitions.
- Stale-referent rows render the designed notice and match nothing; a field deleted mid-session degrades the open row gracefully.
- URL round-trip covers dynamic conditions (shared links restore or go stale-typed); axe-clean; token tiers only.
- Integration tests over each editor kind + the stale paths; coverage ≥90%.
Context refs
- 6.1.2 (dynamic registry entries + stale rule); 6.1.4 (the row surface)
- The 5.3.5 rail-editor grammar + 5.3.4 glyph map; the 5.4.8
MultiSelectPicker+ bounded reads design/work-items/filter-builder.mock.html(the CF/label/component panels)- finding #57 (bounded option reads)