The codebase, mapped
Curious what FULCRUMAXE actually is? Rather than ask you to clone it and read 4,000 files, here is the whole engine as an interactive knowledge graph — modules, layers, dependencies, and a guided tour through how the loop fits together. It runs entirely in your browser. Nothing to install.
Heads up: the graph is a few megabytes and renders best on a desktop browser.
If you only look at three things
Take the tour
The graph ships with an ordered walkthrough that starts at "what this system is" and ends at "what guards a merge." It is the fastest honest answer to what the project does.
Look at the layers
The engine is grouped into architectural layers — the agent role and spawn system, the loop orchestration, the dashboard, the review gates. Toggle one to see just that slice.
Follow a single role
Search for executor and follow its edges. One agent role fans out across a role card, a prompt template, and shared prompt fragments — which explains why so many PRs touch several files to change one behaviour.
What the code itself says
The graph above is a map. These are the measurements underneath it — counted from the files themselves rather than reported by an API, and drawn from the same release manifest that decides what the graph may show. Nothing here is an estimate of a private repository. It is a count of what ships.
What it is written in
Share of code lines in the published tree.
How it ships carries a language chart too, and the two disagree on purpose. That one is GitHub's byte share of the whole public repo; this one is lines of code across the manifest's publishable set. Different denominators, different question.
How much of it is tests
— test files carrying — lines of test for every line of source.
A file counts as a test if it sits in a tests/ directory or is named
the way its ecosystem names tests — test_*.py,
*.spec.ts, and so on. That is a convention, not a fact about what a
file does, so read this as close rather than exact. It is deliberately strict:
the browser-tester agent's own source, the vitest configs and the operational
*-test.sh scripts are all counted as source, not as tests.
The largest modules
Source files by written lines, tests excluded.
Measured at — on .
Comment counts include Python docstrings, which the language does not call comments
but every reader does. Python is counted with the language's own parser; the other
languages with a scanner that tracks string literals, so a /* inside a
string cannot open a comment.
What's in this graph
This is the publishable surface of the engine — the same set of paths the project's own release manifest certifies as shippable: the Python and TypeScript backends, the dashboard, the operational scripts, the sandbox hooks, the agent role and command definitions, and the root documentation.
Internal team state, operator notes, the archive of retired code, and local training tooling are excluded by that same manifest and are not represented here. So the graph is an honest map of the product, not of every file on a maintainer's disk.
Built with Understand Anything (MIT), an open-source tool that combines tree-sitter static analysis with LLM summarisation to turn a codebase into a navigable graph.
This page is generated by tools/build-understand.sh
from a static analysis of the engine’s source tree. Nothing on it is written by hand.