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

magus-path

Connect two knowledge-graph nodes: the shortest chain of edges between them

Synopsis

magus path <a> <b> [flags]

Description

path connects two nodes: the shortest chain of edges between them (edges walked in either direction), with each hop's relation.

It answers the question the other two verbs cannot: not "what is this" or "what does this touch", but "how are these two related at all". That is the question worth asking when a change to one thing breaks a seemingly unrelated other, or when you suspect two projects are coupled and want the chain rather than a hunch. Each hop names its relation, so the answer is a mechanism you can check and not just a claim that a connection exists.

Edges are walked in EITHER direction, which is what makes it useful and is also its main caveat: a returned chain proves the two nodes are connected in the graph, not that influence flows from one to the other. Read the hop relations to see which way each link actually points.

Each argument is a node ID (target:pkg/foo:build) or a name that resolves to one. The graph is cache-backed under <cache>/knowledge; --refresh forces a full rebuild.

Options

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

Examples

How are two projects related

magus path pkg/api pkg/web

From a spell to a diagnostic

magus path spell:go MGS3003

Between two targets by ID

magus path target:pkg/api:build target:pkg/web:test

As a record

magus path pkg/api pkg/web -o json

See Also

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

ManpagePages in this section. magus graphEmit the project dependency DAG, export the knowledge graph for external graph tools, and report the graph's shape (god nodes, orphans, doc coverage). magus queryResolve search terms to knowledge-graph nodes and return the ranked matches plus their neighborhood; also retrieves a target's captured output by ref and a run's journal by invocation id. magus describeDefine a magus concept (spell, charm, target, project, workspace, module, mcp-tool, tool, file, graph, harness) and list every entity of that kind, or detail one when a name is given.
generatedinternal/commands/registry.goclimagus pathpathknowledge graphshortest pathrelationshipcoupling
Last updated (29d8b3de)
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. Workspace in full.

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. Project in full.

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. Target in full.

Op

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

Spell

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

Buzz

The language magusfiles are written in (the .buzz engine). Buzz in full.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. Cache in full.

Affected

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

Broker

The per-user background process that holds this host's capacity: the machine budget every run claims slots from, and the shared services runs keep warm. A run starts it on demand; broker: off in magus.yaml runs without one. Broker in full.

Knowledge graph

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

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. MAGUS.md in full.

Agent

A model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent in full.

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. Session in full.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the daemon, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. Job in full.

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. Run in full.

Conventions

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