repowise: evidence-backed codebase intelligence

Understand your codebase without paying your agent to rediscover it.

Repowise indexes your code, call graph, git history, tests, docs and design
decisions once, on your machine. Then you and your coding agent ask it things:
what calls this, what breaks if I change it, what is dead, what to fix first, why it was built this way,
and what evidence stands behind each change that landed.

Free for one developer on a laptop. Built to run across a company's repositories.

−31.6%
_{less agent output · p<0.0001}

2.3×
_{later-defective files surfaced vs CodeScene · p=0.003}

15M
_{lines of code indexed once on one laptop · then incremental on every commit}

_{Graph, risk, health, tests and dead code make zero LLM calls · same diff, same answer ·
runs inside your network · scoped tokens for REST and MCP · change policy in CI with SARIF ·
free, AGPL-3.0 or commercial}

Hosted · Foresight · What it does · Quickstart · Agents · Changes · Code health · Workspaces · Evidence · Enterprise · Docs

--- Repowise is an ambitious project. We want every engineer, and every agent working beside them, to understand a codebase the way the person who has maintained it for five years does: what calls what, what tends to break, what nobody uses anymore, and why it was built this way. Cutting tokens was never the goal. It happens anyway, because an agent that can ask the index stops searching, opening and re-reading files to find out. Measured against the other context tools on the same agent tasks, it is also the largest saving. The same engine serves a developer who wants their agent to stop rediscovering the code and a platform team that has to show what changed, who owns it and which tests reached it. Every engine capability is in the free, open-source version. The commercial layer adds organisation-wide operation on top. ## Hosted, and Foresight Everything in this README runs free on your own machine. [repowise.dev](https://www.repowise.dev/?src=oss_readme_section) runs it for you, private repos included, and is where **Foresight** arrives first: models trained on years of real commits and fixes that rank the files a fix will touch, name what a change forgot, and explain every answer, with no LLM. [What Foresight does →](docs/business/FORESIGHT.md)

Hosted at repowise.dev: everything in this README with nothing to run, private repos included, one MCP endpoint for Claude, ChatGPT and Cursor, the PR bot with free deterministic review and AI review for cents a pull request, Jira and Confluence, and team workspaces. Coming to repowise.dev: Foresight, models trained on how real codebases change that rank the files a fix will touch, flag what a change forgot, and explain every answer.

--- ## Set it up in one line Open Claude Code, Codex, Cursor or any MCP-capable agent in your repository and paste: ```text Read https://docs.repowise.dev/setup.md and set up Repowise in this repository. ``` The agent installs Repowise, indexes the repo with no API key, wires itself to the index, and asks you before anything costs money. Prefer to do it yourself: ```bash uv tool install repowise # or: pipx install repowise / pip install repowise cd /path/to/your/repo repowise init --yes --no-prose # graph, git, health, dead code, documentation. No key, no spend. repowise serve # dashboard + MCP server (needs Node 20+; first run downloads the UI) ``` `init` wires Claude Code for this repo and points the global repowise MCP entry here (on the interactive plan screen, `s` keeps it where it is). Restart Claude Code or run `/mcp`, then ask *"Use Repowise `get_overview` to summarize this repository"* or *"What breaks if I change `src/auth.py`?"* [Full setup, every agent, documentation written by a model →](docs/start/QUICKSTART.md) --- ## What it does One index, three ways to use it. Find the question you came with; each one links to the page that answers it.

Repowise reads your code, git history, tests and coverage, docs and decisions, and the contracts between repositories into one local index. From it you and your coding agent get answers to understand the code, change it safely and improve it, in coding agents, the editor, CI and pull requests, a local dashboard and multi-repo workspaces.

