Search Concordance

Search, sort, and filtering over the concordance index built in #48 — including the coverage question the Analysis Catalog deliberately cannot answer: what haven't I glossed yet?

Blocked by #48: there is nothing to search until the index and its panel exist.

Scoping stub. This issue was title-only; the body below was drafted from the surrounding code and issues to make it schedulable, and records open questions rather than deciding them. Correct it freely.

Scope

• Search over surface forms, using foldForSearch from src/utils/search-fold.ts (#192, in review) — the same fold the catalog uses, so αρχη finds ἀρχῇ and salom finds šālôm. Do not add a second fold, and do not use normalizeSurfaceForm here — #186 is emphatic that the search fold and the identity normalization must stay separate, and #48 buckets rows on the identity one.
• Fold once at index build time, not per keystroke, following the searchText precedent in src/utils/analysis-query.ts.
• Sort — occurrence count descending as the default, plus alphabetical by surface form. Collate with Intl.Collator on the source project's platform.languageTag; code-point ordering is wrong for Greek and Hebrew.
• Coverage filters — the reason this issue carries weight beyond "add a search box":
  • unglossed only (no analysis for any occurrence)
  • partly glossed (some occurrences analyzed, some not)
  • fully glossed
• Frequency filters — e.g. hapax legomena, or a minimum occurrence count. Cheap once the index exists and genuinely useful for triaging what to gloss next.
• Search / sort / filter state stays ephemeral useState, matching #186's reasoning: persisting a filter across a reload is the classic "where did my data go" bug.

Why this is the coverage surface

#186 routes coverage questions here explicitly: "Coverage questions ('what haven't I glossed?') are out of scope and belong to #50 / #117." #117 answers it per book (counts and last-modified); this answers it per word. Between them they cover "how far along am I" and "what specifically is left".

Relationship to Find (#155)

#155 (Ctrl+F) and this issue are both text search and will confuse users if they behave differently. Find is a transient in-view jump-to-next; this is a persistent ranked list. They should at minimum share the fold, and the wording of "no matches" and the match-highlighting treatment should agree. Worth designing the two together even though they ship separately.

Open questions

• Does search match glosses too, or only surface forms? Matching glosses makes this overlap the catalog's search; restricting to surface forms keeps the two panels' jobs distinct. Leaning surface-forms-only, but not decided.
• Regex or morphological search? Out of scope for a first pass, but decide whether the query shape forecloses it.
• Should this go to user-questions.md for review outside the dev team? (per AGENTS.md UX-decisions guidance)

Blocked by: #48. Related: #186, #155, #117, #192.

Start with blocked issue #48 to understand the concordance index and panel, then read src/utils/search-fold.ts and src/utils/analysis-query.ts for the shared folding and indexing precedents. Review #186, #155, #117, #192, and AGENTS.md before resolving the open UX questions; done means the panel supports the agreed search, sorting, coverage, and frequency behavior without persisting state.