PROTECTED_GLOSSARY exists to preserve short technical terms that generic
filtering would discard, but every glossary match still flowed through
normalizeConceptToken's per-script minimum-length gate. The 2-char latin
entries "kv" and "s3" were therefore never emitted as concept tags despite
being on the protect-list. Thread a fromGlossary flag so glossary matches
bypass only that length check; all other gates still apply.
Because that bypass lets short entries through, a bare substring match would
also surface them from inside longer words ("kv" in "mkv", "s3" in "css3").
Match ONLY the short entries (those below their script's min length) as
delimiter-bounded whole tokens; longer entries keep substring containment, so
the shipped behavior of "backup" tagging inside "backups" is preserved. CJK
entries (no word delimiters) always use substring matching. Positive
(standalone kv/s3) and negative (mkv/css3 substrings) regression tests cover
both directions, and the short-term-promotion stable-tags assertion gains "s3".
Co-authored-by: ly-wang19 <ly-wang19@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore(release): close out 2026.6.10 on main
* chore(release): align native app metadata for 2026.6.10
* chore(release): sync Android 2026.6.10 notes
* docs(changelog): preserve 2026.6.9 history
* docs(changelog): preserve 2026.6.9 history
The initial fix threaded the abort signal through the direct qmd
(runQmd/runQmdSearch) path, but the mcporter / QMD 1.1+ daemon search path
(runQmdSearchViaMcporter, runMcporterAcrossCollections) never received it, so
a grouped/mcporter search left its subprocess running on abort.
Thread the search signal through QmdMcporterSearchParams,
QmdMcporterAcrossCollectionsParams, all four mcporter call sites in search(),
and runMcporter, down to the shared runCliCommand spawn (which already
SIGKILLs the child on abort). Guard runQmdSearchViaMcporter on an
already-aborted signal so the multi-collection loop stops spawning. Reuses the
existing abort mechanism; no new machinery. Adds mcporter-path regression tests.
memory_search timeout cancellation only reached single-group direct qmd
searches. Multi-collection or mixed memory/session configs route through
runQueryAcrossCollectionGroups, which still called runQmdSearch without the
caller signal, so an aborted memory_search left the grouped qmd child running
until the qmd command timeout instead of being killed promptly.
Thread searchSignal through the grouped search path and its unsupported-option
fallback, and add a grouped multi-collection abort regression asserting the
spawned qmd child is SIGKILLed when the caller signal aborts.
PR #91742 wired memory_search's 15s deadline AbortSignal through the builtin
memory manager but missed the QMD backend behind the same
MemorySearchManager.search interface. With QMD, the tool returns "timed out
after 15s" to the agent while the spawned qmd query/search subprocess keeps
running for the full qmd command timeout (memory.qmd.limits.timeoutMs, whose
embed-heavy default was raised to 600s in #87572), leaving orphaned
embedding/search work running after the agent already moved on.
Add optional AbortSignal support to runCliCommand: an aborting signal kills the
spawned child immediately and rejects with the abort reason, funneled through a
single settle() guard so abort/timeout/error/close cannot double-settle. Thread
the search signal through QmdMemoryManager.search -> runQmdSearch -> runQmd ->
runCliCommand for the default direct-qmd subprocess path (including the query
fallback), and fast-fail search() when the signal is already aborted.
* fix(memory-core): report active dreaming phases in status
* fix(memory-core): repair active dreaming status phases
---------
Co-authored-by: openclaw-clownfish[bot] <280122609+openclaw-clownfish[bot]@users.noreply.github.com>
* fix(memory): await search-sync before returning results to prevent stale index
When the gateway process has been running for a while, memory_search
returns stale results because startAsyncSearchSync fires off the index
sync as a background task (void ... .catch()) without waiting for it
to complete. Search results are then read from the old index state.
Change startAsyncSearchSync from sync/fire-and-forget to async/await
so that the index is synced before search results are returned. This
ensures memory_search reflects the current filesystem state, matching
the behavior of the CLI command which creates
a fresh manager each time.
Fixes#52115
* test(memory): prove search waits for dirty sync
* test(memory): align search with synchronous sync
---------
Co-authored-by: Vincent Koc <25068+vincentkoc@users.noreply.github.com>
