What

There are now three places in packages/memtomem/src/memtomem/web/static/app.js that mutate tag-filter and trigger a re-search, and they keep accumulating subtle behavioural differences:

Issue #672 / PR #749 fixed the dual-axis bug in _searchByTag purely by code review + manual checking — there is no automated guard against a future helper extraction re-coupling these paths or someone "fixing" _searchByTag to also set search-input again.

Why

• The repo currently has zero JavaScript test infrastructure (no package.json, no *.test.js, no Playwright config). All Web UI verification is manual, which doesn't scale as the SPA grows.
• Tag-filter mutation is only one cluster — the same risk applies to the namespace filter (PR feat(web): expose namespace list in prod for filter dropdowns (#582) #604, feat(web): expose Settings → Namespaces tab in prod (ADR-0007 PR-A+B) #618), source filter, and the upcoming tag-only search path (Allow tag-only search (relax empty-q guard in /api/search and doSearch) #750).
• The reviewer of PR fix(web): drop search-input pollution from _searchByTag (closes #672) #749 flagged this explicitly: "\_searchByTag is the third tag-filter mutation site (after app.js:1885 and app.js:2413) and they keep accumulating subtle behavioural differences."

Suggested approach

Pick the lowest-overhead option that catches regressions in CI:

1. Playwright + tiny smoke spec (recommended): one spec per mutation site, asserting the correct fields are populated and doSearch() request shape. Adds a Node toolchain dependency but the model is well-understood and CI patterns exist (Playwright's GitHub Action). Runs against mm web started in a fixture.
2. jsdom + vitest: pure-JS, fast, no browser. Can exercise _searchByTag / chip handlers in isolation by injecting the DOM. Cheaper to run but requires shimming qs, api, STATE, etc. Better as a unit-test layer than an integration check.
3. Backend-driven assertion: extend existing pytest by hitting /api/search?q=...&tag_filter=... and asserting the param shape that the frontend should send. Catches API contract drift but not the actual click → request wiring.

Option 1 + Option 3 together would give the most coverage; Option 2 alone is probably enough for the tag-filter cluster.

Out of scope

• Full SPA test coverage (this is a foothold, not a sweep).
• Visual regression testing.
• Performance / load testing of the search pipeline.

Acceptance

• A new test directory (e.g. packages/memtomem/tests/web/) runs in CI.
• At minimum: regression test for _searchByTag pollutes search-input with tag text #672 — clicking a tag pill must NOT populate search-input.
• Optional: regression tests for app.js:1885 and app.js:2413 paths.

References

• _searchByTag pollutes search-input with tag text #672 / PR fix(web): drop search-input pollution from _searchByTag (closes #672) #749 — the bug that motivated this; only caught by manual review
• Allow tag-only search (relax empty-q guard in /api/search and doSearch) #750 — follow-up that lifts the empty-q guard; would benefit from same harness
• ADR-0007 — namespace UI tier precedent (similar three-site mutation pattern for namespace filter)