Magusfile Module Reference

These are the runtime utility modules. Import each under its bare name (import "fs", then fs\glob(...)) with camelCase methods. magus layers these host methods onto Buzz's own stdlib, so a single import "fs" (or os, crypto) carries both sets of methods, and the magus forms are sandbox-aware where Buzz's bare stdlib is not. Methods that are also in Buzz's own standard library are marked with an asterisk (*) and a footnote on their page; either form works.

Files and paths

Process and environment

Text and formatting

Serialization and encoding

Cryptography

Networking

Time

Versioning and version control

Magus internals

Provider namespaces are wired by the runtime rather than declared here, so they do not appear in the method list below: magus\cache.remote(<spell>) selects a remote cache provider, magus\ci.provider(<spell>) a CI provider, magus\secret.provider(<spell>) / magus\secret.read(<ref>) a secret provider and the credentials read through it, magus\harness.provider(<spell>) an agent-host harness (many hosts; like workspace.provider, unlike cache.remote's one), and magus\guard.shell(<rule>) an additive shell-guard rule (strengthen-only), and magus\guard.spawn(<fun>) the one function the agent guard calls on every spawn and continuation (see magus\guard.spawn), and magus\guard.command(<fun>) the one function it calls on every agent shell command (see magus\guard.command), and magus\guard.write(<fun>) the one function it calls on every agent file write. Each provider takes an imported spell handle. magus\secret.endpoint(<grant>) serves the case read cannot: it returns a loopback base URL a CHILD PROCESS is pointed at instead of the real API, so magus attaches the credential on the way upstream and the child never holds it. It takes an object with ref/host/header/prefix fields, declared in your own magusfile. For your own code, read is the ordinary choice. See Secrets, Remote cache and CI integration.

import "magus" is how you reach any of this. The namespace is an ordinary host module, like fs or vcs: without the import line magus is undefined, and the import is what attaches these signatures to your call sites. It resolves in a magus buzz script as well as in a magusfile, and a script run inside a workspace reads that workspace: describe.project, affected, projectGraph, where, insight, the knowledge-graph reads (query, explain, path, refs, stats, importGraph, dir, dirs, layer, neighborhood) and output all answer in-process, and so does magus\job (list, put, register, exit, wait, clear): the job store an orchestrating agent declares about work it handed out (see types.Job). The magus job CLI subcommand is a third write door onto the same rows: ls and describe read, fork declares a row, exec records a worker's landed base, and wait blocks on a dependency. Only the members that DECLARE into the workspace being loaded (magus\project, the provider selections above) raise MGS1022 in a script: there is nothing for them to declare into. Run a script outside any workspace and the reading members raise it too, since there is no workspace to read. The nested-command methods (cmd, run, doctor, and the magus\describe methods that fork) work there either way and discover the workspace themselves. | | charm | Constructors for charm values: RFC 6902 JSON Patches over a target's argv (see docs/charms.md). |

Other

See also

• Targets: the runnable units whose magusfiles call these modules.
• Spells: language and toolchain adapters that compose these modules into ops.
• Charms: the execution modifiers the charm module constructs.
• Playground: exercise these modules live in the browser.