Code map
The code map is the picture Cactus draws of your product from its code: the files it reads, the screens, buttons and text they show, and how those parts link together. Answers and help pages draw on it, so they point at real places in your product.
Read, skim and skip
Cactus sorts the folders of your code into three ways of reading them, and each folder gets one.
- Read: the product's apps, services, workers and libraries, its API and data schema, and the agent instructions the product itself runs.
- Skim: names and signatures only, not the code inside them. This covers the product's tests and a client generated from the product's own API.
- Skip: code that only builds, runs, tests or develops the product, such as CI, deploy and ops scripts, dev tooling, benchmarks, examples and templates, fixtures, and vendored or generated code.
A skipped file stays listed by its name, but its contents are not read.
What the map holds
- Files, and the functions, classes and other definitions in them, each with the lines it starts and ends on.
- For a line of a file, the region of code that holds that line.
- Screens and routes, the addresses they answer at and the methods they accept.
- Buttons and their labels, with the conditions that decide when they show.
- Text shown on screen, translated text and the keys they come from.
- Values such as plans, limits and defaults, each with the line that sets it.
What it leaves out
- Dependency folders and build output, such as
node_modules,vendor,.nextand build caches. - Binary files and links to other files.
- Lockfiles, minified scripts, source maps, images, data tables and log files. These stay listed as files but are not treated as your code.
When the map changes
A build decides the code plan again when the layout of your repositories changes. Otherwise it keeps the plan from the last build.
A page can take a while to change after the code does, because a build has to run first.