Summary

session_search returns 0 hits when invoked with OR-combined short CJK tokens (≤2 chars each), even though the underlying messages plainly contain those terms. The CJK-routing branch in hermes_state.py selects the FTS5 trigram path based on total CJK char count in the whole query, but trigram cannot match phrases of <3 CJK chars; the LIKE fallback that would serve this query is unreachable.

Reproduction

Hermes 0.12.0 / commit 7530ce04e (main).

LLM calls (real example from a Telegram session asking about a past trip):

session_search(query="广西 OR 桂林 OR 漓江 OR 旅游")

→ 0 sessions, 0 messages

But the messages are clearly there:

Single 3+ CJK-char terms work fine via trigram (e.g. 广西旅游 → 6, 漓江游船 → 77, 涠洲岛 → 146).

Root cause

hermes_state.py:1748-1753:

is_cjk = self._contains_cjk(query)
if is_cjk:
    raw_query = query.strip('"').strip()
    cjk_count = self._count_cjk(raw_query)
    if cjk_count >= 3:
        # → trigram FTS5 path
    else:
        # → LIKE fallback

The branch tests the total CJK char count across the whole query string. With 广西 OR 桂林 OR 漓江 OR 旅游 that is 8 (≥3), so the trigram branch is taken. The trigram tokenizer requires each phrase to be ≥3 chars (≥9 UTF-8 bytes); each 2-char token here produces no matchable trigrams, returning 0. There is no empty-result fallback to LIKE inside the trigram branch.

Suggested fixes (either is sufficient)

A — Per-token length check (more efficient):

non_ops = [t for t in raw_query.split()
           if t.upper() not in ("AND","OR","NOT")]
if non_ops and all(self._count_cjk(t) >= 3 for t in non_ops):
    # trigram path
else:
    # LIKE path — extend to handle multi-token OR by OR-of-LIKEs

B — Auto-fallback when trigram is empty (simpler, more robust to future tokenizer changes):

if cjk_count >= 3:
    matches = trigram_search(...)
    if not matches:
        matches = like_fallback_search(...)

The user-visible workaround for now is to instruct the model to use single ≥3 CJK-char phrases instead of OR-combined short tokens, but that is fragile per-deployment guidance — fixing the branch makes the tool work as users naturally expect.

Secondary note (not blocking)

While diagnosing, noticed ~/.hermes/SOUL.md's default comment says "This file is loaded fresh each message -- no restart needed" but run_agent.py:4881-4887 says _build_system_prompt is called once per session and only rebuilt after context compression. Users editing SOUL.md mid-conversation won't see changes until /new or compression. Either the SOUL.md template comment should be updated, or that one layer could be re-read per turn (skipping prefix-cache for the persona section only). Happy to file a separate issue if preferred.

Happy to send a PR for either A or B (your call on style preference).