Local dashboard

This is the self-hosted dashboard: it runs on your machine from the open-source CLI. If you use repowise.dev, the hosted dashboard is described in Dashboard tour.

repowise serve gives you a local dashboard over the index you already built. It reads the same .repowise/wiki.db that the CLI and the MCP server read, so nothing leaves your machine, and no view calls an LLM unless you click something that says it will (Chat, refactoring code generation, doc regeneration).

repowise serve                  # API on :7337, web UI on :3000
repowise serve --port 8000 --ui-port 3001
repowise serve --no-ui          # API only, no dashboard

serve starts the API and the web UI together. See Server and watch for every flag.

The URL shape is /repos/<repo-id>/<view>. Every view is directly linkable, tab state included, so a link you paste into a PR lands on exactly what you were looking at.

What works without an API key#

Without a model, repowise init --no-prose (or Enter on the plan screen) builds the documentation from code. Everything derived from the AST, the dependency graph, and git history works either way. The views that read written pages are the difference:

An index built from code has documentation, so the Docs views are populated. It lacks written documentation and semantic search: repowise generate adds the first, and repowise reindex --embedder <name> the second. An Index only repo (init --mode fast) has no documentation until repowise update --full builds it. Every upgrade works in place, with no re-index from scratch. See Deterministic wiki.

The views#

The repo sidebar groups the views by the question you bring: Overview and Chat at the top, then Understand, Code quality, People & History, and Settings. Each group folds away, and the group holding the current page stays open.

Overview#

The landing view opens on one health reading and a folded Do next with its count in the heading: actions, each with a reason, an effort bucket, and what done looks like. Dismiss, snooze, and done are remembered per action, and repowise next on the CLI is the same list.

Below it, an ask box offers questions drawn from the repository, and six Explore cards lead to the other pages with figures that match the pages they open. A live banner shows while an index or generation job is running, with its progress and log stream.

Docs#

The generated wiki: a page tree on the left, the rendered page in the middle with mermaid diagrams, code blocks that link into the file views, a confidence badge, a freshness indicator, backlinks, and a regenerate action for a single page. Reader personas re-filter the prose for the audience you pick. Human notes you attach to a page survive regeneration. Doc drift (/repos/<id>/docs/drift) lists the markdown references (paths, links, headings, commands, symbols) the tree does not has; see Documentation drift.

Present mode lives behind a button in the docs header. It turns the wiki you already generated into a short, full-screen, keyboard-driven deck. Nothing is generated for it: the deck is built from the overview and a handful of module pages, so there is no LLM call and no extra cost. The button appears only when the repo has a repo_overview page, and the state lives in the URL (?present=deck), so a deck link is shareable.

The deck tells one story in a fixed order: a title slide, the overview's architecture diagram, one slide per major part of the docs tree (up to six), one flow end to end when a sequence diagram exists, and where to start reading. Every slide drawn from a page links back to it, and a stale source page is marked. This is the fastest way to hand a repo to a new joiner.

Doc freshness#

A coverage donut, a drift banner when generated pages fall behind the commits they describe, a per-page freshness table, and a confidence-by-freshness matrix that separates "we were never sure about this page" from "we were sure and the code has since moved". Use it to decide what to regenerate instead of regenerating everything.

Architecture#

Four tabs, each a dataset, not a zoom level. Behind ?view=:

All of it is computed from the parse and git history, so it works on a keyless index.

Knowledge Graph#

A continuous-zoom canvas over the full graph: repo at the top, then modules, files, and symbols as you zoom, rendered by a custom camera and culling engine so it stays smooth on large repos. Deep-link with ?focus=<node> to land zoomed on one node. /c4 and /zoom URLs open here. The export menu downloads the architecture as Structurizr DSL; see Architecture diagrams.

Code Health#

Tabs behind ?tab=:

Test coverage and security findings have their own Tests and Security pages, and a change's blast radius is the Commits page's Review a change view. Old ?tab= links redirect there.

The folder map is a zoomable canvas that draws each directory inside its parent, with health rolled up at any depth, and opens areas into files as you zoom. Lenses switch it between score, churn, main author and knowledge risk. A scope note says how many files the map shows and what it holds out, and a context rail beside the map explains the area you are looking at. Hotspots are counted, searched and paged over the whole set.

