How it reads code

How it reads code

Everything is read from git objects (git ls-tree, git cat-file --batch) or from a folder. There is no checkout, and nothing is imported or run. The reading is pattern-based, which is fast and predictable, and has known limits (below).

Observed from the code

What	How
Connections between parts	Python import / from … import (relative ones too) and JS/TS import, import(), require(), resolved to files of the repository; anything else (the standard library, packages) is ignored
Entry points	FastAPI-style @router.get("/…") / @app.post(…), with the APIRouter(prefix=…) of the file
Front end → API	string literals starting with /api/ in JS/TS, matched to [[api]] prefixes
Settings	os.getenv, os.environ[…], os.environ.get, import.meta.env.X, process.env.X
Outside systems	the settings above matched to [[externals]], drawn when a deploy file sets them
Containers	the services: of the compose file: image, command, ports, replicas
Tables	CREATE TABLE and ALTER TABLE … ADD COLUMN in the migrations (comments stripped first)
Tests	files matching tests, used for the test-gap check

Declared in the config

The names of the parts, their columns, and which files they own. A code file no part claims becomes an undeclared part named by its folder, and is drawn with an amber band so it gets named.

Limits

• An import inside a string or a docstring is read as an import.
• Routes are FastAPI-style decorators; other frameworks need a reader (planned as plugins).
• Dynamic imports with computed names, and settings read through a wrapper (settings.get("X")), are not seen.
• The compose reader understands the common layout, not all of YAML.

None of this changes between runs: the same code gives the same map.