MGS1015: cross-project dependency names an unresolvable project
A target declared ctx.needs on a target in another project, and the path the
alias came from does not resolve to a path inside this workspace.
[MGS1015] workspace://docs: target "ci": ctx.needs names a target in
"../../elsewhere", which does not resolve to a path in this workspace
Why
ctx.needs(agents\lint) says two things: run that target first, and treat the
other project as an input to this one. The second half is the one that decays
quietly.
The resolved path is unioned into this project's depends_on, and that record is
what the affected set is computed from. magus affected walks the dependency
edges in reverse: a change to an upstream project marks every project that
depends on it. Drop the edge, and that reverse walk no longer reaches here.
The failure is invisible in exactly the way that matters. The build still runs, the target still passes, and CI still goes green. What stops happening is the invalidation: an edit to the upstream project no longer marks this project dirty, so the next run replays a cache hit built against the older upstream. Nothing reports a problem, because from the cache's point of view nothing changed.
That is the same consequence the cross-project output side raises MGS1011 for, which is why this one is a load error too. The cross-project input side can afford a best-effort drop, because an under-declared input only weakens a cache key and errs toward re-running. An under-declared dependency errs toward not running, which is the direction that serves stale results.
Cause
The path written after project/ in the import does not resolve to a location in
this workspace. Import paths are always relative to the directory of the
magusfile that writes them, so a path is measured from there, not from the
workspace root:
// in docs/magusfile.buzz
import "project/guides/integrations/agents" as agents; // -> docs/guides/integrations/agents
import "project/../libs/textsearch" as textsearch; // -> libs/textsearch
An import that climbs above the workspace root, or names an absolute path, has no in-workspace answer and lands here.
Resolution
Check the import "project/..." line the alias comes from, and count the ../
segments from the importing magusfile's own directory. Then confirm the target
project is one magus actually discovered:
magus ls
If the path resolves but the project is missing from that list, the import is
fine and the directory simply is not a project yet: it needs a marker
(magusfile.buzz, magus.yaml, or a language marker) and must not sit under an
ignored directory such as gen/ or node_modules/. That case is reported
separately when the graph is built, as an unregistered dependency.
If you did not mean to depend on another project, drop the alias and name a same-project target instead:
ctx.needs(build);