Technical reference
Current Core loaders, stable public contracts, and source locations.
This is a map to the current implementation. Core splits functions by responsibility and validates public loader manifests in CI, so source the loader rather than an arbitrary part file.
| Need | Use/read | Source |
|---|---|---|
| Start a CT script | core/build.func | Core build loader |
| Output, prompts, logging, errors | core/core.func + catch_errors | Runtime |
| Container default/advanced flow | ui/build-ui.func | Wizard |
| Application install helpers | Prepared FUNCTIONS_FILE_PATH / lib/tools.func | Libraries |
| Alpine install helpers | Prepared FUNCTIONS_FILE_PATH / lib/alpine.func | Containers |
| Host backend | pve/ or incus/ | Platforms |
| VM support | pve/vm-core.func or incus/vm-core.func | VM paths |
| Telemetry | api/api.func | Telemetry |
| Generated update command | misc/update.sh | Updates |
Generated API inventories
Core keeps generated API inventories beside loaders: lib/API.txt,
api/API.txt, and
ui/API.txt.
When changing a Core function in one of those areas, update its inventory in the
same Core pull request. CI compares the inventory with the functions the loader
actually exposes.
Rules that prevent source drift
- Use folder-qualified Core paths such as
lib/system.func; several Core areas intentionally use the same basename. - Never hard-code a Core raw URL after
core/build.funchas loaded. Use_cs_source_funcfor Core code, and let the script root remain independent. - Do not import individual UI, API, or library parts from application scripts. The loaders establish required ordering and dependencies.
- Treat the source revision as the final authority; this reference deliberately links to the current Core structure instead of duplicating a frozen function list.