magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
1 min read

raw-tool

A deny rule: it refuses a toolchain command a spell already wraps, run outside the cache, and names what to run instead.

What it catches

A toolchain command a spell already wraps, run outside the cache.

Why

magus covers these exactly and adds cache, sandbox and affected tracking, so the refusal costs nothing: magus run <target> <project>, and magus describe targets -o name lists what this workspace calls them. Tool flags go after --. A raw WRITE (codegen, a formatter with -w/--write/--fix, go mod tidy, build output landing on a tracked path) is the firm half: it leaves the owning target reporting drift it did not cause, and that has no exceptions. The guard reads the command being RUN, so a wrapper, a VAR=value prefix or bash -c reaches the same verdict, and go -C <dir> <verb> reads the same as go <verb> -C <dir>. One build is exempt, in a checkout of magus itself: go build -o magus ./cmd/magus, alone on its line, into a checkout root that has no magus binary yet, is advised rather than refused, because a fresh checkout has no other way to get its first binary. Once the binary exists the deny applies again and names ./magus run go-build ., which regenerates the embedded spell bytecode a bare link bakes in stale. It was an advisory first, and changed behavior zero times over a long session while leaving the Go build cache poisoned by uninstrumented runs, which is why it denies.

Seeing it

A verdict names its rule in brackets, which is how you got here:

deny [raw-tool]: ...

magus describe rule raw-tool prints the same entry at a terminal, and magus describe rules lists every rule this workspace enforces.

See also

  • All rules - what this workspace enforces, deny first
  • The guard - how a verdict is reached and wired
guardrulesraw-tooldeny
Last updated (f789c259)
Earlier changes on this page (1)

Full history ↗ · Blame source ↗

Glossary

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.

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.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. See cache.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. See affected.

Sandbox

The restricted filesystem and environment a target runs in, so builds stay reproducible and side-effect-free. See sandbox.

Session

An agent host's conversation, by the id the host delivers to its hooks. magus never mints one: a record with no session is unattributed, and the OS user it carries says whose account ran it.

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.

Advisor

One read-only check from the advice suite: it reads the changeset through magus and writes one titled section of findings. The same advisors run as a pull request comment in CI and inside magus diff --impact locally.

Conventions

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.