memory_read with multi-word queries returns no results (substring-only matching)

[alain0308t]

Describe the bug

Searching memories with a multi-word query in memory_read returns nothing unless the exact phrase appears verbatim in the entry text, because the filter uses a naive substring match (text.includes(q)).

Example

Given an entry with the text:

"The user prefers to drink coffee in the morning."

Searching with query coffee morning returns no results (the entry actually says "coffee in the morning" — the words in between break the exact substring match). Searching coffee alone works.

Suggested fix

Split the query into terms and match when all meaningful terms are present (AND logic), with a fallback to substring matching when the query has no terms longer than 2 characters:

function readQuery(store, directory, opts = {}) {
  const q = String(opts.query ?? "").trim().toLowerCase();
  if (!q) return readableEntries(store, directory).filter((e) => !opts.category || e.category === opts.category).filter((e) => !opts.scope || e.scope === opts.scope).sort((a, b) => score(b) - score(a));
  const terms = q.split(/\s+/).filter((w) => w.length > 2);
  return readableEntries(store, directory).filter((e) => {
    const hay = e.text.toLowerCase() + " " + e.category.toLowerCase();
    if (terms.length > 0) return terms.every((w) => hay.includes(w));
    return hay.includes(q);
  }).filter((e) => !opts.category || e.category === opts.category).filter((e) => !opts.scope || e.scope === opts.scope).sort((a, b) => score(b) - score(a));
}

Expected behavior

Multi-word queries like coffee morning, sudo password or open source privacy should match the corresponding entries.

---

Note: this issue was vibecoded — written with the help of an AI assistant (opencode) during a live session. The suggested patch was tested against real data and works, but please review it before merging.

[cioffiAI]

Thanks for the report and the patch — confirmed and fixed on the v1.6-retrieval-relevance branch, included in the upcoming 1.6.0, with a more conservative approach than the proposed one.

readQuery now has two paths:

1. the existing contiguous substring match is preserved, so no query that worked before changes behavior;
2. a new path requires all query terms to be present as whole tokens, in any order and non-contiguous, in the entry text or category.

The w.length > 2 filter from the proposal was not adopted: short and technical terms are meaningful, and dropping them reintroduces false positives (AI models matching "statistical models", C compiler matching "Rust compiler"). The tokenizer keeps AI, UI, DB, C, R, no, C++, C#, Node.js, .NET; it does not fold accents (caffe does not match caffè) and adds no stemming or synonyms. Scope/category filters, score ordering and the local-only/project privacy policy are unchanged.

coffee morning now matches "coffee in the morning", while the negative cases above return nothing. The full contract is covered in tests/read-query.test.ts. Commit: b5a4038

1.6.0 is not on npm yet — once published, please verify it against your real data and comment here.

[cioffiAI]

Update: @cioffi_ai/opencode-memory@1.6.0 is now on npm with the multi-term fix (legacy substring preserved + all-terms token match) and symmetric identifier tokenization: JavaScript, javascript and java script now match each other, and userStore matches "user store" in both directions.

Please verify against your real data and comment here if any case is still missed.