fix(memory): handle mem_src scopes in retrieval

[hobertrand-hub]

Summary

• treat mem_src:<source_id>:<item> scopes as document/source scopes during source retrieval
• allow fast retrieval source filters to match both exact tree scopes and mem_src collection ids
• add coverage for mem_src document scope classification

Why

OpenHuman stores reader-backed source trees with scopes such as mem_src:src_vault_hob_local:path/to/note.md. Source-scoped retrieval can be asked for the collection id (src_vault_hob_local), so TinyCortex needs to recognize the collection id embedded inside the composite mem_src tree scope. Without this, host source retrieval can miss indexed summaries even when the source is correctly ingested.

Current state (updated)

Upstream #125 already shipped the source_scope_allows / extract_mem_src_id implementation and the source.rs kind classification on main. This branch has since been merged with main and is conflict-free. The surviving delta vs main is the end-to-end fast_retrieve regression test (dense_fallback_filters_by_mem_src_collection_id in fast_tests.rs) that exercises the collection-id-only source_scope path through the dense retrieval pipeline — the piece #125's unit-only coverage did not include.

Validation

• cargo fmt --all -- --check clean
• cargo test --lib memory::retrieval — 99 passed / 0 failed
• cargo test --lib dense_fallback_filters_by_mem_src_collection_id — passes

Relation to PR #123

This is a focused PR for only the mem_src retrieval fix. The same change was previously pushed onto the broader legacy chunk repair branch in #123, but keeping it separate makes the OpenHuman source-retrieval dependency easier to review and merge independently.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 42d171d0-dedf-438e-9fa6-0f9f3693a7fe

📥 Commits

Reviewing files that changed from the base of the PR and between c0ab3f7 and dc25008.

📒 Files selected for processing (1)

• src/memory/retrieval/fast_tests.rs

---

📝 Walkthrough

Walkthrough

The PR adds an asynchronous retrieval test for dense fallback scope filtering. The test verifies that a bare Mem_Src collection ID matches the inserted note and that a different collection ID returns no hits.

Changes

Dense fallback scope filtering

Layer / File(s)	Summary
Collection ID filtering coverage src/memory/retrieval/fast_tests.rs	Adds a test that validates matching and non-matching Mem_Src collection IDs during dense fallback retrieval.

Estimated code review effort: 2 (Simple) | ~5 minutes

Possibly related PRs

• tinyhumansai/tinycortex#125: Implements the source_scope_allows behavior covered by this retrieval test.

Poem

A rabbit checks the scope with care,
One matching note is waiting there.
A different collection finds no trace,
Dense fallback keeps its proper place.
Hop, hop—tests now guard the case!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: fixing retrieval handling for mem_src scopes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

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.}

[hobertrand-hub]

Ready for review. This is the focused mem_src retrieval fix split out from #123 so OpenHuman source-scoped retrieval can depend on a small, independently reviewable TinyCortex change.

[greptile-apps]

Greptile Summary

This PR fixes source-scoped retrieval for OpenHuman reader-backed trees whose tree scopes are composite mem_src:<collection_id>:<path> strings, so that a caller supplying only the collection id in source_scope still gets matching hits.

• fast.rs: Replaces direct HashSet::contains calls in resolve_local and dense with a new source_scope_allows helper that additionally extracts and checks the collection id embedded in a mem_src: scope.
• source.rs: Extends scope_matches_kind to recognise any mem_src: prefixed scope as document kind.
• source_tests.rs: Adds a targeted assertion for the new mem_src: case; the equivalent end-to-end path through fast_retrieve is not yet tested.

Confidence Score: 4/5

Safe to merge — the change is strictly additive and correctly widens the match condition without breaking existing exact-scope filtering.

Both changes in fast.rs and source.rs are narrow and well-motivated. The logic in source_scope_allows and extract_mem_src_id is correct for the stated format. The main gap is that the new extract_mem_src_id code path has no dedicated test in fast_tests.rs, and extract_mem_src_id uses case-sensitive prefix matching while scope_matches_kind lowercases before comparing.

Files Needing Attention: src/memory/retrieval/fast.rs — the two new private helpers warrant a targeted integration test and a review of the case-sensitivity assumption.

Important Files Changed

Filename	Overview
src/memory/retrieval/fast.rs	Replaces direct HashSet containment checks with source_scope_allows, adds extract_mem_src_id; new mem_src code path is untested and has a case-sensitivity mismatch vs. source.rs
src/memory/retrieval/source.rs	Adds mem_src: prefix recognition inside scope_matches_kind so source trees with composite mem_src scopes are classified as document kind; logic is correct and narrowly scoped
src/memory/retrieval/source_tests.rs	Adds a single assertion for mem_src scope in scope_prefix_matching_known_platforms; covers the source.rs change but not the fast.rs change

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[fast_retrieve called\nwith source_scope] --> B{entity_ids\nempty?}
    B -- yes --> C[dense path:\nquery_source no filter]
    B -- no --> D{graph pairs\nfound?}
    D -- no --> E[global_occurrence\ncalls dense]
    D -- yes --> F[resolve_local\nfrom candidates]
    C --> G[source_scope_allows\nfor each hit]
    E --> G
    F --> G
    G --> H{scope.contains\ntree_scope?}
    H -- yes --> I[Allow hit]
    H -- no --> J{mem_src: prefix?}
    J -- yes --> K[extract_mem_src_id]
    K --> L{scope.contains\ncollection_id?}
    L -- yes --> I
    L -- no --> M[Reject hit]
    J -- no --> M

Loading

_{Reviews (1): Last reviewed commit: "Handle mem_src scopes in source retrieva..." | Re-trigger Greptile}