### Understand the code | You ask | Repowise gives you | |---|---| | *How does checkout work in this repo?* | A cited answer built from the call graph and the generated docs, in one call. [Search and answers](docs/layers/WIKI.md) | | *What calls this function, and what does it call?* | A call graph across 28 parsed languages, every edge stamped with how it was resolved and how far to trust it, plus traced execution flows from each entry point. [The graph](docs/layers/GRAPH.md) | | *Can I get docs for this codebase?* | A wiki for every module and file, rendered from the code's structure with no key, or written by a model when you choose. It updates incrementally after each commit. [Docs](docs/layers/WIKI.md) | | *Which of our docs are wrong?* | Markdown checked against the tree: every reference to a file or symbol the code no longer has, with the line to edit. [Doc drift](docs/layers/DOC_DRIFT.md) | | *Why is it built this way?* | Decisions mined from ADRs, `# WHY:` comments, commit and PR history and your agent sessions, each tied to the code it governs and flagged when it goes stale. [Decisions](docs/layers/DECISIONS.md) | | *Who knows this code?* | Owners, bus factor, fading ownership when the main author goes quiet, and suggested reviewers. [Ownership](docs/layers/OWNERSHIP.md) | | *Can I see the architecture?* | An explorable dependency map, C4 views, and a Structurizr export, no model involved. [Dashboard](docs/start/DASHBOARD.md) | ### Change it safely | You ask | Repowise gives you | |---|---| | *What breaks if I change this?* | Symbol-level blast radius: the callers of what you changed, the files that historically change with it but are missing from your diff, and the tests that reach it. [Change risk](docs/layers/CHANGE_RISK.md) | | *How risky is this PR?* | Where the change ranks against your repository's own recent commits, with the reasons, as a directive your agent can act on. [Change risk](docs/layers/CHANGE_RISK.md) | | *Which tests should run?* | The tests a diff actually exercises, from a coverage report if you have one and from the call graph if you do not. [Test intelligence](docs/layers/TEST_INTELLIGENCE.md) | | *Did this PR add untested lines?* | Patch coverage, branch coverage on changed lines and path-scoped gates in CI, on GitHub, GitLab or any runner. [CI gates](docs/start/CI.md) | | *Will this API change break another repo?* | HTTP, gRPC, topic and OpenAPI contracts matched across repositories, with a breaking-change guard and the consumer files it affects. [Workspaces](docs/scale/WORKSPACES.md) | | *Is anyone else editing these files?* | Other open branches touching the same files or their co-change partners, each with the reason it is listed. [Branch overlap](docs/layers/CHANGE_RISK.md#branch-overlap) | | *Did we just commit a secret?* | Keys, tokens and risky calls found in the working tree and in full git history, with a pre-commit check and a CI gate. [Security signals](docs/layers/SECURITY.md) | ### Improve it continuously | You ask | Repowise gives you | |---|---| | *What should we fix first?* | A ranked queue weighing impact against effort, using churn, fan-in, coverage and bug history. [Fix first](docs/layers/CODE_HEALTH.md#fix-first) | | *Where is the debt?* | A 1 to 10 score for every file from 53 deterministic detectors, split into defect risk, maintainability and performance, validated against real bug history. [Code health](docs/layers/CODE_HEALTH.md) | | *Why is this slow?* | N+1 queries, I/O in loops, blocking calls inside async code and quadratic loops, traced across function and file boundaries. [Performance](docs/layers/PERFORMANCE.md) | | *How do I break this up safely?* | Concrete refactoring plans: Extract Method, Extract Class, Move Method, Split File, Break Cycle, with the exact symbols that move and what moves with them. Ready to hand to an agent. [Refactoring](docs/layers/REFACTORING.md) | | *What can we delete?* | Unreachable files, unused exports and unused packages, each with a confidence tier and the evidence behind it. [Dead code](docs/layers/DEAD_CODE.md) | | *Where do bugs keep landing?* | Bug-fix commits traced to files and symbols, and a warning when your agent edits a bug magnet. [Bug history](docs/layers/BUG_HISTORY.md) | | *Are our tests testing anything?* | Tests with no assertions, tests that only check their own mocks, and untested hotspots. [Test-quality smells](docs/layers/CODE_HEALTH.md#findings) |

Things people do not expect it to do

- **Test coverage without running coverage.** Most repositories never produce a coverage report. Repowise answers "is this tested, and by what" from the import and call graph, and labels every answer measured or inferred. - **It checks its own health score on your repository.** After each index it reports how many of the lowest-scoring files actually had bug fixes in your recent history, so a bad score on your codebase is visible to you. - **It learns from your agent sessions.** With transcript capture on, the corrections you keep repeating ("use the shared HTTP client") become tracked decisions it feeds back to the agent later. Transcripts never leave your machine. - **It writes your `CLAUDE.md` and `AGENTS.md`** from the real index and keeps them current, so even an agent with no MCP support starts informed. - **It shrinks command output before your agent reads it.** `repowise distill pytest` keeps every failure and drops the noise, and nothing is lost: an `expand` command restores any cut. - **New git worktrees start indexed.** A linked worktree seeds its index from the base checkout instead of starting cold. - **It knows which external systems you depend on.** Package manifests across PyPI, npm, Cargo, Go, NuGet, Maven and CMake feed a map of the services and libraries the code reaches.

