Skip to content

Latest commit

 

History

History
375 lines (271 loc) · 16.1 KB

DASHBOARD.md

File metadata and controls

375 lines (271 loc) · 16.1 KB

The dashboard

repowise serve starts the API on http://localhost:7337 and the local web dashboard on http://localhost:3000. Both read the same .repowise/wiki.db the CLI and MCP server read. 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, dashboard on :3000
repowise serve --port 8080           # move the API
repowise serve --ui-port 3001        # move the dashboard
repowise serve --no-ui               # API only

The dashboard needs Node >= 20. Without it, serve falls back to API-only.

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

Two modes, and what changes between them

Without a model, repowise init --no-prose 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:

Needs a model or an embedder Works on any indexed repo
Chat (needs a provider), semantic Search (needs an embedder) Docs, Doc freshness, Present mode, Overview, Architecture, Knowledge Graph, Code Health, Refactoring, Files, Symbols, Commits, Contributors, Decisions, Stats, Usage, Settings, all Workspace views

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.

Overview

/repos/<id>/overview

Answers: what is this repo, and what should I look at first?

The landing view. Repo KPIs (files, symbols, entry points, dead exports, health averages), an attention panel that promotes whatever currently deserves it (declining health, a stale doc set, an at-risk file), a decisions timeline, quick actions, and a live banner while an index or generation job is running. If a job is in flight, the progress and log stream here.

Docs

/repos/<id>/docs

Answers: how does this system work, in prose someone can read?

Repowise docs reader: page tree on the left, the generated repository overview in the center, with its outline and related pages on the right

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. A command palette (⌘K / Ctrl+K) jumps between pages. Reader personas re-filter prose for the audience you pick. Module pages keep the material written for search and agents (the questions a page answers, its identifiers, public API and git signals) out of the body; the Reference tab above the page shows it, and a small History card beside the page summarises owners, hotspots and fix history. You can attach human notes to a page, and those notes survive regeneration.

Present mode (the hidden one)

Inside the docs header there is a Present button. 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, fetched when you open it, so there is no LLM call and no extra cost. The button only appears when the repo has a repo_overview page. The state lives in the URL (?present=deck), so a deck link is shareable.

The deck tells one story in a fixed order:

  1. Title: the repository name and the overview's opening.
  2. How it fits together: the overview's architecture diagram, with the sentence around it. A flowchart with no edges is skipped.
  3. One slide per major part: the largest top-level sections of the docs tree (up to six, in tree order). Each shows the page's opening, its first diagram beside it, and its step-named sections as a numbered list.
  4. One flow, end to end: a sequence diagram from those pages that no earlier slide showed, when one exists.
  5. Where to start reading: each part's first recommended file, then the guided tour's stops, grouped by why they matter. When some top-level sections were left out, this slide says how many.

Prose is cut on sentence boundaries only, and tables, lists and stat lines never become slide text, so older pages give a shorter deck, not a broken one. Every slide drawn from a page has an "Open in docs" link back to it, and a stale or outdated source page is marked.

Keys while the overlay is open: → / Space / PageDown next, ← / PageUp back, Home / End first and last, Esc to close.

Doc freshness

/repos/<id>/docs/coverage

Answers: which docs still describe the code, and which have drifted?

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 rather than regenerating everything.

Architecture

/repos/<id>/architecture

Answers: what talks to what?

Repowise architecture map: every file grouped into the communities it depends on most, with a band for each strong link between communities

Four tabs, with the view in ?view=:

  • Map (default): the dependency graph. A scope switcher in the header picks the zoom: ?view=files (default) draws every file grouped into its detected community, with a band for each strong link between communities, and ?view=communities draws the communities alone. ?signal=dead or ?signal=hot lights dead code or hot files on the graph, and ?module= or ?community= narrows the file graph. Hover or select a file to see what it imports and what imports it; a node's doc page opens in a rail beside the canvas.
  • Coupling (?view=coupling): change coupling, the files that keep changing together without an import edge between them. This is the view that catches the coupling static analysis cannot see.
  • Third-party (?view=packages): the declared third-party dependency registry.
  • Symbols (?view=symbols): the symbol index, covered below.

Older links still work: ?view=map and ?view=graph open the communities view, ?view=explore the files view, ?view=deps Third-party, and ?view=layers redirects to the Knowledge Graph.

Index-only safe: all of it is computed from the parse and git history.

Knowledge Graph

/repos/<id>/knowledge-graph

Answers: where does this file or symbol sit in the whole system?

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. The older /c4 and /zoom URLs redirect here.

Code Health

/repos/<id>/code-health

Answers: which files have the strongest defect indicators, and why?

Repowise code health: the overall score, how it ranks against real bug-fix history, and KPI cards for files, maintainability, performance and hotspot health

Tabs behind ?tab= (the label shown, then the id):

  • Overview (triage, default): a lede that leads with the defect score and says what it means, then the code health map with its inspector. A lens switcher recolors the same map by health, maintainability, performance, or churn. Under the map sit the ranked hotspot table, sortable by bus factor with a filter for single-owner files, and the score trend.
  • Performance (performance): the ranked performance opportunities, each a cause with its steps and the raw observations as evidence.
  • Findings (findings): the fix-next queue of marker findings, filterable by dimension and severity, with function-level panels.
  • Tests (coverage): ingested test coverage joined against risk, so untested hotspots stand out.
  • Dead code (dead-code): unreachable files, unused exports, and zombie packages, tiered by confidence.
  • Doc drift (doc-drift): documentation the code no longer supports.
  • Security (security): the security findings table, by directory and by severity.
  • Blast radius (impact): blast radius for a file or a set of changed files.

