Found while fixing #13695 (which dropped the dead 'status' member from SEARCHABLE_ENUM_TYPES). Adding a [#13695] pin asserting SEARCHABLE_ENUM_TYPES ⊆ FieldType surfaced the same class of ghost elsewhere in the same file, wider in scope, so it is filed separately rather than folded into that fix.
Measured (executed, not read) on packages/spec/src/data/search-fields.ts against FieldType.options (49 members):
SEARCH_AUTO_EXCLUDED_TYPES -> ghost members (not in FieldType): ["object","grid","geometry","encrypted"]
SEARCHABLE_TEXTUAL_TYPES -> ghost members (not in FieldType): []
SEARCHABLE_ENUM_TYPES -> ghost members (not in FieldType): [] (post #13695 fix)
SEARCH_VIRTUAL_TYPES -> ghost members (not in FieldType): []
SEARCH_AUTO_EXCLUDED_TYPES declares 'object', 'grid', 'geometry', 'encrypted' as field types that the $search auto-default must never admit — but none of the four is a member of the current 49-value FieldType enum (packages/spec/src/data/field.zod.ts), so each entry can never match a real field's type and is functionally inert (autoDefaultFields in search-fields.ts never sees a field whose type equals any of them).
This is larger in scope than the SEARCHABLE_ENUM_TYPES fix:
- Unlike
'status', all four names read as plausible field-type names (geometry reads like a sibling of the real location type; encrypted reads like a sibling of the real secret type), so this may be renamed legacy vocabulary rather than pure dead code — worth checking git history / blame before just deleting, in case a rename left the old name behind here without updating this set.
SEARCH_AUTO_EXCLUDED_TYPES is documented in the file as "redundant BY CONSTRUCTION" against the positive allow-lists (the auto-default rejects anything not in SEARCHABLE_TEXTUAL_TYPES/SEARCHABLE_ENUM_TYPES anyway) — but the file's own comment there states the guard's value is "the DIRECTION the two vocabularies resolve in should that disjointness ever break" and calls out exactly these four ghost names' semantic weight (secret, password, encrypted, vector are named as the ones where fail-open would leak a masked/heavy column). A ghost member here does not affect the auto-default's live behaviour today, but it does mean the "fail-closed tiebreak" comment is asserting a safety property for names that cannot currently occur.
Scope for whoever picks this up: confirm whether each of the four is (a) simple dead vocabulary to drop, or (b) a stale spelling for a real FieldType (e.g. geometry → location, encrypted → secret) that should be corrected instead of removed — then either drop the dead members or fix the spelling, and extend the [#13695] pin in search-fields.test.ts to cover SEARCH_AUTO_EXCLUDED_TYPES too once it's clean.
Generated by Claude Code
Found while fixing #13695 (which dropped the dead
'status'member fromSEARCHABLE_ENUM_TYPES). Adding a[#13695]pin assertingSEARCHABLE_ENUM_TYPES ⊆ FieldTypesurfaced the same class of ghost elsewhere in the same file, wider in scope, so it is filed separately rather than folded into that fix.Measured (executed, not read) on
packages/spec/src/data/search-fields.tsagainstFieldType.options(49 members):SEARCH_AUTO_EXCLUDED_TYPESdeclares'object','grid','geometry','encrypted'as field types that the$searchauto-default must never admit — but none of the four is a member of the current 49-valueFieldTypeenum (packages/spec/src/data/field.zod.ts), so each entry can never match a real field'stypeand is functionally inert (autoDefaultFieldsinsearch-fields.tsnever sees a field whosetypeequals any of them).This is larger in scope than the
SEARCHABLE_ENUM_TYPESfix:'status', all four names read as plausible field-type names (geometryreads like a sibling of the reallocationtype;encryptedreads like a sibling of the realsecrettype), so this may be renamed legacy vocabulary rather than pure dead code — worth checking git history / blame before just deleting, in case a rename left the old name behind here without updating this set.SEARCH_AUTO_EXCLUDED_TYPESis documented in the file as "redundant BY CONSTRUCTION" against the positive allow-lists (the auto-default rejects anything not inSEARCHABLE_TEXTUAL_TYPES/SEARCHABLE_ENUM_TYPESanyway) — but the file's own comment there states the guard's value is "the DIRECTION the two vocabularies resolve in should that disjointness ever break" and calls out exactly these four ghost names' semantic weight (secret,password,encrypted,vectorare named as the ones where fail-open would leak a masked/heavy column). A ghost member here does not affect the auto-default's live behaviour today, but it does mean the "fail-closed tiebreak" comment is asserting a safety property for names that cannot currently occur.Scope for whoever picks this up: confirm whether each of the four is (a) simple dead vocabulary to drop, or (b) a stale spelling for a real
FieldType(e.g.geometry→location,encrypted→secret) that should be corrected instead of removed — then either drop the dead members or fix the spelling, and extend the[#13695]pin insearch-fields.test.tsto coverSEARCH_AUTO_EXCLUDED_TYPEStoo once it's clean.Generated by Claude Code