fix: merge dream and normal memory search

[compoodment]

Summary

• Search the regular session/user/global collections for dream queries instead of replacing them with the dream collection.
• Search the dedicated dream collection alongside ordinary memory, then merge by score, deduplicate by record ID, and cap the combined result to the requested limit.
• Forward kind and signals filters to the dream search path.

Root cause

Dream routing used an exclusive ternary: once a dream signal was active, it called only searchText for dream:<user> and skipped searchResolvedCollections. That suppressed all relevant ordinary memory and also dropped structured filters.

Impact

Dream-related queries can now retrieve both promoted dream entries and related normal memories. An empty dream collection no longer makes an otherwise valid memory query return no hits.

Verification

• pnpm exec tsc --noEmit
• pnpm run clean:test && pnpm exec tsc -p tsconfig.tests.json && node --test .ts-build/test/unit/memory-runtime.test.js — 18/18 passed
• pnpm check — reached the full unit suite; 218/220 passed, with two pre-existing failures in slot-conflict.test.ts caused by stale expected tool lists on main
• git diff --check

Fixes #347.

– Vale

[coderabbitai]

Warning

Review limit reached

@compoodment, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4c08a273-3ee9-4955-902e-eadc83868eff

📥 Commits

Reviewing files that changed from the base of the PR and between 96467dd and 2788016.

📒 Files selected for processing (2)

• src/memory-runtime.ts
• test/unit/memory-runtime.test.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[compoodment]

Vale Review — PR #366

Quality: Q4/5 — sharp
Head: 2788016

Findings:

• src/memory-runtime.ts:255 — mergeSearchResults() deduplicates the dream and normal result streams by bare item.id, so a dream result and a normal/session/user result with the same record id collapse into one hit. This reintroduces the collection-collision class the repo already had to fix elsewhere, and it means a dream query can still hide relevant ordinary memory even though the PR is supposed to merge both paths. major

Proof gaps: No local gate run; needs a regression where dream: and user: or session: return the same id with different text/collection and both survive the merge.

Verdict: request-changes — merge dedupe needs a collection-aware key, not bare record id.

– Vale
use @vale review