Two header controls filter the Overview and Findings tabs: scope (all code or production only) and what the score counts (everything, or code shape only, which drops the git-derived half). Older links still work: ?tab=hotspots, heatmap, modules, and trend land on Overview.

Clicking any file opens the health drawer: its markers, its file signals (owners, churn, dependents), its score trend as a sparkline, and its bug history section (see BUG_HISTORY.md).

The full scoring model is documented in docs/layers/CODE_HEALTH.md. Note that the per-file score trend lives on the file's own Health tab and in the drawer rather than as a separate top-level tab.

Refactoring

/repos/<id>/refactoring

Answers: given that this file is in trouble, what exactly do I change?

A board of structured plans (Extract Class, Extract Helper, Move Method, Break Cycle, Split File), each rendered as a card with 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.

Reference: docs/layers/REFACTORING.md.

Files

/repos/<id>/files, /repos/<id>/files/<path>

Answers: what is in this file, and should I be careful with it?

A treemap of the repo sized by code volume and colored by health band, so where the risk sits is one glance rather than 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.

Symbols

/repos/<id>/architecture?view=symbols, /repos/<id>/symbols/<symbolId>

Answers: where is this function defined, who calls it, and how often has it been broken?

The symbol index with 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 next to it, which is the contrast worth reading: how often it changes against how often it breaks.

Search

/repos/<id>/search

Full-text, symbol, and semantic search over the index, scoped to one repo or the whole workspace. Semantic results need generated pages; symbol and full-text search work index-only. ⌘K opens the same thing as a palette from anywhere.

Commits

/repos/<id>/commits

Answers: what has been happening in this repo, and which changes deserve review?

The commit table led by repo-relative review priority, a supporting diff-shape score distribution, a code-evolution chart, commit-category breakdowns, and AI-agent provenance badges plus their trend over time, shown as agent, human-attested and unknown commits with the agent share of covered commits beside its coverage (see ATTRIBUTION.md). The risk model is documented in docs/layers/CHANGE_RISK.md.

Changes

/repos/<id>/commits?view=changes, /repos/<id>/changes/<changeId>

Answers: what landed, from which commits, touching which files, and what its evidence checklist flags?

The Commits page's "By change" view lists merged pull requests, merge requests and commits, newest first, filtered by category or by "Needs attention". Each row counts the attention and unknown items of the change's evidence checklist once it is built; the detail page builds it on first view and lists the commits, files, provenance and metadata of one Change Record. See CHANGES.md.

Contributors

/repos/<id>/owners, /repos/<id>/owners/<owner>

Answers: who knows this code?

A contributor directory with ownership distribution, bus-factor views, and a per-person profile showing what they own and where their knowledge is concentrated. Useful before a reorg, and before assuming a file has an owner.

Decisions

/repos/<id>/decisions, /repos/<id>/decisions/<id>

Answers: why is this code shaped this way?

Architectural decisions with their evidence drawer and a decision graph. (Supersession lineage renders empty for now — the detector that produced those edges is off, see docs/layers/DECISIONS.md.) Decisions are mined from history and PR discussion and can be confirmed, edited, or added by hand. This is the view that keeps a "we already tried that" answer from being lost.

Chat

/repos/<id>/chat

Repowise chat: asked which files are riskiest to change, it answers with a table of files and the reason each is risky

Ask questions against the indexed repo. Answers cite the pages and files they came from, an artifacts panel collects code the answer produced, and you can pick the model. This is the one view that always costs LLM tokens, and it needs generated pages to retrieve over.

Stats

/repos/<id>/stats

Repo trivia that is more useful than it sounds: activity trend, a commit punch card, size class against comparable repos, and superlatives (largest file, most-changed file, oldest untouched file).

Usage & savings

/repos/<id>/costs

Answers: what has indexing cost, and what has it saved?

Daily LLM spend, a cost heatmap, provider comparison, and the savings attributed to repowise distill compressing command output before it reaches an agent's context window.

Setup

/repos/<id>/settings/setup

Answers: what is connected, and what could I add next?

One row each for agents, sync, coverage and a model, with what is on now. Every row has a "copy prompt" that hands the step to your agent, and anything that needs attention rises to the top. Setup also reopens the welcome tour.

Settings

/repos/<id>/settings for the repo (exclusions, generation options, sync), /settings globally (server connection, LLM provider and keys, webhook, MCP server config and tool toggles, display preferences).

Workspace views

These appear only when repowise is running over a multi-repo workspace. See docs/scale/WORKSPACES.md for setup.

  • /workspace: repo cards across the workspace with per-repo status.
  • /workspace/system-map: the cross-repo dependency picture, including a design-structure matrix and package dependencies.
  • /workspace/conformance: where repos diverge from the shared patterns.
  • /workspace/contracts: API contracts extracted on the producer side matched against their consumers, so a breaking change is visible before it ships.
  • /workspace/co-changes: files in different repos that keep changing in the same window.

Keyboard

Key Does
⌘K / Ctrl+K Command palette (jump to a page, file, or symbol)
→ Space PageDown Present mode: next slide
← PageUp Present mode: previous
Home End Present mode: first / last
Esc Close Present mode or the open drawer

See also