magus v0.4.2 is out. See what's new
¶ View generated markdown
1 min read

magus-explain

Show one knowledge-graph node's context: data, edges, and reach

Synopsis

magus explain <node-id-or-name> [flags]

Description

explain shows one node's context: its data, its incoming and outgoing edges with provenance, and how many nodes reach it. Where query finds candidates, explain is what you run on the one you picked.

The argument is a node ID (target:pkg/foo:build) or a name that resolves to one (build). Names are convenient and IDs are unambiguous; when a name matches more than one node, resolve it with query first and pass the ID.

Two parts of the output are worth knowing about. Every edge carries its PROVENANCE - what declared it, so a surprising relationship can be traced to the file that created it rather than taken on faith. And the reach count answers the blast-radius question directly: how many nodes can arrive at this one.

The graph is cache-backed under <cache>/knowledge and only shards whose sources changed are rebuilt; --refresh forces a full rebuild.

Options

--global
Resolve across the workspaces registered in config (knowledge.workspaces)
--refresh
Force a full graph rebuild before explaining

Examples

A target in full

magus explain target:pkg/api:build

Resolve by bare name

magus explain build

A spell's context

magus explain spell:go

As a record

magus explain build -o json

See Also

magus(1), magus-ls(1), magus-describe(1), magus-run(1), magus-x(1), magus-where(1), magus-affected(1), magus-graph(1), magus-query(1), magus-path(1), magus-refs(1), magus-watch(1), magus-events(1), magus-status(1), magus-clean(1), magus-vcs(1), magus-doctor(1), magus-config(1), magus-session(1), magus-memory(1), magus-notes(1), magus-diff(1), magus-server(1), magus-mcp(1), magus-buzz(1), magus-completion(1), magus-man(1), magus-init(1), magus-agent(1), magus-self(1), magus-version(1)

generatedinternal/cli/registry.goclimagus explainexplainknowledge graphnodeedgesprovenanceimpact
Last updated (4f8cc295)
Earlier changes on this page (7)

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.

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.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). See operations.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. See spells.

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

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.

Trace

OpenTelemetry's name for one whole magus invocation; every target it runs is a span beneath it. See telemetry.

Knowledge graph

The queryable graph of a workspace's spells, targets, docs, and code relationships; query it with magus query/explain/path. See knowledge.

MAGUS.md

The committed routing index at a workspace root, regenerated from the knowledge graph: it lists every node and points at the exact query for a given question, so it is the entry point an agent reads first. See knowledge.

Session

One magus process's recorded facts - the targets it finished, their outcomes, and the lease it acted as - kept in a repo-scoped store every worktree shares. magus session lists them; the store prunes itself by last-fact age.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.