Memory map and code graph
The Memory Browser has two sections. Memory shows what the workspace knows. Graph shows the code that knowledge is about, laid out the same way.
Memory
Three views over the same fragments, with a search rail beside them for filtering by type, freshness, and date range.
| View | Shows |
|---|---|
| List | Fragments ranked, with type, confidence, and referenced files. The view to search in. |
| Timeline | Fragments in the order they were learned. The view for "what did we decide that week". |
| Map | Every fragment as a point in two dimensions, clustered into topic islands. The view for "what does this workspace know, roughly". |
Selecting anything opens a detail drawer with the full content, a confidence meter, its tags, the source it was stamped with (the files and commit), its version history, and related fragments. From there you can edit it, merge it with a near-duplicate, or delete it — and the browser as a whole lets you add a fragment by hand or run a dedupe pass over the whole store.
How the map is drawn
The map is not a metaphor — it's the actual embedding space, flattened.
- Projection: PCA down to two dimensions, computed by power iteration so the full covariance matrix is never formed. On a store of any realistic size this is cheap.
- Clustering: k-means with k-means++ seeding, run over the 2-D coordinates rather than the original vectors, so the islands you see are the islands the algorithm found — the layout and the grouping can't disagree.
- Stability: a fixed-seed RNG, so the same store always projects to the same picture. Your mental map of it survives a reload.
Distance means similarity. Two fragments near each other are about the same thing, whether or not they share vocabulary.
Code graph
The Graph section is a semantic index of the workspace's symbols, and it answers the question plain search can't: "how does auth work" — where the answer is a set of functions none of which contain the word "auth".
How it's built:
- Enumerate the workspace's source files.
- Pull each file's structural symbols from the language server — the same request an outline view uses, noise-filtered.
- Embed a short descriptive text per symbol.
- Answer a query by nearest-neighbour against those vectors.
Indexed kinds are the structural ones: function, method, class, interface, enum, struct, namespace, and module, each with its own colour in the legend.
Call edges
Select a node and its call edges are drawn — callers by default, or outgoing calls, to a depth of up to three. These are computed live from the language server rather than stored, so they reflect the code as it is right now. If the language server can't answer, the graph degrades to an empty edge set with a reason rather than an error.
One visual language
The code graph is laid out with the same projection and clustering primitives as the memory map — same PCA, same k-means, same fixed seed. That is deliberate: two maps that mean the same thing by "near" and "island" can be read with one set of habits, and put the workspace's knowledge and the workspace's code side by side without translation.
Next
- Configuration and sharing — embedders, and getting this to your team.