A real Claude Code session asks Repowise what breaks before editing a file, then the dashboard shows the ranked Fix first queue, a refactoring plan ready to hand to an agent, dead code with confidence tiers, a commit ranked against the repo's own history, and the HTTP contract between a frontend and backend on the workspace system map

_{Recorded on this repository and its workspace: an agent asking the index, then the
dashboard and CLI on the same local index. No API key and nothing uploaded.}

### Pick your front door | If you care about... | Start here | |---|---| | **A coding agent that knows the repository** | Task-shaped context in fewer calls, with decisions and risk delivered before the agent asks. [For agents ↓](#your-agent-stops-guessing) | | **Safer pull requests and faster CI** | Change risk, symbol-level callers, missing co-changes and the tests a diff needs. [Change intelligence ↓](#know-whats-dangerous-before-you-merge) | | **Paying down the code most likely to hurt you** | A defect-validated health score, then the concrete fix. [Code health ↓](#code-health) | | **Showing what changed, to a reviewer or an auditor** | Each merged change with its evidence, change policy in CI, and reports you can hand over. [Change evidence ↓](#change-evidence) | | **An estate of many repositories** | Contracts matched across repos, breaking-change guards, architecture rules in CI, one MCP endpoint for everything. [Workspaces ↓](#past-one-repo) | | **Rolling it out across a company** | Self-hosted with nothing leaving your network, per-language accuracy, sizing, compliance status and licensing in one place. [Teams and enterprise ↓](#for-teams-and-enterprises) | --- ## Your agent stops guessing Every question your agent asks about a repository has an answer that could have been computed ahead of time. *Who calls this function? What breaks if I change it? Why is it written this way? Which files are actually dangerous?* Without an index, the agent rediscovers that answer on every task: grep, read, re-read, forget. Repowise gives Claude Code, Codex, Cursor, VS Code and any other MCP host **ten task-shaped MCP tools** backed by one index of graph, git, docs and decisions. Most code tools are built around data entities, one file or one symbol at a time, which pushes agents into long chains of sequential calls. These are built around tasks: pass several targets in one call and get the whole picture back. [The tool list ↓](#the-ten-mcp-tools) **About tokens.** Every tool in this category promises to cut your token bill, and there are a lot of tools in this category. We think tokens are a symptom. An agent burns them because it does not know the codebase, so it searches, opens files, opens more files, and searches again. Give it an index that already knows, and the savings show up on their own. They also happen to be the best we have measured: in a paired agent loop over 43 questions on `django/django`, Repowise cut the agent's own output by **31.6%** (p<0.0001) and got there in **3.8 tool calls instead of 7.2**, ahead of every other context tool in the same run. On 42 sealed retrieval tasks it found **0.876** of the files a fix needed, against **0.610** for the next tool. [Method and every row we lose →](docs/BENCHMARKS.md) **Context arrives before the agent asks.** Optional [hooks](docs/agent/HOOKS.md) push it into the session when it matters: the governing decision when your agent edits a file that decision covers, a warning when it touches a file with a run of recent bug fixes, a short briefing at session start, and a correction when it reaches for a path that does not exist. **It learns from how you work.** Switch on transcript capture (`repowise decision source set session --on`) and Repowise reads your own agent transcripts for the corrections you keep making, turning the durable ones into tracked decisions it delivers back later. Transcripts never leave your machine; one batched model call per update turns the candidates that clear the deterministic gates into records, and `--no-llm` keeps the gates and drops that call.

What the index builds

Five layers, one index: | Layer | What it contributes | |---|---| | **1. Graph** | File and symbol dependencies across 28 AST-parsed languages, confidence-stamped call resolution, communities, centrality, cycles and execution flows | | **2. Git history** | Hotspots, ownership, co-change, bus factor and bug-fix history: behavioural signals static analysis cannot see | | **3. Docs** | A wiki for every module and file, hybrid search, and your own markdown checked against the tree for claims the code no longer supports | | **4. Decisions** | Architectural rationale from ADRs, inline markers, commits, PRs and agent sessions, each claim traced to evidence | | **5. Health and change** | 53 deterministic detectors across defect risk, maintainability and performance, change risk, test impact, dead code and concrete refactoring plans | The structural wiki needs no model. Model-written prose is an optional upgrade, one page or directory at a time. [How the layers fit together →](docs/layers/INTELLIGENCE_LAYERS.md) · [How the graph earns trust →](docs/layers/GRAPH.md)

