Admin console · animated

Click to expand

Codebase Atlas — /explore

The Explore page turns the raw indexed source files into a visual, navigable map of how your project is architecturally structured. It is the fastest way to answer “where does X live?”, “what imports what?”, and “which layer handles this concern?” — without opening your editor.

Tab groups

The page is organized into three rails (URL ?tab=):

MCP equivalents: ask_codebase, get_file_summary, get_codebase_tour, search_codebase, get_codebase_domains, analyze_codebase_impact, analyze_wiki_knowledge, get_repo_digest (on the default feature set; needs no index).

Copy digest

Copy digest (top of the page) copies your repo as one paste for an AI chat or coding agent: the folder tree plus the most useful files, in this order — README, manifests (package.json, …), entry points, source, then tests. Pick a size first; the digest stops at that many tokens (an estimate: characters ÷ 4) and says what it left out.

• It reads GitHub at one commit and names the commit, so the paste matches a real version of your code.
• Real env files (.env, .env.local, .env.production), private keys and similar files are never included. Env templates such as .env.example are included, because they explain the setup. Any file that looks like it holds a secret, templates too, is replaced with a notice.
• On a bug report, Copy code for this bug puts the bug’s files first: files from its stack trace, files earlier fixes changed, related code from the index, then the files that import them.

The same digest is the MCP tool get_repo_digest, on the default tool set.

Map views

Diagram

An AI drawing of the main parts of your app and how they connect. Mushi reads the repo on GitHub at the latest commit and asks the AI for the parts, their folders or files, and the links between them. Then Mushi checks every path against the real repo: a path that does not exist is removed and the part is marked, so a made-up file never becomes a link.

• Draw diagram costs one AI call. Diagrams are stored per commit and never redrawn on their own, not even on a push: that would spend an AI call on commits that change nothing, and a public page must only show what you previewed. Update to latest commit draws only when there is a new commit; Redraw asks the AI again.
• Click a part to read what it does and open its folder or file on GitHub at that commit.
• Badges on each part count its open bug reports and its code findings from the last 30 days. Click the part to list them: reports open their detail page, findings open the file and line on GitHub. A report lands on a part through its stack trace or the files its fixes changed; reports and findings in files no part covers are counted under the diagram.
• Public page (optional, owner or admin): share the diagram at kensaur.us/mushi-mushi/r/<owner>/<repo>. The preview shows exactly what becomes public: part names, descriptions and paths, never file contents. A private repo needs you to tick a consent box first. The page shows the commit it was drawn from, keeps showing that drawing until you publish again, and Unpublish removes it. Visitors can report a wrong or unwanted diagram privately: the report goes to Mushi’s own inbox, never to a public issue. Once live, the card gives you a README badge to copy and a Markdown copy of the page for AI agents. Search engines index the page.
• From your editor: the MCP tool get_repo_diagram returns the latest diagram; pass overlay: true to also get the open reports and findings on each part. It reads the stored drawing and never draws a new one.
• With an API key: the preview, publish and unpublish routes take a key with mcp:read (preview) or mcp:write (publish, unpublish) as well as the console session. A key can publish a public repo’s diagram. A private repo’s diagram can only be published from the console, because the consent box is a person reading the preview.

Graph

A ReactFlow canvas laid out in deterministic swimlane columns (one column per architectural layer), with every file as a node coloured by layer. Nodes are freely draggable within the canvas:

Each node chip shows:

• Left accent bar in the layer colour
• Filename truncated to fit
• File extension badge (.tsx, .ts, .py, …)
• Directory context (last two path segments) below the filename

Import edges are drawn as directed arrows. Hover a node for its full path tooltip. Click a node to open the detail panel on the right.

Controls:

• Drag — pan the canvas
• Scroll — zoom in/out
• Layer legend (bottom-left) — expands to show counts and a proportional fill bar per layer
• File/edge counter badge (top-left)
• Zoom in / Zoom out / Fit view (bottom-right)

Layers

A horizontal Sankey flow that groups files left-to-right: UI → Library → Backend → Tests → Config → Other.

Each column shows:

• Layer name and file count in the layer’s colour
• A proportional fill bar (wider = more files relative to the largest column)
• Hub node — the file with the highest import degree in that column (most-imported or most-importing)
• File cards with filename, .ext badge, and line count

Import edges are drawn as bezier curves with directional arrows between columns. This makes cross-layer dependencies immediately obvious.

Click any file card to open the detail panel below the lane.

Search

Semantic search over vector embeddings. Type a natural-language description of what you’re looking for — the search finds the most relevant files and symbols ranked by cosine similarity.

Layer filter tabs appear after a search to narrow results to a single architectural layer (e.g. “Tests only” or “Backend only”). Click the layer chip, or click All to clear the filter.

