One search across everything in a workspace: memory, published work and published wiki pages, in one place.
Before this, every store searched only itself - Artifacts matched titles, memory had its own box, a wiki had one per wiki. Which meant the question people actually have - where did we write that down - had no answer that didn't start with guessing which store it was in.
What it matches
The words that were written, not what they mean. "pricing" will not find a page that says "fee". Several words all have to appear; put a phrase in quotes to keep it together.
That's a deliberate division of labour, not a limitation we're apologising for:
- You search for a word you remember somebody using.
- Your instances use recall, which matches meaning and returns full content with provenance, in one call, mid-session.
If you find yourself fighting the search, the answer is usually to ask your assistant instead - it has the better tool.
Results are grouped, not blended
Hits come back in three groups - Memory, Wiki pages, Published work - rather than one ranked list.
That's on purpose. Memory and published content live in separate indexes with different weightings over different corpora, so a single ordering would be comparing two relevance scores that aren't on the same scale. It would look authoritative and be arbitrary. Grouped, you do the comparison, which you can actually do.
Results show the passage that matched, with the matching words marked, so you can judge relevance without opening each one. Every result carries its date and its project, because a shared store accumulates contradictions - two decisions about the same component, months apart - and without a date there's no way to tell which one is current.
What it never returns
- Drafts. An unpublished wiki page is not searchable - not to your teammates, and not to its author either. A result only you can open is a trap, and an author who finds their own draft assumes the team can too.
- Anything you can't already see. Private projects, author-private items and restricted wiki sections are excluded by exactly the same rule that hides them everywhere else. The search index ranks results; it never decides who gets in.
- Deprecated memory. Recall stops surfacing it, and a search that quietly disagreed with recall would be worse than either.
Counts, and what they mean
A group header reads "first 25 of 32" where the total is known, or "first 25, there are more" where it isn't. A bare number would be ambiguous - 25 is exactly the sort of round figure that's really a page size - and reading a cap as a total is how you conclude a workspace holds 25 of something when it holds 300.
Each group offers "see all", which hands you to that store's own search - memory, the wikis or Artifacts - where the same query runs with filters and paging. This screen's job is telling you which store to look in; once you know, the store's own surface is the better one.
From an assistant or the CLI
There's no single search tool over MCP, because recall is the better answer for an instance: it spans memory and published work already, matches meaning rather than spelling, and comes back with content and provenance attached.
For scripts, each store is addressable on its own:
kythe recall --search "migration runner" # memory + published work, by meaning
kythe timeline "migration" # published work, by word
kythe pages handbook # a wiki's tree