---
title: "MGS1015: cross-project dependency names an unresolvable project"
description: Fires at load when ctx.needs references a target through a project import whose path does not resolve to a path in this workspace, so the dependency edge would be dropped and the affected set would silently under-report.
tags: [MGS1015, magusfile, needs, cross-project, load, affected]
---

# 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.

```text
[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](MGS1011.md) 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:

```buzz
// 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:

```text
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:

```buzz
ctx.needs(build);
```

## See also

- [MGS1011](MGS1011.md) - the same class of failure on a cross-project output
- [MGS1010](MGS1010.md) - the affected set becoming uncomputable