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

MGS3018: a directory as a job write path

magus job fork, the magus_job tool and magus\job.put refused a job because one of its write paths names a directory that already exists and is not a project root:

[MGS3018] job: wave/docs-fix declares a directory as a write path: "internal/job",
  inside project ".". A directory claims every file under it, so the job would
  overlap every job editing anything there. List the files the job will edit, or
  declare the root of the project it owns whole

Nothing was written to the job store.

Why

A write path is a claim. A directory claims every file under it, so a job that declares one overlaps every other job that edits anything in that directory, whether or not the two ever touch the same file. The overlap report then fills with pairs that share no file, and an orchestrator reading it as a queue holds work back that could have started.

A job's brief names the files it will change. The write paths should name the same files.

What passes

  • A file, existing or not: internal/job/store.go.
  • A path that does not exist yet. The job creates it, so nobody else can be editing anything under it.
  • A project root, meaning a directory holding a magusfile.buzz, a magusfiles/ directory or a magus.yaml. The job owns that project whole. The workspace root, ., counts when it is a project.
  • A file pattern, such as internal/job/*.go or internal/**/*_test.go.

A glob whose last segments are only wildcards, such as internal/**, internal/* or internal/**/*, names everything under its directory, so it is judged as that directory. When the directory part is itself a pattern (libs/*/src/**), each directory it matches is judged.

A directory under node_modules, vendor, .git, .claude and the other trees the workspace load skips is never a project root, even when it holds a magusfile.

What to do

List the files the job will edit:

magus job fork wave/docs-fix --write-paths internal/job/store.go,internal/job/store_test.go

If the job really does own a whole project, declare that project's root. The error names the project the directory sits in. There is no flag that accepts a plain directory.

See also

  • Leases: what a write path grants and what the guard enforces.
MGS3018jobsleaseswrite pathsforkagentsoverlap
Last updated (c1ca4543)
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.

Module

A magus stdlib namespace a magusfile imports for host capabilities: filesystem, exec, vcs, and more. See the module reference.

Buzz

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

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.

Lease

The grant a holder takes on a job: the write and read paths that job declared, enforced in the checkout that took it with magus job exec. A job is the piece of work; a lease is permission over it.

Conventions

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