Graphban — the stack view

Why it matters

One view answers three people's questions.

For the engineering lead

Where the risk is, by component: security findings, complexity hot spots, unfinished code, and which parts nobody has checked at all.

For the developer

What runs where and what talks to what, before touching it. Click a box for its surfaces, its connections and every finding, with the file.

For the agents

Tech debt stops being a vague backlog. One click turns a finding into a card on the board, where the fleet picks it up and it goes through review like any other work.

The map

An architecture diagram that draws itself.

Nothing is placed by hand. The layout is a function of the topology the API reports, so when the system changes, the picture does too.

① Code we write

Your deployables, grouped by where they run: user machines, agent hosts and outposts, and the compose or hosted stack.

② Infrastructure we run

What you operate but didn't write, such as the database, nested around your code.

③ External services

What you only call over the network, in its own column, so the boundary of ownership is visible.

Liveness on every box. Reachable, unknown or not configured. Never a healthy default.
The facts that drift, in one strip. The running version and commit, the database schema revision, the database engine and the live MCP tool count.
Edges say how. Connections are labelled by protocol, such as HTTP with JWT or HTTP plus MCP.
Hand it to an architecture review. Print or export the whole map to PDF at a readable fit.

What's missing is on the map too

Above the canvas, every absence gets a chip: no fleet registered, no email configured, no Linear sync, and how many catalogued providers are unwired. A diagram that only draws what exists makes a half-configured system look finished.

The health overlay

Every scanner's latest answer, on the component it's about.

Each component carries seven categories. A finding records its severity, file, scanner and version, and the commit it was scanned against.

Category	What it tells you	Fed by
Security	Vulnerable dependencies and risky code	pip-audit, npm audit, osv-scanner, bandit, semgrep, trivy
Refactoring · complexity	Hot spots: high cyclomatic complexity, oversized functions	radon, ESLint complexity
Partial implementation	Stubs and placeholders that shipped	a stub scan
Dead code	Functions, exports and files nothing uses any more	vulture, knip, ts-prune
Coverage	How much of the component the code map describes, and whether that description is stale	the code graph, built in
Tests	Whether the suite ran at the running commit, with passed, failed and skipped counts, and each failing test as a finding	pytest, vitest, jest, any JUnit report
Open work	Cards on the board that touch this component	the tracker, built in

The api component selected: an inspector panel lists its surfaces (REST, MCP, sync engine, provider-resolution) and code health, with a security finding from pip-audit and two refactoring findings from radon, each showing scanner, version, the commit it ran against, the file, and a Defrag button. — **Click a box.** Its surfaces, then every category: which scanner ran, when, against which commit, and each finding with its file. Demo instance with sample scan data.

No score

A component is never green by default.

There is no health score to game. Each category is in exactly one of four states, and the last two are never drawn as the first.

clean at head

Scanned at the commit that's running, with zero findings.

has findings

Coloured by the worst severity present, so one critical outweighs ten lows.

never scanned

Nothing has looked. Until something does, the state is unknown.

stale

A clean result at an older commit. It doesn't cover what's running now.

A component only rolls up clean when the result covers its whole tree. One clean file says nothing about the rest. That's why, in the screenshot above, fleet reads stale: its only scan predates the running commit. And cli shows a high finding even though nothing failed, because its test run executed zero tests. An empty run is not a pass, so it is recorded as one.

The scan report

The whole codebase's health on one screen.

Every component against every category, then every finding, filterable by severity, component, category and text. "Not run" and "stale" are cells, not blanks.

The scan report: a matrix of components (web, api, fleet, cli) against Security, Refactoring, Partial Implementation, Dead Code, Coverage, Tests and Open Work, showing clean, findings, stale and not run cells, followed by filter chips and seven findings, including a test run that executed zero tests with severity, component, category and file. — **Scan report.** Pinned to the running commit, with no score and nothing hidden. Demo instance with sample scan data.

Defrag

From finding to card in one click.

Every finding has a Defrag button that files it as a card on the board, tagged as tech debt. Defrag all files every unfiled finding on a component at once.

Filed once. A finding remembers that it was filed, so the same issue never becomes two cards.
Then it's ordinary work. The card is claimed, built in its own worktree, independently reviewed and verified by CI, like everything else on the pipeline.
And the next scan closes the loop. When the fix lands and the scanner runs again at the new commit, that category goes clean at head. The box follows once every category is.

Where the results come from

Your scanners, your repo. Graphban keeps the answers.

Graphban never runs a scanner. An agent working in your repo runs the tools you already trust and reports the results, the same way it describes code for the graph. CI can post them too, over a key-authenticated REST endpoint.

record_scan(scanner, path, scanned_sha, findings) No commit, no result. A clean scan without a revision can't be told apart from a stale one, so it is refused.

Coverage and open work need no scanner at all: they come from the code graph and the board. How the code graph is built →

Your whole system, and its health, in one place.