Intelligence · Lens
Lens is the code-intelligence plane underneath your agents: lexical, structural, semantic, and graph search over the refs your organisation has admitted. Every result carries its path, its ref, its commit, how fresh the index was, and which plane served it — so an answer can never quietly be about a different version of your repository than the one you are working in.
A repository is admitted once. Lens indexes it four ways, and the ref topology binds every index to a specific commit. A query fans out across the planes and comes back as one ranked, cited answer — pinned to the ref it was true on.
zephr_grepugrep-class literal and regex search across every admitted ref — the plane that never hallucinates because it never interprets.
zephr_lspTree-sitter and LSP symbol resolution: definitions, references, call sites, and enclosing scope rather than string matches.
zephr_searchCode embeddings for the questions no grep answers — "where do we enforce this", not "where does this string appear".
zephr_searchImport, ownership, and ref edges, so a result can say what depends on it and which branch it was true on.
Ref topology is what keeps the other three planes honest across branches: without it, a result from a stale index is indistinguishable from a current one. It is planned, and until it lands, Lens answers say so on the record rather than in a footnote.
This is the shape of a Lens answer — real markup, not a screenshot. Select it, copy the commit, read it with styles off. Note what the answer refuses to hide: the plane that served it, the ref it was pinned to, and the one hit whose file moved after indexing.
A plain-language question, not a regex. Lens resolves it against the planes it can actually serve right now and reports which one that was.
Hosted Lens is not serving this repository yet, so the query fell back to local Lens. That is a different answer with different freshness, and the card says so before you read a single result.
Route middleware rejects an unauthenticated request, and scope admission rejects an authenticated request that is not bound to the project it is reaching into. An answer that named only the first would be true and useless.
Illustrative example — not live data
Cloud-first Lens is the design commitment (ADR-028). Local Lens is the part you can run today. The gap between them is a build, not a footnote — so it is listed here at the same size as everything that works.
The full tool surface served by zephrd from the machine the code is on. No source and no embeddings leave the host.
Literal and regex search with path, ref, and line-range citations on every hit.
Tree-sitter parsing plus language-server symbol resolution for definitions, references, and enclosing scope.
Vector substrate (Qdrant) is in place and capacity-tested. The hosted embedding pipeline, and the provider gates it needs, are not built.
Admitting a repository once and having every machine query the same index. This is the missing piece of cloud-first Lens — not a slow one.
Import, ownership, and ref edges as first-class query targets (ADR-028).
Querying a local working ref against the hosted index, so uncommitted work is visible without publishing it (ADR-029).
Each answer states whether it came from the hosted index or local Lens, at which ref and generation, and how fresh that index is.
Status labels follow docs/PRODUCT-DESIGN.md. "Shipped" means substantially implemented; "Evolving" means real foundations with active work remaining; "Planned" means designed and not yet built.