What

_searchByTag(tag) (packages/memtomem/src/memtomem/web/static/app.js:3631-3640) sets both search-input (full-text query) and tag-filter to the clicked tag value:

qs('search-input').value = tag;   // ← full-text query also gets the tag string
qs('tag-filter').value = tag;     // ← intended tag filter

Clicking a tag pill in the Tags tab therefore runs a search where the BM25 query and the tag filter both equal the tag string.

Why this surfaced

While auditing the same axis-mismatch pattern that produced #672 (vendor sub-tab follow-through on cross-tab navigation), this came up as an out-of-scope sibling. The Sources family fixes are about a new axis being ignored by older consumers; _searchByTag instead has the same axis duplication that has shipped since v0.1.0 (commit 82bdc54). Filing separately to keep #672 scoped per CONTRIBUTING.md "one focused change per PR".

Two possibilities — needs a decision

1. Intentional union: BM25 ranks documents that mention the tag string in their body higher, on top of the tag filter's exact-match constraint. Result set = documents tagged with the tag, ordered by how often they also reference the tag in prose. Some users might rely on this implicit behaviour.
2. Design flaw: clicking a tag should narrow to that tag, not add an unrelated full-text constraint. Filling search-input makes the search bar look like the user typed it, which is misleading; clearing the tag filter later still leaves the query string behind.

The user-visible behaviour change rules out a silent bug-fix patch — whichever way it lands needs a CHANGELOG.md entry.

Repro

1. Tags tab → Cloud or List view.
2. Click any tag pill.
3. Observe: Search tab activates; search bar shows the tag text; tag-filter dropdown shows the tag; results combine both.

Suggested resolution path

• Decide intent (likely a UX call — link to similar UX patterns in mem0 / Zep / Letta if useful).
• If "design flaw": drop the qs('search-input').value = tag line, keep tag-filter only, add a CHANGELOG entry under "Changed".
• If "intentional union": rename to make it obvious (_searchTextAndTag?) and add a tag-only entry-point for users who want strict tag scoping.

No regression — v0.1.0+ behaviour, not a recent ADR-0007 / #604 / #618 follow-up.