future-plans: parametric search, field filter, field grouping, DRY audit

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

future-plans.md

@@ -49,6 +49,19 @@ function render() { sync_nav(); SECTION_RENDERERS[section]?.(); }
 (`views/components.mjs`, `views/grids.mjs`, etc.) that each export their render
 function and own their local state.
 
+### DRY / SSoT audit
+As the app grows, patterns are being duplicated rather than centralized. Areas to
+review:
+- Field sorting: same sort-by-name logic appears in both detail view and edit dialog
+- Field rendering: `render_field_value()` exists but call sites still sometimes
+  inline display logic
+- Component display name: `component_display_name()` is the SSoT but there may be
+  call sites that still use `c.name` directly
+- Server-side: PDF conflict checks, sanitize calls, and rename logic are inline in
+  route handlers — could be extracted into a `pdf_service` helper
+- General pass to identify and eliminate copy-paste between routes and between
+  render functions before the codebase grows further
+
 ## Field system
 
 ### Improvements
@@ -79,8 +92,30 @@ With or without a parser chain, `render_field_value()` should gain:
 - Mouser/Digi-Key part number fields → auto-craft links to product pages
 - More URL-like patterns (without `https://` prefix)
 
+#### Field selector filter
+When adding a field to a component in the edit dialog, the dropdown becomes
+unwieldy with many fields. Add a filter/search input to the field selector.
+
+#### Parametric search
+Allow searching/filtering components by field values, not just names. Examples:
+- `resistance < 10k`, `package = 0603`, `voltage_rating >= 50`
+- Cross-field queries: find all 0603 resistors under 10kΩ
+- Should integrate with the existing word-split search or replace it with a
+  richer query language
+- Depends on field types (numeric vs string) for range queries to work correctly
+
 ### Long term
 
+#### Field grouping / linkage
+Some fields naturally belong together (e.g. `frequency_stability` and
+`frequency_stability_temp_range`). Options:
+- Soft linkage: tag fields with a group name, display grouped in the UI
+- Structured fields: a field can be a record type with named sub-fields
+  (e.g. `stability: { value: 10, unit: "ppm", temp_low: -40, temp_high: 85 }`)
+
+Structured records are the more powerful option but require a schema system and
+more complex UI. Grouping/linkage is a lighter short-term win.
+
 #### Renderer/parser result cache
 Once parsers and formatters run per-render, a cache keyed on field value + template
 version would avoid redundant work on large inventories. Invalidated when any
@@ -89,6 +124,7 @@ template changes. Not urgent — premature until the parser chain exists.
 #### Field types
 Currently all field values are free-text strings. Typed fields (numeric,
 enum/dropdown) would enable better formatting, validation, and range-aware search.
+Prerequisite for parametric search with range operators.
 
 ## PDF / files