Browse docs

← All docs

docs / features-orientation.md

Orientation and project shape

These answer the questions you'd ask on your first day in a codebase, and the ones you ask again after two weeks away. They describe the project as a whole rather than any single file.

Getting your bearings

Project orientation — a state-of-the-union for the repository: what it is, how it's laid out, and where the important surfaces are. The right opener when your assistant has never seen the project, or when you're the one who's new.

Entry points — where execution actually begins: runtime bootstrap, framework wiring, the route surface, test runtime. Useful when a project has six plausible-looking main files and only one of them runs.

Indexed repositories — which repos are indexed on your account, and how current each one is. Worth checking when an answer looks like it came from the wrong project.

The surfaces a project exposes

Routes — indexed HTTP routes with their method, handler, and location. Answers "what does this service expose" without reading a router file top to bottom.

GraphQL handlers — queries, mutations, data fetchers and subscriptions, each with the code behind it.

Persistence statements — ORM-mapped statements with their SQL kind and the tables they touch, for projects where the queries live in mapper files rather than inline.

Database schema — every table and column. Your assistant should read this before writing a model, a migration, or a query, rather than inferring column names from how they're used.

What changed

Catch-up briefing (Pro+) — a structural summary of what moved since you last looked. Not the commit log: what actually changed shape. This is the "I've been out for a week" tool.

Last diff (Pro+) — the structural delta from the most recent index update, for when you want the shape of the latest change specifically.

Whether to trust the index

Two signals, both worth understanding before you rely on an answer.

Coverage map — how much of the repository the index actually covers. Coverage gaps are where confident wrong answers come from.

Vital sign (Pro+) — a single 0–100 score for the structural health of the index.

Parse errors — files the indexer couldn't fully read. A file that failed to parse is invisible to symbol search, which makes this the first place to look when your assistant insists something doesn't exist.

Note — a parse error doesn't mean your code is broken. It means the indexer couldn't build a symbol map for that file, so search can't see inside it. Index issues covers what to do.

Next: Search and lookup.