Clicking any file opens the health drawer. It opens on the score, one plain sentence and the top three issues with their vital signs, and what the score lost to code shape, change history and test coverage, with one primary action; the markers, file signals (owners, churn, dependents), score trend and bug history sit below. The drawer is non-modal, so the map stays usable while it is open.

Every language is served. On a language whose layer is still being measured, findings carry a Preview badge whose tooltip gives the latest hand-judged measurement. The scoring model is documented in Code health.

Refactoring#

A board of structured plans (Extract Class, Extract Helper, Move Method, Break Cycle, Split File). Each card shows its split groups, the evidence that justifies it, its impact delta, an effort bucket, and the blast radius that has to move with it. Filter by type with ?type=. Two actions per card: copy-to-agent, which produces a prompt you can hand to a coding agent, and Generate code, an opt-in LLM expansion into code plus a unified diff. Everything except that last button is deterministic. More in Refactoring.

Files and Symbols#

Files opens on a treemap of the repo sized by code volume and colored by health band, so where the risk sits is one glance, not a sorted table. Drill into a file for its tabs: overview, its generated doc page, health, coverage, graph neighborhood, and history. /repos/<id>/modules/<path> is the same idea one level up.

The symbol index (/repos/<id>/architecture?view=symbols) has filters for kind, hot files, and a Bug-fixed facet that keeps only symbols with a counted bug fix inside the window. Each row carries a fix chip when it has one. The symbol detail page and drawer show the signature, the call graph around it, modification count, and a Bug fixes tile. That contrast, how often a symbol changes against how often it breaks, is the part worth reading.

Search, Commits, Ownership, Decisions#

Search covers full-text, symbol, and semantic search over the index, scoped to one repo or the whole workspace. Semantic results need a configured embedder; symbol and full-text search work on any index.

Commits has a History view switch with four views:

Ownership opens on knowledge coverage and risk: the truck factor, single-owner files, silo modules, and quiet owners (no commit in 90 days, still owning files that changed). A knowledge matrix lists each code file's top people with their share of its commits, for off-boarding what-ifs, and a per-person profile shows what they own. Ownership counts people only.

Decisions shows architectural decisions with their evidence drawer and a decision graph. Decisions are mined from history and PR discussion, and can be confirmed, edited, or added by hand.

Chat#

Ask questions against the indexed repo. Answers cite the pages and files they came from, and you pick the model from the provider's live list. Chat is the one view that always costs LLM tokens.

• Charts in one call. Ask for any chart of your files, findings, changes, health trend, coverage, dead code, dependencies or layers, as bars, lines, areas, donuts, treemaps, heatmaps, scatter or stacked charts. Tables and charts are built on the server from the turn's tool results, so every plotted number comes from a result. Each chart keeps a text summary, a Data toggle and a basis line, and empty chats suggest a chart that fits.
• Every figure is checked. Each number an answer states is looked up in that turn's results. A figure no result holds is marked with a dotted underline, a tooltip and screen-reader text.
• Chats print as documents.

Settings, models and sync#

Repo settings take a provider, a model and a base URL, with presets for local servers and a Test connection button. The model field lists the provider's live models, accepts any typed id, and shows where each value comes from. An OpenAI-compatible server on this machine (LM Studio, Ollama, vLLM) needs no API key, and an unconfirmed base URL from config.yaml offers Trust this URL. Choosing a model or base URL for a repo writes that repo's .repowise/config.yaml; /settings holds the global default.

Sync and full re-index show their progress. A failed or partial run stays on screen with the reason (a rejected key, a rate limit, an unreachable base URL or a missing model) and Retry, Provider settings and Dismiss actions.

What's new#

After a minor upgrade the dashboard opens What's new once, with the release summary, a By the numbers ribbon, the highlights with links into the current repository, and every change by section. A patch shows a short note. Highlighted pages carry a New mark in the navigation, and the upgrade banner names the next release's top highlights. See Upgrading.

Workspace views#

These appear only when repowise is running over a multi-repo workspace. See Workspace setup.

Keyboard#