### Also: stop paying for output nobody reads Most of what an agent reads back from a shell command is noise: 300 lines of passing tests wrapped around 4 failures, full commit bodies when it asked what changed recently. `repowise distill ` compresses command output **before the agent reads it**, errors first, exit code preserved. ```bash repowise distill pytest # 61% fewer tokens, all 11 failure lines kept repowise distill git log -50 # 89% fewer tokens repowise saved # what distillation saved you, in tokens and dollars ``` Every omission leaves an inline `[repowise#]` marker that `repowise expand ` reverses in full, so the agent can pull the detail back without re-running the command. Small outputs pass through untouched. An opt-in hook rewrites noisy commands for the agent automatically.

repowise Costs dashboard: tokens and dollars saved across distill and the MCP tools

_{The Costs dashboard tallies both savings surfaces. Every event is priced from the model that produced it, and where the evidence is ambiguous it declines to claim a saving. Example from a week of heavy local use.}

Full guide: **[docs/agent/DISTILL.md →](docs/agent/DISTILL.md)** --- ## Know what's dangerous before you merge Four deterministic signals, all computed from the graph and git history, no LLM: - **Change risk.** Score any commit or `base..HEAD` range **0-10** from the shape of the diff, ranked against your repository's own recent commits. PR mode returns directives an agent can act on: `may_break`, `missing_cochanges`, `missing_tests`, `tests_to_run`. One command: `repowise risk main..HEAD`. ([reference →](docs/layers/CHANGE_RISK.md)) - **Bug history.** Which files and symbols actually get bug-fixed, and how recently. Doc, test and config commits are filtered out so the count means what it says, and a file with a run of recent fixes is flagged as a bug magnet while you edit it. ([reference →](docs/layers/BUG_HISTORY.md)) - **Test intelligence.** Which tests reach a file and which ones a diff exercises, from a coverage report or from the call graph. ([reference →](docs/layers/TEST_INTELLIGENCE.md)) - **Change coordination.** Which other open branches edit the files you are editing, every row saying why it is listed, and whether the diff in front of you is one change or several unrelated ones. `repowise overlap` and `repowise risk`. ([reference →](docs/layers/CHANGE_RISK.md#branch-overlap)) ### Which tests cover this file, without a coverage report Ingest LCOV, Cobertura, Clover, JaCoCo or a Go coverprofile and you get the measured answer. Most repositories never produce one, so the graph answers instead: a test file that imports a source file *reaches* it, which is a recorded edge, where most tools fall back to matching file names. ```bash repowise impacted-tests main..HEAD # only the tests this diff exercises repowise health # untested hotspots, graph-aware ``` _{Checked against this repository's own test coverage:
97.7% precision on the files tests call into and 97.5% on the run
list (on a slice with per-test attribution). Every row is stamped basis: "measured" or
"inferred", measured wins where both can answer, and an empty answer means
unknown, never "no tests".
Test intelligence →} ### In CI, and on every pull request Patch coverage, doc drift, security and change risk run as gates in your own pipeline through the [GitHub Action](docs/start/CI.md#github-actions), a [GitLab template](docs/start/CI.md#gitlab) or plain CLI commands anywhere else, with annotations, SARIF and GitLab Code Quality output. The gates need no API key. [Repowise in CI →](docs/start/CI.md) On GitHub you can also install the free **[Repowise PR Bot](https://github.com/apps/repowise-bot)**, a hosted GitHub App that puts the same analysis on every pull request. One comment, edited in place on every push, and **a green PR gets no comment at all**. It shows symbol-level blast radius (the contracts the PR changed and every caller outside the PR), the tests and co-change partners missing from the change, change risk against the repository's own history, and a public analysis page per PR. Zero LLM calls, so the same diff always gets the same review. The dark Repowise per-PR analysis page showing change risk, repository health, changed contracts, outside callers, newly added findings, and a blast-radius treemap of the repository

The dark Repowise per-PR analysis page showing change risk, repository health, changed contracts, outside callers, newly added findings, and a blast-radius treemap of the repository

