Take a search term literally: _ and % were live wildcards

[Exelord]

The finding

searchFilter built `%${term}%` and handed it to ILIKE, so a search
term was never taken literally. Measured on a seeded workspace:

search	returned
web_app	["webXapp", "web_app"]
%	every project in the workspace

Both scans were affected — the project scan and the
project \|\| '#' \|\| task pair scan behind the Tasks box.

The failure is over-matching only (a wildcard can never narrow), so what you
searched for is in the results — which caps the severity and is exactly
why it survives review: the answer looks right until you read it.
Underscores are ordinary in package names, so this is routine, not exotic.
And this box is the only way to reach anything past one page in a
1000-project workspace.

The sweep found the same class in core

listInvocations' --tag filter does tags LIKE ? over the serialized
JSON with the user's value interpolated raw. Measured: env=prod_us also
returned a run tagged prodXus; env=% returned every tagged run. That
reaches vx mcp's list_runs — so an AI agent filtering by tag was handed
rows that don't match the filter it asked for.

The fix

One escaper on the façade (escapeLikePattern — the
clampInt / parseDecimalInt / splitTaskId / escapeMarkdownCell
precedent, now five times). Two copies of "which characters are
metacharacters" is how the dashboard and vx mcp come to answer the same
search differently, and there is no third answer to drift toward: LIKE has
exactly two metacharacters plus the escape.

ESCAPE '\' is mandatory, not decorative, and the reason is
dialect-specific: Postgres defaults the LIKE escape to backslash, but
SQLite has no default at all — so an undeclared \% there matches a
literal backslash followed by anything, relocating the bug rather than
removing it. Both call sites declare it.

A correction to my own expectation, caught by the failure side

My first core pin asserted env=% would match a run tagged 100%. It does
not: jsonPairFragment emits the full "k":"v" pair including both
quotes, so the tag filter is exact-value (positioned anywhere in the
blob), not a substring search on the value. The pin now asserts what
actually holds — % matches only a run tagged exactly %, and 100% is
correctly not a match either.

Refuted by measurement, so nobody re-treads it

I suspected an unbounded search term was a CPU vector: textParam has no
length cap, and a %_-alternating pattern is the classic LIKE-backtracking
shape. Measured on the real query — an 801-character
'%_'.repeat(400) pattern ran in 1.0 ms. The haystacks are short
identifiers, so there is nothing to backtrack over. A length cap would be
guarding a hazard that does not exist.

Differential

Neutralising the escaper alone — leaving both call sites and both
ESCAPE clauses in place, so the escape itself is what's isolated — fails
exactly 5:

• core: the tag pin + the escaper unit
• cloud: underscore, percent, and the pair scan — a second call site
  that could have been fixed on its own and drifted

Restore byte-identical. Three controls pass both ways, and without them
"no false positives" would be satisfied by matching nothing at all: an
ordinary term stays byte-identical through the escaper, a plain app
search still matches webXapp and web_app by substring, and the escaper
never introduces a wildcard of its own (callers own the surrounding %…%).

The façade widening cost exactly one pin, as every previous one has — the
package-boundaries export snapshot, which is the guard working.

Gates (from the repo root)

• fmt 0, lint 0
• core 2660 / 0, no skip line
• cloud 1332 / 0 across 60 files, zero skips
• docs site builds clean

No CACHE_VERSION / SCHEMA / wire / migration bump: this changes which rows
a filter matches, never a key or a stored byte.

Docs shipped in the same wave — cloud/api.md's two search rows now
state that the term is taken literally and that %/_ are not wildcards.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RW7aso5j5CrBo7cjyET23D

---

Generated by Claude Code