magus resolves configuration from three layers, highest precedence first: a CLI flag, a MAGUS_* environment variable, then the magus.yaml file at the workspace root. This page is the complete inventory of config keys, each with its magus.yamlpath, environment variable, CLI flag, and value type.
Last updated (3e1b75ad)Earlier changes on this page (2)
e0463131 - Add install script for easy curling (#2)
b022d75e - reorganize the docs into a concepts/guides/reference/migrating hierarchy: move ~160 pages and recompute every cross-link; keep documentation/glossary/conventions top-level (the refDocHtml embed assumes depth-1) and file operations under concepts; retarget the doc generators (magus-docs/spelldocs/manpage/examples/configdocs) plus their emitted links, the tour/development/nav/route SSG references, and diagnostic.go's codes URLs; retire the 137 moved URLs in retired.urls.lock; regenerate the site and MAGUS.md
The magus root directory that owns a set of projects and shared config; the unit
magus operates over. See workspace.
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.
Charm
An execution modifier attached with : (lint:rw) that changes how a target
runs, not which one; the built-in rw flips a check-only target to mutate in
place, and ci always strips it. See charms.
Cache
The content-addressed store magus consults before running a target, so unchanged
work is skipped. See cache.
Sandbox
The restricted filesystem and environment a target runs in, so builds stay
reproducible and side-effect-free. See sandbox.
Service
A long-running or shared process magus manages across runs, distinct from a
one-shot target. See services.
Daemon
The background magus host that owns shared state such as services and the warm
knowledge graph. See daemon.
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.
Pool
The concurrency pool: the shared set of slots that caps how many targets run in
parallel on one machine. Its capacity defaults to MAGUS_CONCURRENCY, then 4 on
GitHub-hosted runners, then min(NumCPU, 8); magus status and the
dashboard report it live. See daemon.
Concurrency
How many targets run at once. It is bounded by the pool's capacity and set with
--concurrency, MAGUS_CONCURRENCY, or the concurrency config key. See
daemon.
Volatility
A target that fails once and passes on rerun is volatile, as opposed to a
regression that started failing and stays failing. magus keeps per-target
pass/fail history and a Wilson-score volatility rate to tell them apart and
auto-retry the noise. See volatility.
Conventions
Documentation conventions
A few conventions run through every page on this site. This page is the key.
Placeholders
Angle brackets mark a value you replace with your own - never type the brackets:
magus run <target>
magus completion <shell> # e.g. bash, zsh, fish
<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.
Command synopsis notation
Every synopsis on this site and in magus <verb> -h and the manpages uses the
same five marks. This is the whole vocabulary:
notation
means
example
<value>
required; replace it
magus run <target>
[thing]
optional; omit the brackets if you use it
magus ls [flags]
<a|b|c>
required, and one of these exact words
magus completion <bash|zsh|fish|powershell>
<value>...
repeatable; one or more, space separated
magus describe file <path> [<path>...]
word[s]
the s is optional - both spellings work
magus describe spell[s]
The last one is the only place square brackets do NOT mean "optional argument":
spell[s] means magus describe spell and magus describe spells are the same
command, not that s is a separate thing you can pass.
Combining them reads left to right, so [<path>...] is "optional, and if you give
it, one or more paths":
[flags] and [args] are categories rather than placeholders - there is nothing
called "flags" to substitute. Run the command with -h to see which it accepts.
A bare -- ends magus's own arguments; everything after it is passed through
untouched to whatever the target runs:
magus run test libs/foo -- -run TestX
Values are written --flag <value> in synopses, but every magus flag also accepts
--flag=<value>, -flag <value> and -flag=<value>. Pick whichever reads
better; they parse identically.
Some flags take a comma-separated list, which is written as one value. Spaces
around the commas are trimmed and empty entries are ignored:
magus status --probe=mcp,liveness
A few take a structured value spelled key=<value> pairs, comma separated. Where
a pattern is accepted it is always the same three types:
magus watch --ignore type=glob,pattern='**/node_modules/**'
magus where --filter type=regex,pattern='^libs/'
Shell commands
Command blocks omit the shell prompt - copy the whole block as-is, no leading $ or
> to strip. A # comment on or after a line shows expected output or an aside:
magus version
# magus 0.4.2
Windows examples are shown in PowerShell and labelled as such.
Reading Buzz: the backslash
Buzz code on this site is full of names like fs\readFile and magus\project. The
backslash is namespace access - it reaches into a module. Most languages spell this
with a dot, so it is the one piece of syntax worth knowing before you read anything
else here.
Buzz uses both separators, and the distinction is what they reach into:
final body = fs\readFile("VERSION"); // backslash: a function IN the fs module
ctx.needs(build); // dot: a method ON the ctx value
Backslash reaches into a module; dot reaches into a value you already have.
So os\exec is the exec function the os module provides, while site.docPages
is a field on the site object. A module name never appears on the left of a dot,
and a variable never appears on the left of a backslash.
Some Buzz code blocks are live: a Run button appears in the corner and executes
the snippet in the in-browser playground via WebAssembly - no
install needed. Blocks without the button are illustrative only. (With JavaScript
off, every block is plain, copyable text.)
Admonitions
Call-outs are rendered from GitHub-style alert blockquotes and carry a colored accent
per type:
Note
Context worth knowing, but not a warning.
Warning
Something that can bite you if ignored.
The types are NOTE, TIP, IMPORTANT, WARNING, and CAUTION.
Footnotes
An aside that would break the flow inline is written as a footnote: a bracketed
superscript like this1 links to a short note at the foot of the page, which
links back. The generated module reference uses them to flag methods that also exist
in Buzz's own standard library without cluttering each signature.
Reach for a footnote when a sentence needs a source, a caveat, or a pointer that
would derail it inline: a citation or external reference, an edge case that qualifies
the claim, or a "see also" that is worth keeping but not worth interrupting the
thought. Prefer a footnote over a parenthetical that runs long, and over dropping the
detail entirely.
Code-block titles
A fenced block can carry a filename or label in a small caption bar above it, so you
know which file a snippet belongs in (for example a magusfile.buzz).
Diffs
A ```diff block shows a change: added lines (leading +) render as a green band,
removed lines (leading -) as a red one.