Workspace
The magus root directory that owns a set of projects and shared config; the unit
magus operates over. See workspace.
Project
A directory magus recognizes as a unit of work (it has a magusfile); the unit of
caching, scheduling, and dependency tracking. See workspace.
Magusfile
The magusfile.buzz that declares a project's targets (as export funs) and
binds its spells. See targets.
Target
A named operation (build, test, ...) you invoke with magus run <target>; it
may compose a spell's tool-native operations and depend on other targets. See
targets.
Spell
A language/runtime adapter (e.g. go, md) that maps generic targets onto a
toolchain's real commands. See spells.
Manifest
The file that declares what a package is: its name, dependencies, entry points
and tool config (go.mod, package.json, pyproject.toml, Cargo.toml). How
the workspace builds, tests and lints the package belongs in the magusfile, not
in the manifest's scripts. See
spells.
Cache
The content-addressed store magus consults before running a target, so unchanged
work is skipped. See cache.
CI
An ordinary magusfile-defined target you compose yourself with magus\needs:
magus does not hardcode its stages. Magus.RunCI treats it specially only in
that it strips the rw charm, it is the anchor magus affected ci keys off,
and a selected scope with no project declaring it is a load error rather than
a silent no-op. See targets.
Health
The at-a-glance server state derived from the pool: healthy when the pool is
reporting, degraded when it reports an error, down when there is no pool.
The dashboard color-codes each state. See server.
Run
One target executing under one magus invocation, such as magus run test web
or magus affected ci. A run keeps its captured output behind an output
reference. Every magus run is a run whether or not any job asked for it; see
Job for how the two relate.