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

MGS1031: a project's output is another project's source

One project declares a file as an output. A different project's source glob also claims it. Both declarations are individually reasonable, and together they arm a report that blames the wrong project.

[advice] output-is-another-projects-source: 11 declared output(s) are also another
project's source
    libs/testlayout/MAGUS.md is libs/testlayout's output and .'s source

Why it matters only later

Nothing misbehaves while the file's content is stable. The moment it changes:

  1. the owning project's generate rewrites it, which is exactly its job
  2. the claiming project is running a target that declared the same path as a source
  3. that target sees a declared input move underneath it and reports MGS4007 - an undeclared source mutation

The report is true about the write and wrong about the cause. The file is generated by definition, and the project named in the message never wrote it.

This is why the check is static. The conflict lives in the declarations, so it can be answered before anything runs - and it is present for as long as the two globs overlap, not only on the day some content drifts. In magus's own tree it sat on four projects' MAGUS.md files for as long as the markdown spell has claimed **/*.md, and only the one whose bytes went stale ever surfaced it.

What to do

Decide which project owns the file, then make the declarations say so:

  • Narrow the claiming glob. Usually right when the claim is incidental - a broad **/*.md from a spell sweeping up a nested project's generated index.
  • Move the file into the owning project's tree, if it is only claimed because of where it sits.
  • Leave it, deliberately. A file genuinely read by one project and written by another is a real relationship; declare the dependency so the ordering is explicit rather than incidental.

It is advice, not a failure, for the reason MGS1028 is: which project owns a file is the workspace's judgment, and a check that failed on it would be dictating a layout it cannot see the reasons for.

Exact paths only

The check compares an exact output path against the other project's globs. Whether two globs can overlap is not decidable in general - the same line MGS4002 draws - but whether a pattern matches one literal path is. An output declared as a pattern (dist/**) is not reported.

magusfile diagnosticsLanding page for MGS1xxx diagnostics that flag authoring mistakes in a workspace's magusfile, such as missing targets or unresolved declarations. magus stdlibReference for every magus stdlib module - fs, os, http, json, yaml, crypto, and the rest of the magusfile API surface. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets. magus DocumentationThe magus documentation hub covering install, targets, spells, charms, operations, engines, remote caching, MCP, telemetry, and the interactive playground.
MGS1031magusfilesourcesoutputsgenerateddoctor
Last updated (407edfa7)
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.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. See targets.

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.

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.

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.

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 server, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. See doctrine.

A job is not a run. magus run build web is a run, and no job exists for it. A job causes runs: its check executes as one, and a server job records the invocation of its last one. Jobs are listed with magus ls jobs and in the console's Jobs view; runs are listed in the Runs view.

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.

Conventions

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