Twelve tabs. One map of your system.

Every page and component the frontend defines, listed with its route. Open one to see its component tree: each input, button and child component, with the event it fires and the handler that answers. Desktop forms are drawn as a wireframe from their real layout; web screens get a navigation diagram.

• Pages and components per project, searchable by screen or handler
• event → handler on every element — click a handler to open its call trace
• “Expand components” inlines each child component’s own tree
• Delphi .dfm + .pas and Qt .ui + .cpp pairs read as one screen

Pick any function and see it as a double tree: callers on the left, callees on the right, tables as green leaves. Links cross the HTTP boundary — a frontend call joins the backend route that serves it — and calls through dependency injection resolve to the class the container actually builds.

• “Reaches” sums up what a symbol touches: database reads and writes, API calls, queue messages — directly or several calls deep
• Diagram or List view, up to four levels each way
• Every edge is tagged extracted, inferred or ambiguous, with how it was resolved
• Ctrl/⌘-click any node to open it in your editor

Five views of one graph, each laid out deterministically, so the same code always draws the same picture. With compose, Kubernetes or Terraform files, deployment edges come from evidence — API keys, URLs and connection strings — rather than from someone’s memory.

An entity-relationship diagram recovered from ORM code and SQL: columns with primary and foreign keys, relationships with cardinality and join tables. Click an entity for its columns, its relationships and every function that accesses it.

• About 25 ORMs — EF Core, Hibernate/JPA, TypeORM, Prisma, Django, SQLAlchemy, Eloquent, GORM, Diesel and more — plus plain DDL
• Filter by source when a table is described twice, like a Prisma schema and its SQL migrations
• “Accessed by” jumps straight to each function’s call trace
• Inferred relationships are drawn dashed

Every route the backends expose and every API call the frontends make, matched by method and path. Each row keeps what the code says about the endpoint, not just where it lives.

• Auth: anonymous, policies, roles, schemes or guard middleware
• API versions, with deprecated ones struck through
• The request body type and how each parameter binds — body, query, route, header
• Outbound calls marked when they match a known route — or the third-party service they reach; click a route for its trace
• Route gaps: calls that reach no route, with the reason, and routes no call reaches
• Contract findings: a body missing a field the route requires, a response read for a field it never returns

Starting from every entry point — each endpoint and each screen — ClarifyDoc follows the calls to the data effects they reach: database reads and writes, outbound API calls and queue messages, however many calls deep.

• Direct effects and those reached through calls, shown apart
• How many endpoints and screens reach a write
• A screens → endpoints → tables diagram, writes in red; click a node to filter
• Entry points that aren’t routes, too: MCP tools, CLI and editor commands
• Filter by effect or entry type; click a bar to filter the table

A grade from A to F with the penalties that produced it, and the findings behind them: patterns and anti-patterns, security issues, ranked suggestions, duplicated code, layer violations, dependency cycles and dead code.

• Each penalty opens the findings that caused it
• Suggestions ranked by priority, each ending in a concrete next step
• Dead code: files no entry point reaches, exports nothing imports and unused imports — tuned so that “maybe used” stays off the list
• Performance patterns: a query inside a loop, a blocking call inside async code
• Security findings traced across files, from request input to the call it reaches; webhooks that never verify their signature
• Findings from Semgrep, CodeQL or any SARIF tool, joined to the routes that reach them
• The riskiest files to change, from the blast-radius analysis

Every file ranked by how far a change to it would reach. Pick one for a plain-language verdict, the screens, routes and tables on the other side of it, and the files that depend on it — directly or transitively.

• Risk to change — dangerous, moderate or safe — and the file’s role: foundation, boundary, flow, shared
• Cross-tier reach: the screens, API routes, tables and queues a change would touch
• Exported symbols, with exactly which files use each one

Cyclomatic complexity per file and per function. With git history, each file also gets its commit count, when it was last touched and a hotspot score — churn × complexity — so you can sort by where risk actually piles up.

• Expand a file into its functions, with line ranges
• A treemap of folders and files sized by complexity
• With git history, every file plotted by commits against complexity — the changed-often-and-complex corner is where to refactor first
• In VS Code, click a function’s complexity to see it drawn as a flowchart

The graph’s own signals: how much of it was extracted versus inferred, the god nodes everything leans on, connections that bridge parts of the system that otherwise don’t talk, questions worth asking, and the communities the files fall into.

• Confidence distribution across every link
• God nodes, by combined in- and out-degree
• Surprising connections, with the reason each one stands out
• Communities named after what they contain
• Knowledge risk: with git history, the files only one person has ever changed, ranked by the routes and tables they carry

Every package declared in every manifest, across ecosystems — npm, NuGet, Maven, PyPI, Composer, Cargo, Go modules and more — with its version, category, scope and whether any code imports it.

• Frameworks, ORMs and databases sort first
• Used, unused or unknown — “unused” is only claimed where every import is visible
• Filter by ecosystem, category or usage

The headline numbers — files, screens, interactive elements, routes, links, call traces, frameworks, packages and the health grade — with trace confidence, the sub-projects found and, given git history, the top churn × complexity hotspots.

• Sub-projects detected from their markers: package.json, *.csproj, go.mod, pom.xml and more