Summary

memory_search falls back to the builtin index whenever the query contains hyphenated tokens (e.g. sqlite-vec, 2026-05-04, multi-agent). The root cause is in qmd (tobi/qmd#414, tobi/qmd#618), but OpenClaw amplifies the impact: a single sub-search validation failure aborts the entire qmd.query response, taking down lex even though lex doesn't care about hyphens.

Reproduce

memory_search(query="sqlite-vec backend health")
# → returns provider:"none" with fallback.reason mentioning validation

Root cause chain

1. qmd's validateSemanticQuery regex /-\w/ flags any -X as a NOT operator, including word-internal hyphens.
2. OpenClaw's memory_search runs lex + vec + hyde in parallel via buildV2Searches().
3. Any sub-search validation error → the whole qmd.query returns isError: true.
4. OpenClaw treats that as fatal → falls back to the builtin lex index.
5. Result: lex (which would have worked on the raw query) is also lost.

Code refs (in the bundled CLI):

• tools-B3jFTrn6.js:324
• qmd-manager-D-Df6uBI.js:1184-1212 — buildV2Searches(), no sanitization before dispatch.

Impact

• ~26× slower memory recall (builtin vs qmd vec, measured locally)
• Loss of semantic ranking
• Affects any query mentioning version strings, dates, or dashed identifiers — extremely common in dev/ops contexts

Suggested fix

Sanitize the query for vec/hyde paths only; keep the raw query for lex:

const semanticQuery = rawQuery.replace(/(\w)-(\w)/g, '$1 $2');
// vec & hyde use semanticQuery; lex uses rawQuery

This decouples OpenClaw from the upstream qmd fix timeline. Once qmd ships #618, the workaround becomes a no-op.

Alternative

Make qmd validation errors non-fatal at the OpenClaw layer: log and skip the failing sub-search, return whatever the others produce. This is more general and handles future qmd validation regressions too.

Environment

• OpenClaw 2026.5.7 (eeef486)
• qmd 2.0.1
• macOS (Darwin 25.3.0 arm64), Node v24.14.1