{"id":"417b1173-8809-4a93-94e9-68cdaf1711a4","slug":"semantic-vision","kind":"mcp","name":"Semantic-Vision","summary":"Local-first codebase intelligence for the AI-agent era. See what an agent's edit will break before you merge it: impact analysis, interactive call graphs, execution flowcharts, complexity reports, AI-","owner":"venom21adi","repoUrl":"https://github.com/venom21adi/Semantic_Vision","license":"MIT","licenseTier":"permissive","trust":"community","stars":8,"match":null,"fewStars":false,"format":"mcp","createdAt":"2026-08-22T07:50:07.000Z","addedAt":"2026-10-21T17:58:07.716Z","logoUrl":"https://avatars.githubusercontent.com/u/69112627?u=28902c766a454fadfe339f228332aa6c2888c0bc&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools","data-analytics"],"tags":[],"runtime":"python","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-25T15:53:07.871Z","sample":false,"url":"https://conduits.dev/tools/semantic-vision","language":"Python","transports":["stdio"],"install":{"pypi":"semantic-vision"},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"\n\n# Semantic Vision\n\n**Codebase observability for you and your AI agents so you can use AI coding effectively and privately.**\n\n\n\n[](https://marketplace.visualstudio.com/items?itemName=venom21adi.semantic-vision)\n\n### What problem does this solve?\n\nAI coding agents can now change large parts of a codebase in seconds. The problem is that our ability to understand those changes has not kept up.\n\nA diff tells you what an agent changed not what depends on it, what it affects, or whether the codebase is actually getting better. Understanding that still means jumping between files, tracing dependencies, and relying on a mental model that is usually incomplete.\n\nSemantic Vision gives you that context in one place so you can understand, review, and change a codebase with confidence, whether the last edit was yours or an agent's.\n\nImpact Analysis shows the blast radius of any change. Call Graphs make relationships between files, classes, and functions visible. Execution Flowcharts show how a function actually behaves. Code Health surfaces complexity, hotspots, dead code, coverage, duplication, dependencies, and AI-powered recommendations. AI Documentation captures context from the code itself. Code-to-Data Lineage connects application logic to the tables and columns it depends on.\n\nEverything runs locally 100% private. Your code never leaves your machine.\n\n### At a glance\n\n![\"\"/](\"assets/icons/impact-analysis.svg\")
Impact analysis · ![\"\"/](\"assets/icons/call-graph.svg\")
Interactive call graph · ![\"\"/](\"assets/icons/execution-flowchart.svg\")
Execution flowcharts · ![\"\"/](\"assets/icons/complexity-report.svg\")
Code Health · ![\"\"/](\"assets/icons/ai-docs.svg\")
AI-generated docs · ![\"\"/](\"assets/icons/data-lineage.svg\")
Code-to-data lineage · 🤖 MCP server for coding agents · ![\"\"/](\"assets/icons/fast-local-private.svg\")
100% local & private\n\n## Impact Analysis\n\nRight-click any function — or, with code-to-data lineage connected, any\ntable or column — and choose **Impact Analysis** to see every direct\nand transitive caller, resolved from the real call graph, not a guess.\nCircular call chains are flagged instead of silently mishandled, and\nthe whole blast radius highlights live on the graph.\n\n\n\nReviewing an AI agent's edit, or your own? This is the answer to \"what\nactually depends on this\" before you merge, not after something breaks\nin production — the same traversal also crosses into data lineage, so\nrenaming a column or dropping a table surfaces every function, model,\nand table upstream of it in one right-click.\n\n## Interactive Call Graph\n\nParsing is purely static (your code is never executed), and nothing\nabout it leaves your computer unless you explicitly ask for AI docs.\n\n\n\n\n## AI documentation setup\n\nRight-click any function and choose **Document** to generate Markdown\ndocs for it, assembled from its real source, callers, callees, and\nparent class — not just the function in isolation. Right-click a file\ninstead and the same action generates a module-level summary from its\nimports and the signatures of everything it defines, without ever\nsending a function body:\n\n\n\nPick a provider in the panel that opens — no extra setup is required to\ntry it, but each provider needs one of the following before generation\nwill work:\n\n- **Ollama** (local, free, private) — install [Ollama](https://ollama.com),\n run `ollama serve`, and pull one or more models, e.g.\n `ollama pull llama3.2:3b`. The panel lists whatever you've actually\n pulled and lets you pick which one to use per generation — handy for\n swapping in a lighter model for quick testing. The backend talks to\n Ollama at `http://localhost:11434` by default.\n- **OpenAI** — set an `OPENAI_API_KEY` environment variable before\n starting the backend. Uses `gpt-4o-mini` by default.\n- **Anthropic** — set an `ANTHROPIC_API_KEY` environment variable before\n starting the backend. Uses `claude-haiku-4-5` by default.\n\nOpenAI's and Anthropic's default model names can be overridden with\n`SEMANTIC_VISION_OPENAI_MODEL` / `SEMANTIC_VISION_ANTHROPIC_MODEL`; for\nOllama, use the model picker in the panel instead. Generated docs are\nonly written to disk when you click **Save** — nothing is persisted\nautomatically, and they're written to wherever you've configured as\nthe **Save location** (see Quick start below).\n\n## Execution flowcharts\n\nRight-click any function and choose **Execution Flowchart** to see\nexactly how it behaves, built from its real AST/CST rather than a rough\nsummary: entry and return points, decisions with **Yes**/**No** edges,\nloops with a visible back-edge, I/O calls, and calls out to other\nfunctions in the repo — each in its own conventional flowchart shape.\nWorks for both Python and JS/TS, including `switch` fallthrough,\n`do...while`'s bottom-condition check, and labeled `break`/`continue`.\n\n\n\nThe flowchart replaces the graph canvas while open; **Back to graph**\nreturns you to the normal call graph.\n\n## Code Health: score a change, not just a snapshot\n\n**Code Health** sits in the header as a peer to **Codebase Graph** —\ntwo persistent, browser-tab-style lenses on the same repo, not a panel\nyou open and close. Switching to it replaces the sidebar with a\nfilterable, sortable ranked list instead of leaving the graph's file\ntree sitting there unused next to a second navigator. Seven tabs share\nthat list, each backed by its own `GET`/`POST /api/...` endpoint (see\n[guides/mcp-server.md](guides/mcp-server.md) for the matching MCP tools)\n— everything below runs locally against your own source, with two\nexplicit, opt-in exceptions noted below.\n\n\n\n- **Complexity** (`GET /api/complexity`) — cyclomatic complexity for\n every function, computed from a real AST walk (decisions,\n boolean-operator chains, comprehension filters, `match` cases, and\n nested-loop hotspots all count, not just a line-count guess),\n filterable by name/file/tier/call depth and sortable by any of them.\n- **Hotspots** (`GET /api/complexity/hotspots`) — the same complexity,\n weighted by how often each file actually changed in a chosen window —\n a moderately complex function edited constantly is a bigger practical\n risk than a complex one nobody touches.\n- **Dead code** (`GET /api/dead-code`) — zero-caller functions after\n excluding decorators, test files, dunders, and entry points —\n candidates to review, never a verdict, since a caller outside the repo\n (a library's public API) can still be real.\n\nClick any row to see exactly who calls it and what it calls, live:\n\n\n\nComplexity is also git-aware: **Compare to last look** diffs the\ncurrent state against whatever it showed the last time you opened it\n(useful right after an AI agent's session, or your own edit); typing a\ncommit or branch into the ref picker instead diffs against any point in\nthe repo's history — or fill in the second, optional field to diff two\narbitrary commits against each other, with no dependency on what's\ncurrently checked out. Either way, the result is added / removed /\nchanged functions, each with its before-and-after complexity, so\n\"did this change make the code healthier or worse\" is a glance instead\nof a manual `git diff` read-through.\n\n### Coverage — where correctness risk actually concentrates\n\nComplexity and blast radius each answer half of \"is this risky to\nchange\"; neither alone answers \"and is it actually tested.\" Point the\n**Coverage** tab at a coverage.py XML (`coverage xml`) or lcov report\nyour own test-runner already produced (`POST /api/coverage/ingest` —\nSemantic Vision never runs your tests itself, only reads what you\nalready generated), and every function gets ranked by `complexity ×\n(1 + blast radius) × (1 − coverage)`:\n\n\n\nA function with no coverage data at all badges **No coverage data** —\nkept visually distinct from a genuinely-measured **Coverage 0%**, since\nthe risk formula treats both as worst-case but only one of them is\nreally \"measured and bad.\"\n\n### Duplicates — the maintenance cost complexity can't see\n\nTwo individually \"simple\" functions can still be a real duplication\ncost together. The **Duplicates** tab (`GET /api/duplicates`) normalizes\nevery function's AST down to its bare shape — every identifier name,\nliteral value, and comment stripped away — and groups whatever hashes\nidentically:\n\n\n\nExact-shape matches only, not near-misses: a renamed-and-recommented\ncopy still groups with its original, but two functions with any real\nstructural difference won't. Click a group to jump to its first\nmember's own relationship graph, same as any other tab.\n\n### Dependencies — the one feature that leaves your machine\n\nEvery import the resolver can't match inside your repo already becomes\na synthetic `external::` node; the **Dependencies** tab cross-references\nthose against what your manifest (`pyproject.toml` / `requirements.txt`\n/ `package.json`) actually declares — only packages that are *both*\nimported *and* declared get checked — then queries\n[osv.dev](https://osv.dev) for known vulnerabilities against each. This\nis the one outbound network call anywhere in Semantic Vision besides an\nAI-provider doc request, so it's opt-in every time: check the consent\nbox, click **Scan dependencies**, and only then does anything leave your\nmachine (`POST /api/dependencies/risk` itself rejects the request\nserver-side if you didn't explicitly confirm, regardless of what any\nclient sends). Results render as a grid, sorted vulnerable-first — click\na package to see, in the same relationship-graph panel every other tab\nuses, exactly which of *your own* files actually import it, not just\nthat it's declared somewhere:\n\n\n\n### Recommendations — one AI pass across every signal above\n\nEvery tab above answers one question in isolation. **Recommendations**\nasks an AI provider (the same local-[Ollama](https://ollama.com)/OpenAI/\nAnthropic choice AI docs already use) to read the real complexity,\nhotspot, coverage, and duplicate findings for your repo together and\nprioritize — a function that's both a hotspot *and* part of a duplicate\ngroup is a stronger signal than either fact alone, the kind of\ncorrelation that's easy to miss skimming five separate ranked lists one\nat a time. Dependency findings are folded in automatically once you've\nscanned this session, but generating a recommendation never triggers\nthat scan itself — the osv.dev call stays exactly as opt-in as it is on\nits own tab; clicking Generate here only ever talks to your chosen AI\nprovider, the same one AI docs already talk to.\n\n\n\n## Code-to-data lineage\n\nThe sidebar's **Data lineage** section extends the graph past your code\nand into the data it reads and writes. Three sources feed the same\ngraph, reconciled by table name so the same table only ever shows up\nonce no matter how many of them see it:\n\n- **SQLAlchemy models** — declarative model classes are detected\n automatically on every parse, no setup needed: each becomes a table\n node with its own columns underneath (expand the table to see them),\n foreign keys drawn as edges between tables, and every function that\n queries or writes one connected to it — down to the specific column,\n where it can be named with no guessing (a constructor's own keyword\n arguments, or a raw `INSERT`/`UPDATE`'s column list).\n- **dbt** — click **Add tables & models** and paste the path to a\n `manifest.json` your own `dbt compile` already produced (Semantic\n Vision never invokes dbt itself) to pull in every model, its `ref()`\n dependencies, the table it materializes, and every column it declares.\n- **A live database** — from the same panel, paste a read-only\n connection string to introspect a real schema directly — the highest-\n confidence column source there is, straight from the catalog — so you\n can see where your ORM models have drifted from what's actually\n deployed.\n\n\n\n### Using it well\n\nOnce at least one table or dbt model is on the graph, two more tools in\nthe same **Data lineage** section turn \"the graph happens to include\nsome tables\" into an actual lineage view:\n\n- **Data only** dims everything on the canvas that isn't a table, a\n dbt model, or code that directly reads/writes one — the same graph\n and the same impact analysis, just filtered to a lineage-only\n reading, rather than a separate mode you have to switch into and out\n of.\n- **Impact analysis** works on a table — or a single column — node\n exactly like it does on a function: right-click it to see every\n function, model, and table upstream of it, code and data lineage in\n one traversal — the way to answer \"what actually breaks if I rename\n this column, drop this table, or change what this dbt model\n materializes\" before doing it, not after.\n\nA real, worked example — dbt Labs' own `jaffle_shop` tutorial project\ningested into an app that already declares `Customer`/`Order` models\nfor the same tables, columns reconciling from both sources onto one\ntable, impact analysis crossing the dbt model, the ORM class, and the\nreading functions in one right-click — is in\n[guides/data-lineage.md](guides/data-lineage.md), with screenshots.\n\n## 🤖 MCP server for coding agents\n\nSemantic Vision already computes the exact structural facts a coding agent\notherwise has to grep and guess at — call graph, impact analysis, complexity,\ngit-aware hotspot scoring, and data lineage. `semantic-vision-mcp` exposes\nall of it as [MCP](https://modelcontextprotocol.io) tools any compatible\nagent (Claude Code, Claude Desktop, Cursor, etc.) can call mid-conversation:\n\n```bash\nuv sync\nuv run semantic-vision-mcp\n```\n\nthen add it to your agent as a stdio MCP server, e.g. for Claude Code:\n\n```bash\nclaude mcp add semantic-vision -- uv --directory /path/to/Semantic_Vision run semantic-vision-mcp\n```\n\nIt talks to the same FastAPI backend over HTTP rather than running a\nseparate analysis engine — reachable-or-spawn, exactly like the VS Code\nextension: if you already have the desktop app or extension open with a repo\nparsed, the MCP server reuses that warm cache instead of starting cold; if\nnothing's running, it spawns its own backend and cleans it up on exit.\n`parse_repo`, `get_graph`, `get_impact`, `get_callees`, `get_complexity`,\n`get_complexity_diff`(`_ref`), `get_hotspots`, `get_dead_code`,\n`ingest_coverage`, `get_coverage_risk`, `get_duplicates`, `get_git_refs`,\n`get_flowchart`, and `get_function_source` cover the same ground the UI\ndoes — see [guides/mcp-server.md](guides/mcp-server.md) for the full tool\nreference, client config examples, and what's deliberately left out: both\ndependency/security-risk scanning and AI-generated Recommendations stay\nweb-app-only, since neither an outbound network call nor client-supplied\nscan data an agent didn't ask for is something a tool call should trigger\nsilently.\n\n\n## ✨ Features\n\n **See the whole call graph at a glance** — every directory, file,\nclass, and function as a zoomable, color-coded graph with\ncall/import/defines edges. Structure that would take an hour of\ngrepping to piece together by hand is visible on one screen.\n\n🔍 **Find anything instantly** — real-time search across the whole\nrepo, or scope the graph down to a single file's own structure when you\nonly care about a slice.\n\n **Know what you'll break before you break it** — right-click any\nfunction for impact analysis: every direct and transitive caller,\ncircular call chains flagged instead of silently mishandled, and the\nwhole chain highlighted live on the graph.\n\n **Trace exactly how a function behaves** — right-click any function\nfor its execution flowchart: branches, loops with visible back-edges,\nI/O, and calls out to other functions in the repo, rendered with\nconventional flowchart shapes instead of you stepping through the code\nby hand.\n\n **See which functions are worth worrying about** — the Code Health\nlens ranks every function by complexity, by hotspot score (complexity ×\nhow often it actually changes), by coverage-vs-blast-radius risk, lists\ndead-code and near-duplicate candidates, and flags known vulnerabilities\nin packages you actually import — click a vulnerable package to see\nexactly which of your own files import it; click any function to see\nexactly who calls it and what it calls, live. An AI pass across all of\nit then prioritizes what to actually work on first, correlating signals\na person skimming five ranked lists one at a time would likely miss.\n\n **Judge a change, not just a snapshot** — Code Health compares\ncomplexity against the last time you looked, any commit or branch, or\ntwo arbitrary commits against each other, so \"did this AI agent's edit\nhelp or hurt\" is a glance instead of a manual diff read.\n\n **Never write another docstring by hand** — right-click any function\nto generate real Markdown documentation (Purpose, Parameters, Returns,\nSide Effects, Notes) from its actual source, callers, callees, and\nparent class, streamed live from your choice of a local\n[Ollama](https://ollama.com) model, OpenAI, or Anthropic, and saved\nstraight into the repo.\n\n **See where your code touches your data — down to the column** —\nSQLAlchemy models are detected automatically; connect a dbt manifest\nand/or a live database to add their tables, models, and columns to the\nsame graph, reconciled by name. Flip **Data only** to read it as a pure\nlineage diagram, with impact analysis spanning code and data in one\ntraversal.\n\n🤖 **Give a coding agent the same map** — an [MCP](https://modelcontextprotocol.io)\nserver exposes the call graph, impact analysis, complexity/hotspot\nscoring, and data lineage as tools Claude Code, Claude Desktop, or any\nother MCP-compatible agent can call directly, instead of grepping and\nguessing at blast radius. Reuses whatever backend and cache you already\nhave running — no separate setup, no re-parsing.\n\n🧩 **Right inside your editor, zero setup** — install the\n[VS Code extension](https://marketplace.visualstudio.com/items?itemName=venom21adi.semantic-vision)\nand get the full graph, impact analysis, and everything else below in a\npanel next to your code — no separate browser tab, no Python or `uv` to\ninstall, the backend ships bundled in.\n\n💾 **Pick up exactly where you left off** — dragged layout, saved docs,\nand analysis state persist locally and restore instantly next time you\nopen the same repo. The save location defaults to the repo's `.git`\nroot — auto-detected even if you've scoped the graph down to a\nsubfolder for performance — and can be changed at any time.\n\n **Fast, local, and private** — a FastAPI backend statically parses\nyour code (Python's own `ast` module for Python, [`tree-sitter`](https://tree-sitter.github.io/tree-sitter/)\nfor JavaScript/TypeScript and Java), a React frontend renders it. No account, no\ncloud, no telemetry, nothing installed beyond a Python and a Node\ntoolchain you already have.\n\n## 📊 Status\n\nWhat works today, per language:\n\n| Feature | Python | JavaScript / TypeScript | Java |\n|---|:---:|:---:|:---:|\n| Call graph — imports, classes, functions, calls | ✅ | ✅ | ✅ |\n| Interactive graph visualization | ✅ | ✅ | ✅ |\n| Search | ✅ | ✅ | ✅ |\n| Persisted layout & view state | ✅ | ✅ | ✅ |\n| Impact analysis (upstream callers, cycle detection) | ✅ | ✅ | ✅ |\n| Code Health (complexity, hotspots, dead code, coverage, duplicates, dependencies, AI recommendations) | ✅ | ✅ | ✅ |\n| AI-generated documentation | ✅ | ✅ | ✅ |\n| Execution flowcharts | ✅ | ✅ | ✅ |\n| Code-to-data lineage (SQLAlchemy, dbt, live DB) | ✅ | — | — |\n| Docker packaging / one-command setup | ✅ | ✅ | ✅ |\n\nMost real repos are polyglot, so Semantic Vision auto-detects which supported languages are present in the path you enter and pre-checks them as chips — Python, JavaScript / TypeScript, and Java can all be selected together for the same repo. Each selected language is parsed independently and shown as its own tab in the dashboard (call graph, Code Health, docs, etc. all scoped to that language); there's no cross-language call linking between tabs yet.\n\nJS/TS uses tree-sitter for static AST resolution—including full support for JSX/TSX. To preserve precision without execution, dynamic patterns (like computed require() calls) are flagged directly in the UI rather than inferred.\n\n## ⏱️ Benchmarks\n\nReal-world numbers against genuinely large, well-known open-source repos — not this project's own\nfixtures — one per supported language:\n\n| Language | Repo | Files | Backend parse — cold (s) | Backend parse — warm (s) | Browser: time to render (s) |\n|---|---|---|---|---|---|\n| Python | [fastapi/fastapi](benchmarks/fastapi.md) | 1,138 | 23.25 | 4.08 | 7.20–7.84 |\n| JavaScript | [three.js](benchmarks/threejs.md) | 752 | 29.33 | 1.98 | 4.88–5.01 |\n| TypeScript | [nestjs/nest](benchmarks/nest.md) | 1,907 | 39.68 | 2.48 | 6.85–6.88 |\n| Java | [google/guava](benchmarks/guava.md) | 615 | 9.83 | 2.52 | 4.73–7.63 |\n\n*\"Cold\" is the first read of a fresh clone this machine has never touched; \"warm\" is a second parse\nof the identical files immediately after — the only variable that changes is OS file-cache state.\nEvery language shows a large cold/warm gap (3.9x–16x); it isn't specific to any one parser or\nlanguage. Warm-to-warm, TypeScript actually parses faster than Python, and Java is right alongside\nit.*\n\nSee the [`benchmarks/`](benchmarks/README.md) folder for the full methodology, a webpack case\nstudy on what happens when a repo's default view doesn't collapse much, and the reasoning behind\nevery number above.\n\n## 🚀 Quick start\n\nRequires Python 3.12+, [uv](https://docs.astral.sh/uv/), and Node.js 20+.\n\n```bash\ngit clone https://github.com/venom21adi/Semantic_Vision.git\ncd Semantic_Vision\n\n# Backend — from the repo root\nuv sync\nuv run uvicorn semantic_vision.api.app:app --port 8000\n\n# Frontend — in a second terminal, from frontend/\ncd frontend\nnpm install\nnpm run dev\n```\n\nThen open `http://localhost:5173`, enter the absolute path to any local\nrepository. Detected languages (**Python**, **JavaScript / TypeScript**,\n**Java**) are pre-checked as chips — adjust the selection if needed —\nthen click **Load**.\n\nBy default, everything Semantic Vision saves (layout, impact analysis\nstate, generated docs) is written to a `.visualiser/` folder at the\nrepository's `.git` root — even if the path you loaded is a subfolder\nscoped down for performance on a large repo. A **Save location** field\nnext to the repository path shows and lets you override this before or\nafter loading; the first time anything is saved, a notice names exactly\nwhere it went, with an inline **Change** control to relocate future\nsaves without re-parsing.\n\n## 🐳 Run with Docker\n\nRequires Docker and Docker Compose.\n\n```bash\ngit clone https://github.com/venom21adi/Semantic_Vision.git\ncd Semantic_Vision\ncp .env.example .env # Windows CMD: copy .env.example .env\ndocker compose up --build\n```\n\nPre-built images are also published to GHCR on every change to `master`\n(`ghcr.io/venom21adi/semantic_vision-backend` and\n`ghcr.io/venom21adi/semantic_vision-frontend`, tagged `latest` and by\ncommit SHA) if you'd rather pull than build locally.\n\nOpen `http://localhost:5173` — with no further setup, it mounts the\nproject's own repo, so `/workspace/repo` gets you a ready-to-explore\ndemo. To point it at one of your own repos, set `REPO_PATH` in `.env`\nfirst:\n\n```bash\n# .env\nREPO_PATH=C:/Users/you/projects/my-repo\n```\n\nthen `docker compose up --build` and paste that same path (the real one\nfrom your machine, not `/workspace/repo`) into the app's repository-path\nfield — it's mapped into the container automatically. Point `REPO_PATH`\nat a *parent* folder instead of one repo to switch between several\nwithout editing `.env` or restarting each time; see\n[guides/docker-setup.md](guides/docker-setup.md) for that pattern, plus\nthe AI provider keys and where saved data lands.\n\n`REPO_PATH` is deliberately a one-time `.env` setting, not something the\napp can change about itself at runtime — see\n[\"Why REPO_PATH isn't configurable from the app itself\"](guides/docker-setup.md#why-repo_path-isnt-configurable-from-the-app-itself)\nfor why.\n\nLoading a large repo for the first time is noticeably slower in Docker\nthan natively (bind-mounted files cross the Docker Desktop VM boundary on\nevery read) — every load after that first one is much faster, since the\nbackend keeps an internal fast copy and only re-reads what actually\nchanged. See [\"Why the first load is slow\"](guides/docker-setup.md#why-the-first-load-is-slow-and-why-every-load-after-that-isnt) for the numbers.\n\n\n## 🧩 VS Code Extension\n\nThe fastest way to try Semantic Vision: install it straight from the\n[VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=venom21adi.semantic-vision)\n(search **Semantic Vision**, or `ext install venom21adi.semantic-vision`)\nand open a Python, JavaScript/TypeScript, or Java repo — no Python, no\n`uv`, nothing beyond VS Code itself. The backend it needs ships bundled\ninside the extension for Windows, macOS (Intel and Apple Silicon), and\nLinux.\n\n- **Semantic Vision: Open Graph** — opens the same interactive graph as\n the web app in a panel beside your editor, centered on whichever file\n you have open. Click any node to jump straight to that code.\n- **Semantic Vision: Impact Analysis at Cursor** (also on the editor's\n right-click menu) — resolves your cursor position to a graph node and\n highlights its full blast radius without leaving your place in the\n file.\n\nEvery other feature below — flowcharts, the complexity report, AI docs,\ncode-to-data lineage — works the same way inside that panel. See\n[vscode-extension/README.md](vscode-extension/README.md) for\nconfiguration details (e.g. pointing it at an already-running backend\ninstead of the bundled one). Prefer running the backend and frontend\nyourself, or via Docker? Both remain fully supported below.\n\n## 🧩 How it works\n\nSemantic Vision has three parts:\n\n- **Backend** (`src/semantic_vision/`) — a FastAPI service that walks a\n repository (Python's `ast` module, or `tree-sitter` for\n JavaScript/TypeScript and Java, chosen per load), resolves imports and\n call sites into a graph of nodes and edges, and serves it over a small\n REST API. Parsing is purely static: your code is never executed. AI\n documentation is generated separately, on demand, via\n [LiteLLM](https://docs.litellm.ai/) against whichever provider you\n pick. For a function, only its own source, its direct callers/callees'\n signatures, and its parent class header are sent; for a file, only its\n path, imports, and the signatures of what it defines — never a\n function body or the whole repository. Code-to-data lineage extends the same graph with table,\n column, and dbt-model nodes, from SQLAlchemy models detected in your code, a dbt\n `manifest.json` you point it at, and/or a live database connection\n string — held in memory for that one request only, never logged or\n written to disk.\n- **Frontend** (`frontend/`) — a React + TypeScript app that renders the\n graph with [`@xyflow/react`](https://reactflow.dev/) and `dagre`\n auto-layout, and persists your layout and saved analysis state in a\n `.visualiser/` folder inside the repo you're inspecting.\n- **MCP server** (`src/semantic_vision/mcp_server/`) — a thin wrapper\n exposing the backend's REST API as MCP tools over stdio for coding\n agents, described above; no analysis logic of its own.\n\n## 🛠️ Development\n\n```bash\n# Backend\nuv sync\nuv run pytest -q\nuv run ruff check .\n\n# Frontend (from frontend/)\nnpm install\nnpm run test -- --run\nnpm run dev\n```\n\n## 🤝 Contributing\n\nIssues and pull requests are welcome. This project is early and moving\nfast — for anything beyond a small fix, please open an issue first to\ndiscuss the approach.\n\n## 📄 License\n\nMIT — see [LICENSE](LICENSE).\n"}