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

MGS3044: a regenerated output outside the write paths

magus job fork, magus job apply and magus\job.put refused a job record because a target regenerates an output from sources inside its write paths, and the output itself is outside them:

[MGS3044] internal/job/gen/job.schema.json is regenerated by .:job-generate from
  types/job.go, and no write path covers it: add it to write_paths, or waive it
  if the root regenerates it

Nothing was written to the job store.

Why

A generated output changes with its sources. A job that edits the sources and cannot write the output either leaves it stale or hand-edits around the guard, and either way the next gate fails on a diff nobody owns.

What to do

  • If the job regenerates the output, add it to the write paths.
  • If the root regenerates it after integration, waive the problem with the output as its subject:
"waivers": [
  { "code": "MGS3044", "subject": "internal/job/gen/job.schema.json", "reason": "the root regenerates it" }
]

magus describe job <id> lists every output regenerated outside the write paths.

See also

  • MGS3045: a ci gate over the write paths that nothing runs.
  • Leases: write paths and waivers.
Sandbox diagnosticsLanding page for the sandbox that confines magus spells to the workspace, plus its MGS2xxx diagnostics for denied reads, writes, execs, and env leaks. MGS3045: a ci gate over the write paths nothing runsFires when a ci target reads files inside a job's write paths and neither the job's check nor any of its goals runs it. The record is refused unless it adds a goal for the target or waives the problem with a reason. MGS3032: an unordered share of one claimable fileFires when a job is forked with a write path that names the same single literal file, with a diff driver, as another live job's write path in a different checkout, and neither job is ordered against the other by parent, child, or depends_on. The fork is refused; claim a declaration, add --depends-on, or fold the work into the holder. magus jobThe POSIX child lifecycle over delegated work: fork declares a job, exec takes the lease on it in this checkout, exit returns it with its result, wait verifies that result, and run submits one of the server's own jobs.
MGS3044jobsleaseswrite pathsgeneratedforkapplyagentswaiversvalidation
Last updated (29d8b3de)
Glossary

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.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI 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.

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.

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

Conventions

Placeholders

Angle brackets mark a value you replace with your own; never type the brackets:

magus run <target>
magus completion <shell>    # e.g. bash, zsh, fish

<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.