Each result shows:

• Symbol or filename in monospace
• Layer badge
• File path
• A colour-coded similarity bar (green ≥ 70%, amber ≥ 50%, red below 50%)
• Content preview (first 240 characters of the indexed content)

Click a result to open the detail panel. Click the panel’s View in graph button to switch to Graph view with that file selected.

The detail panel

Clicking any node (in any view) opens a detail panel with:

Layer filter chips

The Filter: row above Map views lets you narrow Graph, Layers, and Search simultaneously. Click 64 Tests and the graph shows only test nodes and their inter-test edges, the Layers lane collapses to just the Tests column, and Search results are pre-scoped to Tests.

Click the chip again (or Clear) to restore the full view.

Stats bar

Below the page title:

115 files · ts, tsx, js · Indexed via Mushi SDK

Shows total indexed file count, top languages detected by extension, and the indexing source.

Density toggle

Switch between Files (one node per file) and Symbols (one node per exported function, class, or constant). Symbol mode gives a much denser graph suited for large codebases where you want to trace a specific function’s callers.

Indexing

npm install -g @mushi-mushi/cli

mushi index

How much of a large repo is indexed

Your plan sets how many files the index may hold: 300 on the free plan, and more on paid plans. The hourly sweep fetches files in batches, starting with the files named in open error stack traces and your application source. It keeps going until the whole repo or the plan limit is covered.

The Codebase indexing card shows coverage in files, for example 1,500 of 4,700 files, in one of four states:

• all: every indexable file is in the index.
• still filling: later sweeps will add more files.
• plan limit: the limit is reached. Diagnoses and fixes only see the indexed files. A path filter limits the sweep, and the count, to the directories that matter.
• stuck: the last sweep could not add a file, for example because GitHub kept refusing a file or the embedding API kept rejecting it. The card shows the error. The sweep retries daily instead of hourly.

The path filter is the repo’s path_globs, the same globs the fix worker uses to pick its target files. They limit indexing too: a sweep indexes only matching files, and removes files a narrowed filter no longer matches from the index (unless the project indexes more than one repo, since they share one index). **/ also matches the repo root, so **/*.ts includes index.ts and src/**/*.ts includes src/a.ts. If you set globs on a repo only to route fixes, check that they cover the code you want diagnoses to see.

“Last sweep” counts partial sweeps too. A partial sweep is never shown as a complete index. Pushes count against the plan limit as well: a push re-indexes files already in the index, and adds new files only while the index is under the limit.

What the search understands

The semantic search uses the same embeddings that power RAG-augmented bug review and fix suggestions. It understands:

• Concepts: “authentication and session handling”, “rate limiting”, “error boundary”
• Patterns: “component that wraps children with a loading state”, “hook that fetches paginated data”
• Behaviour: “where payment processing happens”, “what sends the push notification”
• Cross-language: works across TypeScript, Python, Go, Swift, Kotlin, and any other language with indexed content

It does not understand:

• Exact symbol names (use your editor’s Go-to-symbol for that)
• Regex or glob patterns
• File system structure queries (“all files in src/screens/”) — use the Graph or Layers view instead

API reference

The Explore page is backed by two project-scoped REST endpoints:

GET /v1/admin/projects/:id/codebase/explore

Returns the full graph payload.

Query parameters:

Response:

{
  "nodes": [
    {
      "id": "uuid",
      "node_type": "code_file",
      "label": "auth-guard.tsx",
      "metadata": {
        "file_path": "components/auth-guard.tsx",
        "symbol_name": null,
        "signature": null,
        "line_start": 1,
        "line_end": 142,
        "language": "tsx",
        "layer": "ui",
        "content_preview": "export function AuthGuard({ children, ..."
      }
    }
  ],
  "edges": [
    {
      "id": "uuid",
      "source_node_id": "uuid",
      "target_node_id": "uuid",
      "edge_type": "imports",
      "weight": 1
    }
  ],
  "layers": { "ui": 12, "lib": 3, "test": 64, "other": 36 },
  "total_files": 115
}

POST /v1/admin/projects/:id/codebase/search

Semantic search over vector embeddings.

Body:

{
  "query": "authentication logic",
  "k": 20
}

Response:

{
  "results": [
    {
      "id": "uuid",
      "file_path": "components/auth-guard.tsx",
      "symbol_name": "AuthGuard",
      "signature": null,
      "line_start": 1,
      "line_end": 142,
      "content_preview": "export function AuthGuard...",
      "layer": "ui",
      "similarity": 0.87
    }
  ],
  "query": "authentication logic"
}

Similarity scores range from 0 to 1. Scores above 0.7 are usually highly relevant. Below 0.3 is coincidental overlap.

Troubleshooting