4grayandClaude Fable 5 0f8f7be2fe fix(search): keep non-compound tokens as SQL constraints on compound arms ...

Review follow-up (Greptile P1 x2, Codex P2 x3 on #1172): for multi-token
compound terms like "A&E HD", the compound substring arms let any title
containing "a&e" into the bounded SQL candidate window (200 per-playlist /
5000 global) before scoring enforced the remaining tokens, so enough plain
"A&E" rows could push real "US: A&E HD" matches out of the window.

- title and M3U payload conditions now compose per word: each word's token
  conditions AND together, and only a compound word's own arm gains the
  intact-substring OR — every other word stays an independent constraint
- the trigram FTS supplement AND-s the non-compound tokens as contains
  LIKE conditions next to MATCH '"a&e"'
- new SearchWordPlan/getSearchWordPlans/getCompoundResidualTokenGroups
  helpers in content-search.util.ts

Verified on real SQLite: searching "A&E HD" selects "US | A&E HD" but no
longer selects plain "A&E"/"US: A&E" rows at the SQL level.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-24 07:39:10 +02:00

..

architecture

fix(search): keep non-compound tokens as SQL constraints on compound arms

2026-07-24 07:39:10 +02:00