_{A real comment on a real PR: [repowise-dev/repowise#1204](https://github.com/repowise-dev/repowise/pull/1204) ·
[its analysis page →](https://repowise.dev/pr/repowise-dev/repowise/1204) ·
[install the PR bot →](https://github.com/apps/repowise-bot)} --- ## Every change, with its evidence Repowise reads each merged pull request, merge request or commit back from git as a **Change Record**: the commits it brought in, the components it touched and their declared owners, the tests that reach it, the contracts and decisions it crosses, its provenance, and what happened after it landed. No forge API is called, and every item says what it rests on: measured, inferred, declared or unknown. | You ask | Repowise gives you | |---|---| | *What landed in this PR, and what backs it up?* | The change's evidence checklist, each item `ok`, `attention` or `unknown`, with an in-toto export. [Change Records](docs/layers/CHANGES.md) | | *Can CI hold changes to our payment code to a higher bar?* | Rules in `.repowise/policies.yaml`, matched to components by name, tag or criticality and evaluated by `repowise check`, with SARIF or JUnit output. [Change policy](docs/layers/POLICY.md) | | *Something broke. Which change do we read first?* | Recent changes ranked against an error, a stack trace or an issue. On 43 real regressions, the change a later revert or fix named was in the top 5 for 67% of them, against 28% for ranking by shared files. [Suspects](docs/layers/CHANGES.md#suspects) | | *Who owns this, and are they still working on it?* | Backstage-shaped components with owners from your catalog and CODEOWNERS, compared with the last 90 days of commits. [Components](docs/layers/COMPONENTS.md) | | *Can we show an auditor or an acquirer where we stand?* | Evidence packs: a repository assessment, a change report for a period and a component inventory, as JSON, Markdown, HTML or CSV. [Reports](docs/layers/REPORTS.md) | ```bash repowise changes show pr-412 # one change and its evidence checklist repowise check main..HEAD --sarif-file policy.sarif # run .repowise/policies.yaml in CI repowise suspects --trace stacktrace.txt # the recent changes to read first repowise report changes --format html --out q3.html # change evidence for the last 90 days ``` Owners and reviewers are counted, never ranked or named, and every report states what git alone cannot attest. --- ## ★ Know exactly what to fix Code health measures technical debt: the code shape and change history that make a file likely to need the next fix. A score that says *"this file is risky"* is where most tools stop. Repowise scores every file, finds where the risk concentrates, and names the specific fix.

repowise code-health loop: deterministic markers fan into three signals, the graph and git history locate where risk concentrates, and refactoring intelligence emits concrete plans your agent executes

Every file is scored 1-10 by **53 deterministic detectors** (McCabe complexity, brain methods, LCOM4 cohesion, god classes, clone detection, untested hotspots, change entropy, prior-defect history and more), read through three lenses: **defect risk**, **maintainability** and **performance**. Performance findings such as N+1 queries and I/O in loops are traced *across* functions and files through the call graph, which is where file-local linters lose them. Only 25 of the 53 detectors move the defect score, because that is the number carrying published accuracy claims. > **Zero LLM calls, zero cloud.** Detector weights are **calibrated against a real > defect corpus, not hand-tuned**: every file scored at a commit before the bug > window so nothing leaks backward, with file size as an explicit control, so a > detector only earns weight for defect lift beyond a file being big. **It checks itself on your repository.** After every index, Repowise compares its own flags with your git history and tells you what it found: *"16 of the 20 lowest-health files had a bug fix in the last 6 months, 3.3x the 24% baseline."* If that number is bad on your codebase, you will see it. **Then it names the fix.** **Extract Class**, **Extract Helper**, **Move Method**, **Break Cycle**, **Split File** or **Extract Method**, with the exact methods, edges and symbols that move, the callers and co-changing files that move with them, and a ranking that puts a fix on a central hub above the same fix on a leaf. Extract Method runs a dataflow pass over the function to lift the exact span and infer a behaviour-preserving signature. ```bash repowise next # what to fix first, ranked by impact and effort repowise health # KPIs and lowest-scoring files repowise health --refactoring-targets # ranked, concrete plans repowise health --trend # snapshots plus declining-health alerts repowise dead-code # what can go, by confidence tier ``` The dashboard renders each plan as a card with a copy-to-agent button. An optional model step, never in the indexing path, expands a plan into generated code and a unified diff. _{Validated on 21 open-source repositories across 9 languages
(2,826 files scored at a fixed point and checked against the following 6 months of bug
fixes): ROC AUC 0.737 [0.683, 0.787]. Against CodeScene
on the 2,770 files both tools scored, ranking by Repowise surfaces 2.3x the
later-defective files under a fixed review budget (paired, p = 0.003). CodeScene keeps a
shorter, slightly more precise list.
Full head-to-head and its limits →} Guides: **[code health](docs/layers/CODE_HEALTH.md)** · **[refactoring](docs/layers/REFACTORING.md)** · **[dead code](docs/layers/DEAD_CODE.md)** --- ## See all of it `repowise serve` starts the full web dashboard next to the MCP server, all local. It needs Node.js 20+, and the first run downloads the UI.

_{Architecture · the dependency graph, laid out and explorable, with per-node context and change coupling}	_{Code Health · every file as a bubble, hover any one to inspect its score, size, coverage and findings}
_{Chat · ask the codebase a question, answers cite the files and pages they came from}	_{Docs · generated wiki pages for the whole codebase, with confidence and freshness badges}

Also in there: **Architecture** and **C4** views, the **Knowledge Graph** and a zoomable map, **Risk**, **Hotspots**, **Coupling** and **Blast radius**, **Contributors** and **Ownership**, **Decisions** with an evidence drawer and timeline, **Symbols**, **Security**, **Dead code**, **Costs** and **Workspace**. Every view and what it answers: **[docs/start/DASHBOARD.md →](docs/start/DASHBOARD.md)** --- ## One intelligence layer across your software estate Real systems are not one repository, and the expensive failures live in the gaps between them. Change a backend contract and Repowise can name the frontend calls that consume it, the services downstream, the companion files missing from the change, and the architecture rule the new dependency violates, before it ships. | Workspace intelligence | What it answers | |---|---| | **Contract map** | Which services provide and consume each HTTP, gRPC, event, socket and data contract? Links keep their exact or candidate confidence and the source evidence. | | **Cross-repo blast radius** | If this provider changes, which downstream services are in structural reach, and which may drift through historical co-change? | | **Breaking-change guard** | Was an endpoint removed or an OpenAPI, proto or signature shape changed incompatibly, and which consumer files are linked to that contract? | | **Test impact** | Which tests in the consumer repos should run for this provider change, measured from coverage or inferred from the call graph? | | **Architecture as code** | Does the live system graph violate declared dependency rules or contain cycles? `repowise workspace check` gates CI. | | **Architecture health** | How coupled is the estate? Propagation cost, the cyclic core, service roles and a deterministic 1-10 architecture score. | | **Federated context** | One dashboard and one MCP server answer across every repository while keeping repo-level evidence. | The system map models **services**, not just repository boxes, and never conflates a real contract with "these files often changed together". HTTP field-level comparison covers a bounded OpenAPI 3.x subset; matched consumers prove endpoint exposure, not field use or runtime failure. **[Workspace guide and exact support matrix →](docs/scale/WORKSPACES.md)** Worktrees and updates stay light: a linked worktree seeds its index from the base checkout, and post-commit hooks, file watching, webhooks or polling keep each repository and the cross-repo graph current. [Keeping the index fresh →](docs/scale/AUTO_SYNC.md) --- ## Supported languages **28 languages parsed to an AST, 42 on a five-rung ladder, framework-aware where an ecosystem handler exists.** Every language ships in the open-source distribution.

Full

Good · Partial

The full ladder, and what each rung gives you

| Rung | Languages | What you get | |---|---|---| | **Full** (15) | Python · TypeScript · JavaScript · Svelte · Vue · Astro · Java · Kotlin · Go · Rust · C++ · C# · Scala · Ruby · Apex (Salesforce) | The whole pipeline: AST symbols, import resolution, a resolved call graph, heritage, docstrings, framework edges and code-health markers | | **Good** (11) | C · Swift · PHP · Dart · Object Pascal · COBOL · GDScript · VB.NET · Elixir · F# · Objective-C | All of the above except the full health suite, within the language-specific ceilings in the full matrix | | **Partial** (2) | Luau / Roblox · Razor / Blazor | Luau: AST symbols and `require()` resolution, Rojo and `.luaurc` aware. Razor: component symbols, `@code` and component-tag call edges, C# health markers; no import resolution yet | | **Lightweight** (6) | Clojure · Haskell · Lean 4 · Erlang · HTML · QML | A real file-to-file import graph, and no symbol-level claims | | **Structural** (8) | R · Zig · Julia · Elm · OCaml · Crystal · Nim · D | Git history: blame, hotspots, co-change, ownership, bug history | SQL and dbt projects get `ref()` / `source()` lineage, shell scripts get function-level symbols, HTML pages contribute their `