How it works
Your code becomes a graph. Everything else is computed from it.
There is no step in which a model looks at your repository and forms an opinion. The analysis builds a graph of your system, the rules run against that graph, and every number on every screen can be traced back to a file and a line. A model may phrase an answer; it may never create a node, an edge or a score.
The four steps
It reads your repository where it already is
The command-line scan runs in your checkout — in your terminal or in your own CI. It uses the language server for each language, the same one your editor uses, so what it knows about a language is what that server knows rather than a parser we wrote and have to keep current.
It builds the graph
Services, routes, modules, files, functions and the data stores they read, with the edges between them: imports, calls, reads, writes, renders, requests. Every edge is marked as read or inferred, and an inferred edge is drawn as one.
The rules run against the graph
Each rule declares what it needs. A rule whose inputs are missing is recorded as not run rather than as finding nothing — so a region of your code the scan could not read never renders as a clean one.
A report is uploaded; your source is not
What leaves your machine is findings, paths, line numbers and the graph. The database has nowhere for source to live, which is a property of how it is built rather than a promise.
Where you read the answers
- The console: the architecture of your project, the issues, and what a change reaches.
- Your editor’s coding agent, over a local MCP server with 6 read-only tools — so the assistant answers from what was measured in your repository instead of what it inferred from the files it happened to open.
- A badge for your README, from the last report you published.
- A resident process that answers while you work, installed with mlreps hooks install. It runs on macOS and Linux; it has not been measured on Windows, and on Windows the command line says so instead of starting it.
- Your CI: the scan exits non-zero on what you tell it to fail on, and the report is published from the same run.
What it finds, and how narrow that is on purpose
The performance rules read 6 database libraries and no others: Prisma, Drizzle, Sequelize, TypeORM, Django, SQLAlchemy. A call counts as a query only against a model your own schema declares, and as being in a loop only when it sits in the body of a loop over a collection of items.
A miss costs one unreported problem. A false report teaches somebody to ignore the whole screen, which costs all of them — so the rules are written to be believed rather than to be many, and what they refuse to call a problem is written on the page beside what they find.
What it cannot do
- Anything that depends on observing your software while it runs. Nothing is installed in your application and nothing is collected from your users, so it cannot tell you what your traffic did last night.
- Draw the half of a request path that starts in the browser. The map draws the server half, traced from the code; screen-to-API edges read “not measured yet” rather than being guessed.
- Teach you to be a better engineer. A finding carries the pattern it matched and a prompt that carries out the fix; it keeps no record of what you have learned and makes no judgement about you.
- Score your repository. There is no grade, no letter and no health number, because the measurement behind one of those does not exist yet.
The rule the whole thing is built on
The graph answers and the model explains. A deterministic answer is assembled first and the model is handed it to phrase — so the answer survives the model being absent, wrong, or switched off. It is switched off today, and the analysis is unaffected.
Two ways in
Run it yourself and your code never leaves your machines, and every language with an adapter is read. Install the GitHub App and your commit is copied to our analysis server, where TypeScript and JavaScript are read — nothing is installed on your side.